Re: Assorted arm-buster problems - network configuration
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?
> 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>
Reply to: