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