[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Assorted arm-buster problems - network configuration



On Sunday 07 July 2019 00:11:43 David Wright wrote:

> On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote:
> > On Saturday 06 July 2019 15:35:10 Brian wrote:
> > > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote:
> > > > On Friday 05 July 2019 15:23:38 Brian wrote:
> > > > > I was rather hoping someone would clarify why not having
> > > > > avahi-daemon in the first place was a good thing in general.
> > > > > Your problem doesn't particularly interest me because it is
> > > > > probably something you have brought on yourself due to
> > > > > previous actions.
> > > > >
> > > > > > Here is your Clarification: I used apt to purge avahi-daemon
> > > > > > which took nsswitch with it,
>
> That was your claim. Then I read the following:
>
>   Greg> Whatever Gene did, it's absolutely not normal or desirable for
>   Greg> nsswitch.conf to vanish.  I still think he deleted it by hand
> and then Greg> forgot the exact sequence of steps which led to its
> disappearance, so Greg> he simply blamed it on purging ahavi-daemon.
>
>   Gene> I didn't say that. If I made that impression I didn't intend
> to. I Gene> removed it by hand about 2 hours back but that u-sd has
> not been Gene> inserted in the pi yet as I'm also the chief cook […]
> Gene> […] recycle the dishwasher. :(
>
>   https://lists.debian.org/debian-user/2019/07/msg00306.html
>
> > > > > I stopped reading there. I am not into fantasy.
> > > >
> > > > Which proves another theorem of mine. Folks with a sheepskin on
> > > > the office wall stop learning, and by your stopping without
> > > > reading the explanation is evidence of that effect. I can lead
> > > > you to the facts, but
> > >
> > > Your first "fact" is demonstrably incorrect and has been shown to
> > > be so. Indeed, you seem to have backed away from your claim that
> > > avahi-daemon is the cause of your difficulties. The only place you
> > > lead people is up the misleading garden path. A clear statement of
> > > what you did and what happened is more likely to bring results;
> > > making attacking software a lifestyle choice gets a bit boring
> > > after a while.
> > >
> > > > like the horse refusing to drink when led to water, I'll drop
> > > > the reins. You may, or may not drink the water of knowledge. I
> > > > can't control that.
> > >
> > > Is this an attempt at some self-promotion as the fount of
> > > knowledge? I never thought I would live to see the day!
> >
> > If you read the full thread, you will find where I found and fixed
> > that problem, by killing dhcpd5 with htop, and restarting
> > networking, and the problem was fixed, everything then worked
> > correctly, but I have not reinstalled avahi-daemon to see if it
> > returns.  Perhaps I should because it appears there were 2 sources
> > of that trash.
>
> Perhaps you mean dhcpcd5? I thought you said that you're "the last one
> on the planet using hosts files and no dhcpd's of any kind".
>
That last as a qualifier was a bad reference too, as I now see the name 
of that function having been changed sometime in the last 20 years.

> If you were running this, did you try using the -L or --noipv4ll
> option?

No, and whereintunket would I find that in reference to my problem?>

> > Yes, I purged what was left as it wouldn't reinstall, then
> > reinstalled avahi-daemon.  results:
> >
> > With avahi-daemon running. the trash in the ip a report was back
> > after a networking restart, BUT allthough it showed in an ip r
> > report with a metric of 202, I could still ping yahoo.com. I could
> > not before.
> >
> > So I service avahi-daemon stopped it, and restarted the networking,
> > trash 169.254 junk gone. An yahoo.com still pinged.
> >
> > So I've purged it again.  And restarted the networking yet again.
> > ip a:
> > pi@picnc:~ $ ip a
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> > group default qlen 1000
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >     inet 127.0.0.1/8 scope host lo
> >        valid_lft forever preferred_lft forever
> >     inet6 ::1/128 scope host
> >        valid_lft forever preferred_lft forever
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> > state UP group default qlen 1000
> >     link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff
> >     inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link
> >        valid_lft forever preferred_lft forever
> > 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
> > pfifo_fast state DOWN group default qlen 1000
> >     link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff
> >
> > ip r:
> > pi@picnc:~ $ ip r
> > default via 192.168.71.1 dev eth0 onlink
> > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
>
> That looks very like what I posted, except for "onlink"; also I'm
> connected by wireless rather than wire. But my    ps -ef   listing
> and nsswitch.conf file show:
> $ ps -ef | grep avahi | grep -v grep ; grep hosts /etc/nsswitch.conf
> avahi      653     1  0 21:23 ?        00:00:00 avahi-daemon: running
> [wren.local] avahi      666   653  0 21:23 ?        00:00:00
> avahi-daemon: chroot helper hosts:          files mdns4_minimal
> [NOTFOUND=return] dns

>
> > So I now have a working network. Free of the bogus inventions of
> > dhcpd5 and avahi.  That _was_ the point of all this hoopla in the
> > first place.
> >
> > Now, I have learned what works to _my_ satisfaction.
>
> Glad to hear it. I still don't see that you've shown why you had to
> purge avahi to get your results above.
>
> > Have you? Or did you quit reading the instant I went off the edge of
> > your menu?
>
I ask because I've since found that if I give avahi a chance to pollute 
things, removeing it does no good until you've rebooted the machine and 
I have already found that out for dhcpcd5. Either one can pollute, but 
to get the full effect of removing it, you must reboot the machine. 
However I am reticent to do that as I then have to go to the machine and 
hand start ssh as it won't start on reboot even if told to.

Why is that?  I have had no such trouble with a realtime stretch.

> Cheers,
> David.

Cheers yourself David

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


Reply to: