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 _______________________________________________ Dnsmasq-discuss mailing list [email protected] https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
