Bugzilla – Bug 1227326
Machine running dnsmasq no longer answers DHCP requests
Last modified: 2024-07-17 13:50:56 UTC
After a recent update of my server, dnsmasq no longer answers DHCP requests. Or rather, dnsmasq seems to produce answers, but clients don’t receive them. I used wireshark on the server as well as on one of the clients to have a closer look. On the server, wireshark shows incoming DHCPDISCOVER and outgoing DHCPOFFER messages as should be. However, on the client, wireshark only shows the outgoing DHCPDISCOVER messages but no corresponding incoming DHCPOFFER messages. So the packets seem to get lost between wireshark logging them and the packets actually hitting the wire (or rather the WiFi antenna). This problem affects all clients, including Android smartphones, so the problem is clearly on the server side. Dnsmasq hasn’t been updated since months, so it likely isn’t the culprit. I didn’t change any relevant system configuration, e.g. firewall settings. I observed this behavior under kernel 6.9.7. Reverting back to 6.9.6 didn’t help, however. By the way, dnsmasq answers DNS queries still just fine. Any ideas? What else could I try?
Is there no one here to take over? Not even for a rejection?
Meanwhile, I updated all Linux machines to kernel version 6.9.9, which didn’t help. However, I also reactived an old notebook, updated it to the most recent Tumbleweed version, and – lo and behold – it DOES receive DHCP messages from the DHCP server (dnsmasq) and gets a proper network configuration! All other clients in my network don’t, which are a few Linux machines as well as Android phones.
Next insight: To rule out possible influences from possibly different system configurations, I used the Tumbleweed network installer as a minimal and standardised DHCP client on two different machines. One of these machines was the reactivated notebook mentioned above, which receives DHCP responses when running the installed Linux system. In both cases, the DHCP client received no network configuration via DHCP. This really is a mystery! But I believe we can conclude that it is a server issue, especially since also Android clients are affected. What else can I do to investigate this further? (Assuming someone is reading this at all …)