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? > Here's the (mangled) output from this PC: > > $ dpkg -l | grep avahi > ii avahi-autoipd 0.6.32-2 amd64 Avahi IPv4LL network > address configuration daemon ii avahi-daemon 0.6.32-2 > amd64 Avahi mDNS/DNS-SD daemon ii avahi-discover 0.6.32-2 > all Service discover user interface for avahi ii avahi-utils > 0.6.32-2 amd64 Avahi browsing, publishing and discovery > utilities ii libavahi-client3:amd64 0.6.32-2 amd64 Avahi client > library ii libavahi-common-data:amd64 0.6.32-2 amd64 Avahi common data > files ii libavahi-common3:amd64 0.6.32-2 amd64 Avahi common > library ii libavahi-core7:amd64 0.6.32-2 amd64 Avahi's > embeddable mDNS/DNS-SD library ii libavahi-glib1:amd64 0.6.32-2 > amd64 Avahi GLib integration library ii python-avahi > 0.6.32-2 amd64 Python utility package for Avahi $ ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > group default qlen 1 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: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc > pfifo_fast state DOWN group default qlen 1000 link/ether > 12:34:56:12:34:56 brd ff:ff:ff:ff:ff:ff > 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state > UP group default qlen 1000 link/ether 12:34:56:12:34:56 brd > ff:ff:ff:ff:ff:ff > inet 192.168.1.17/24 brd 192.168.1.255 scope global wlp2s0 > valid_lft forever preferred_lft forever > inet6 fe80::123:4567:1234:5678/64 scope link dadfailed tentative > valid_lft forever preferred_lft forever > $ ip r > default via 192.168.1.1 dev wlp2s0 > 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.17 > $ > > It appears swamped in avahi packages, but no sign of interference from > 169.254… addresses. > > BTW, what *is* dhcpd5? > > Cheers, > 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>