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 andreimpope...@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.
