On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote: > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus > <c.brinkh...@t-online.de> wrote: > > [...] > > > But backing up... I suspect there's something wrong with your static > > > ip address assignment. The address is already taken, the netmask is > > > wrong, or the gateway is wrong. > > > > > > Looking back through this thread, I did not see where you showed your > > > static ip configuration. Maybe you should start with that. If it is > > > bad, then the APIPA is just a symptom of the [static ip address] > > > problem. > > > > This is the systemd-networkd configuration: > > > > [Match] > > Name=w* > > > > [Network] > > DHCP=no > > Address=192.168.0.62/24 > > Gateway=192.168.0.32 > > DNS=127.0.0.1 > > > > I have unbound as a DNS listening at localhost. But with > > DNS=192.168.0.32 the behaviour has been similar. > > > > I have not yet checked the address assignment using systemd-networkd. > > For doing so I have to reinstall some packages. > > I don't know what the Match section does. I am suspicious of it.
Oh, Match is great. For a typical, simple PC or laptop, you no longer have to worry about whether your wifi is called wlan0 (kernel, and iwd), wlo0, wlp365s7 (onboard/slot/path), or wlxf1dd1efadd1e (USB), it'll get matched nonetheless. Ditto for e* and ethernet. > 192.168.0.0 address block is /16, not /24. > > I'm in the US, and I use Verizon for my ISP. Verizon gadgets, like set > top boxes and media centers, use 192.168.0.x addresses. I never put > anything on 192.168.0.x. I start with 192.168.1.x. And on the Verizon > network, I've never seen a 192.168.0.x gateway. Gateways also go on > 192.168.1.x. So I'm a bit suspicious of the network assignments. I don't understand this. If you're actually running two subnets with 255.255.255.0 netmasks, and they intercommunicate with each other (your computers on subnet 1, and Verizon ISP on subnet 0), then you must have a gateway on each subnet for them to communicate through. But backing up… the systemd-networkd configuration above is that of Christoph, who wrote that their system had been (a) switched to systemd-networkd from systemd-networking, and (b) purged of avahi packages to eliminate 169.254.x.y addresses. So I'm not sure what there is to fix here. But (a) raises the question of what systemd was running /before/, which was presumably what was giving rise to 169.254.x.y addresses. And, while I can add an innocuous 169.254.0.0 route to a system merely by installing ifupdown and avahi-autoipd, that route looks like the second line here: default via 192.168.1.1 dev enp2s2 onlink 169.254.0.0/16 dev enp2s2 scope link metric 1000 192.168.1.0/24 dev enp2s2 proto kernel scope link src 192.168.1.10 and not like the OP's (ie Geert's): 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 (which has been grepped out of its context). Cheers, David.
