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

Re: Assorted arm-buster problems - network configuration



On Sat 06 Jul 2019 at 21:38:10 (-0400), Gene Heskett wrote:
> 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

Well, I'm glad I didn't take the trouble to try answering the previous post.

> 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?

Dunno. What does journalctl tell you?

Cheers,
David.


Reply to: