[Dnsmasq-discuss] Shut down caused by device request address.

[Geert Stappers]

On Sun, Feb 22, 2026 at 02:56:40PM +0100, Matthias Andree wrote:
> Am 22.02.26 um 13:49 schrieb john doe: 
> > On 2/22/26 12:45 PM, Matthias Andree wrote:
> > > Am 22.02.26 um 11:33 schrieb Colin Finnis:
> > > > 
> > > > I have been running dnsmasq for some time on a Raspberry PI. I
> > > > had no problems until about 18 months ago when the DNS would
> > > > suddenly stop working. I found these types of entries in the
> > > > syslog.
> > > > 
> > > > Feb 21 16:14:07 pilot dnsmasq-dhcp[2061]: DHCPACK(eth0) 192.168.0.242 02:ef:dd:91:3a:f3 Wild-s-S21
> > > > Feb 21 16:14:09 pilot dnsmasq-dhcp[2061]: DHCPREQUEST(eth0) 192.168.0.242 02:ef:dd:91:3a:f3
> > > > Feb 21 16:14:09 pilot dnsmasq-dhcp[2061]: DHCPACK(eth0) 192.168.0.242 02:ef:dd:91:3a:f3 Wild-s-S21
> > > > 
> > > > Feb 21 16:14:09 pilot dhcpcd[377]: eth0: hardware address 02:ef:dd:91:3a:f3 claims 192.168.0.8
> > > > Feb 21 16:14:10 pilot dhcpcd[377]: eth0: hardware address 02:ef:dd:91:3a:f3 claims 192.168.0.8
> > > > Feb 21 16:14:10 pilot dhcpcd[377]: eth0: 10 second defence failed for 192.168.0.8
> > > > Feb 21 16:14:10 pilot dhcpcd[377]: eth0: deleting route to 192.168.0.0/24
> > > > Feb 21 16:14:10 pilot dhcpcd[377]: eth0: deleting default route via 192.168.0.1
> > > > 
> > > > Feb 21 16:14:10 pilot avahi-daemon[279]: Withdrawing address record for 192.168.0.8 on eth0.
> > > > 
> > > > The problem always seems to be associated with Samsung phones
> > > > and appears to have started after an update to the phone around
> > > > 18 months ago. I have found what purports to be a solution which
> > > > requires a setting change on the phone. This is fine for my
> > > > phone but visitors to my house can cause the same problem and
> > > > its difficult to get them all to change before the damage is
> > > > done. It dosnt always happens when the phone is brought into the
> > > > house, I think it occur when the phone is close to the property
> > > > and the signal is poor.
> > > > 
> > > > As you can see the request is made for an address and the DNS
> > > > responds. The request is made a second time and immediately the
> > > > device seems to take over the IP address of the DNS box. DHCPD
> > > > then goes into some sort of defence mode and avahi withdraws the
> > > > statically assigned address. I have tried changing the address
> > > > of the DNS server in case it was just the phone using a random
> > > > address but that made no difference. I cant run a network
> > > > monitor on the traffic so I cant see what is happen during this
> > > > event. It just sems strange behaviour for the phone to suddenly
> > > > decide its going to usurp the DNS’s IP address.
> > > > 
> > > > Im technically savvy having worked in the IT industry for 40
> > > > years but cant work out away to either prevent this or stop it
> > > > happening. The only way at the moment is to reboot the PI. Any
> > > > help would be appreciated.
> > > > 
> > > 
> > > you're not reporting your dnsmasq version, and what's utterly
> > > unclear to me is how the MAC address is both for Wild-s-S21 and
> > > dhcpcd? What is the setting for the Samsung phone that would prevent
> > > this? Give the phone a static address?
> > > 
> > > How come dhcpcd concludes that the shown hardware address is for
> > > 192.168.0.8 if dnsmasq handed out 192.168.0.242 for what appears to
> > > be a Samsung S21 phone?

I do read `dhcpcd[377]: eth0: hardware address 02:ef:dd:91:3a:f3 claims 192.168.0.8`
as an informational message, dhcpcd telling "MAC-address X claims IP-address Y"


> > Newer phones have, per default, random MAC turned on, if you  want to
> > assign a static lease to your phone you might want to stop that from
> > happening.
> > 
> That's one thing -- but to me does not explain what Colin reported:
> what does the Raspberry Pi's dhcpcd have to do with that killing the Pi's
> own network connection?

My guess:   `pilot`, hostname of the Raspberry PI, default install
with dhcpcd, DHCP Client Daemon,  and later on install of dnsmasq
as DHCP server.  Without setting a static IP-address to `pilot`
and without removal of dhcpcd.
Thing is the dhcpcd dnsmasq on same server feels wrong.


> If the phone re-rolls the dice for its new random MAC, it should hopefully
> release the old lease, get a new IP address from the DHCP server - but that
> should not be one that's currently in use. (Except if there are two or more
> DHCP servers active on the subnet.) A tcpdump or similar should shed some
> light on the issue still.

Yes, sharing a .pcap will be a good thing for getting more insights.



Groeten
Geert Stappers
-- 
Silence is hard to parse