Weird problem with local router after hardware change

Rocky Linux Help & Support
1

Hi,

My local network is managed by a local gateway/router/proxy running Rocky Linux 8 and stuff like Dnsmasq, Squid, SquidAnalyzer, etc.

The whole configuration is described in this Ansible playbook:

So far this worked perfectly, but today I had a hardware crash. The PC Engines routerboard apparently went belly up.

Fortunately I have a spare one in my office. So I installed Rocky Linux 8 on it along with Git and Ansible. I fetched the playbook. I didn’t even have to adjust the network interface names, since they were the same than the previous machine.

I just ran the playbook, and less than an hour later (it’s not a very fast machine) I had my configuration back.

Now I’m facing a weird problem. Dnsmasq seems to work OK, but only for those machines that weren’t connected recently. My main workstation and my laptop can’t seem to get an IP address from the router. Dnsmasq’s logs look like this:

Apr 26 14:23:24 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:24 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:40 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:40 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:40 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:40 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:55 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:55 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:55 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:55 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:58 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:58 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:58 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:23:58 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:24:03 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:24:03 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:24:03 dnsmasq-dhcp[682]: DHCPDISCOVER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd 
Apr 26 14:24:03 dnsmasq-dhcp[682]: DHCPOFFER(enp2s0) 192.168.2.5 d0:37:45:24:61:bd

Do I have to clear some weird cache-related or lease-related stuff on the client side? I vaguely figure there’s some problem because the new machine obviously has a different MAC address on the LAN interface, but I’m not proficient enough in network internals to know exactly what is wrong here.

Any suggestions ?

2

I’ll answer this myself, since I eventually solved the problem, though I don’t know exactly how. I booted a NixOS LiveUSB on each of the problematic clients, which renewed the DHCP lease. After this I could boot normally into Rocky Linux with the “new” lease.

If anyone has an explanation of what happened, I’m curious.

3

Your inventory seems to have/use MAC:s only for the DHCP server’s config. The “main workstation and my laptop” did not change, so they should not have been affected in any way.

NetworkManager connection can be bound to ifname or to MAC. That is, NM will use the connection for device that matches. In the era of “randomly” enumerated ethN names, binding to MAC was awesome for persistence.

The Rocky installer creates connections bound to MAC.
The manual use of nmcli con add forces us to bind to ifname (which is inconvenient, IMHO).
Not sure how your “NM config” role updates the connections.

No idea, why you got the:

Client: Hi. This is d0:37:45:24:61:bd. Can I keep the 192.168.2.5?
Server: That is ok.
Client: server does not talk to me, I’ll ask again