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

Re: Assorted arm-buster problems - network configuration



On Saturday 06 July 2019 20:30:02 Gene Heskett wrote:

> On Saturday 06 July 2019 12:02:51 David Wright wrote:
> > On Fri 05 Jul 2019 at 21:19:29 (-0400), Gene Heskett wrote:
> > > On Friday 05 July 2019 12:08:45 David Wright wrote:
> > > > On Fri 05 Jul 2019 at 06:06:30 (-0400), Gene Heskett wrote:
> > > > > On Thursday 04 July 2019 16:48:56 andreimpopescu@gmail.com 
wrote:
> > > > > > On Jo, 04 iul 19, 11:40:30, Gene Heskett wrote:
> > > > > > > > 1. content of /etc/network/interfaces and all files
> > > > > > > > under /etc/network/interfaces.d/
> > > > > > >
> > > > > > > pi@picnc:~ $ cat /etc/network/interfaces.d/*
> > > > > >
> > > > > > Is below the literal output of the cat above?
> > > > > >
> > > > > > Please post also /etc/network/interfaces.
> > > > > >
> > > > > > > auto eth0
> > > > > > >
> > > > > > > iface eth0 inet static
> > > > > > > address 192.168.71.12/24
> > > > > > > gateway 192.168.71.1
> > > > > > > post-up echo 1 > /proc/sysy/ipv6/conf/$IFACE/disable_ipv6
> > > > > > >
> > > > > > > Which the last line disables ipv6  on this machines mostly
> > > > > > > stretch install.
> > > > > >
> > > > > > It doesn't, but IPv6 is not your problem anyway.
> > > >
> > > > […]
> > > >
> > > > > > In addition to the full /etc/network/interfaces please post
> > > > > > also the output of
> > > > >
> > > > > Its unmodified, and contains only the line to source whatever
> > > > > may be in the interfaces.d directory.
> > > >
> > > > Technically, that just doesn't cut it, and I'm not sure what
> > > > makes you coy about posting them. Which files get used depends
> > > > on how the source line is expressed (source/source-directory),
> > > > and then on what the filenames are for the files which you cat'd
> > > > with * (that have to match a filename pattern).
> > > >
> > > > On Debian, it's normal for the d-i to write (and sometimes
> > > > unwrite) the /e/n/i file. But what gets written depends on the
> > > > installation method. But it's not even clear that you used the
> > > > d-i to install your system, if I've followed the thrread
> > > > correctly.
> > >
> > > d-i? Define please so we're both on the same jargon page.
> >
> > Sorry, I thought you were familiar with these terms, which I see we
> > were conversing with years ago. d-i Debian installer, /e/n/i
> > /etc/network/interfaces.
> >
> > > And yes, until
> > > N-M was sufficiently house broken & trained to leave a static
> > > setup alone, and it had so many dependencies you could only neuter
> > > it by a chatttr +i on the stuff you didn't want it editing. Or
> > > find it and use the F8 key in mc.  Six of one, half a dozen of the
> > > other as later as wheezy.
> >
> > I've read enough of this to know that it's not worth treating
> > seriously. Over the years you've frequently posted (and reposted)
> > malformed configuration files which you defend vehemently.
> >
> > > > As I've said, though, I'll go no further in looking at the
> > > > problems you have because I think that many of them are of your
> > > > own making.
> > >
> > > Thats also true, simply because I'm the last one on the planet
> > > using hosts files and no dhcpd's of any kind.
> >
> > "I'm the last one …" might be true, but there's no evidence for your
> > writing "because".
> >
> > > So no one has answered me with a
> > > howto to get rid of all the 169.254.xx.xx bull shit in my network
> > > configs that stopped it from working.  I turned out, after I had
> > > removed ALL the avahi sources, it was still there, so I next
> > > killed dhcp, no effect, but it all disappeared when I removed
> > > dhcpd5, that stopped all the poisoning of my network configs.
> > >
> > > IMO having a dhcpd5 invent bogus numbers when there is not an
> > > accessable server, is both a huge security hole that could be
> > > exploited, and grounds for 30 lashes useing a cat-o-9-tails made
> > > out of wet noodles being applied to whoever thought it was a good
> > > idea. It was, IMNSHO, a very very bad idea.
> >
> > I don't really have much idea of what you're talking about, except
> > to ask why, if you don't like DHCP and claim not to be runnning it
> > (above), you installed all this stuff (on picnic, I assume). What
> > was it there for?
>
> Its part of the buster-rc2 installed image, and I just now found that
> even with that stuff removed, something times out and restores the
> bogus default route, screwing up what 30 seconds before was a works
> perfectly network, but the default route has, without me doing
> anything but running ip r, has reset the default route to
> 169.254.0.0/16 with a metric (which I'm told is a priority) of 202,
> which wins the battle since the default metric is 1024. So now my
> network is again unusable because anything out of the 192.168.71.00/24
> block does not get thru the router to actually access the internet at
> large.
>
> So my next question is: what the hell is discovering that 169.254 bull
> shit is missing, and automatically re-adding it to the routing?  I've
> killed it with ip route del 169.254.0.0/16 dev eth0, restarted the
> networking, run ip r to see its clean, rerun ip r 30 seconds later and
> in been restored again and my network is dead again.
>
> Thats a long question but I'm hoping the answer is suitably short.
> What is restoreing it?  I've even gone so far as to
> edit /etc/default/networking to look like this and which did work on
> stretch:
> # Configuration for networking init script being run during
> # the boot sequence
>
> # Set to 'no' to skip interfaces configuration on boot
> #CONFIGURE_INTERFACES=yes
>
> # Don't configure these interfaces. Shell wildcards supported/
> #EXCLUDE_INTERFACES=
>
> # Set to 'yes' to enable additional verbosity
> #VERBOSE=no
>
> # Method to wait for the network to become online,
> # for services that depend on a working network:
> # - ifup: wait for ifup to have configured an interface.
> # - route: wait for a route to a given address to appear.
> # - ping/ping6: wait for a host to respond to ping packets.
> # - none: don't wait.
> WAIT_ONLINE_METHOD=ping
>
> # Which interface to wait for.
> # If none given, wait for all auto interfaces, or if there are none,
> # wait for at least one hotplug interface.
> WAIT_ONLINE_IFACE=eth0
>
> # Which address to wait for for route, ping and ping6 methods.
> # If none is given for route, it waits for a default gateway.
> WAIT_ONLINE_ADDRESS=192.168.71.1
>
> # Timeout in seconds for waiting for the network to come online.
> WAIT_ONLINE_TIMEOUT=30
>
> And I'm going to take a SWAG and say that 30 seconds is about the
> length of a working network. This worked on stretch, but isn't working
> on buster-rc2. As an experiment I will reset that 30 to 600 and see if
> O have a working network for ten minutes. No, no effect, the network
> dropped off the edge ib 30 to 40 seconds again,
> a networking restart gets me this:
> 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
>
> but if I query it again after typing this, which took 30+ seconds:
>
> pi@picnc:/etc/systemd/system/network-online.target.wants $ ip r
> default dev eth0 scope link src 169.254.163.253 metric 202
> 169.254.0.0/16 dev eth0 scope link src 169.254.163.253 metric 202
> 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12
>
> So whats next?
>
Since I hit send I found that dhcpcd and dhcpcd5 were installed on this 
u-sd card. They have now been purged. And that had no effect on this, 
that bogus route is restored perhaps 10 seconds after I restart the 
networking and verify its gone.

15 minutes later I've found that after purging the stuff, it also takes a 
reboot to clear some buffers, possibly in /proc.

So its possible this problem is fixed, at least till it makes a liar out 
of me but its been rebooted about 30 minutes and ip r still says:
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

So that leaves one more problem thats piling up the mileage on these 
ancient legs, that of having to go out to where this machine is, which 
regardless of which door I come in thru, involves climbing over and 
walking on a pile of mahogany for a furniture project so I can start ssh 
by hand. That in spite of having a link called by S01ssh in /etc/rc5.d/.

So whats stopping ssh from starting at bootup which is to a pretty 
desktop gui?

Thanks all.

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: