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

[Matthias Andree]

Am 22.02.26 um 13:49 schrieb john doe via Dnsmasq-discuss:
> On 2/22/26 12:45 PM, Matthias Andree via Dnsmasq-discuss 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.
>>>
>>> Colin Finnis
>>>
>>
>> Colin,
>>
>> 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?
>>
>
> 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?

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.