惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
雷峰网
雷峰网
S
SegmentFault 最新的问题
博客园 - 【当耐特】
博客园_首页
量子位
爱范儿
爱范儿
博客园 - 叶小钗
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Jina AI
Jina AI
V
V2EX
美团技术团队
V
Visual Studio Blog
博客园 - 三生石上(FineUI控件)
IT之家
IT之家
Hugging Face - Blog
Hugging Face - Blog
Apple Machine Learning Research
Apple Machine Learning Research
小众软件
小众软件
博客园 - 聂微东
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
The Cloudflare Blog
宝玉的分享
宝玉的分享
WordPress大学
WordPress大学
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻

dnsmasq-discuss

[Dnsmasq-discuss] Announce: dnsmasq-2.92rc2 Re: [Dnsmasq-discuss] [PATCH] Fix arguments order for chaos subdomain check Re: [Dnsmasq-discuss] patch: block-file/allow-file - for review/feedback Re: [Dnsmasq-discuss] patch: block-file/allow-file - for review/feedback Re: [Dnsmasq-discuss] patch: block-file/allow-file - for review/feedback Re: [Dnsmasq-discuss] patch: block-file/allow-file - for review/feedback [Dnsmasq-discuss] patch: block-file/allow-file - for review/feedback Re: [Dnsmasq-discuss] server= with interface parameter changes behavior over time [Dnsmasq-discuss] NFTsets and hosts-files [Dnsmasq-discuss] [PATCH] Allow expired RRSIGs when stale caching is enabled [Dnsmasq-discuss] [PATCH] Fix local host records being overridden by upstream NXDOMAIN [Dnsmasq-discuss] [PATCH] Fix arguments order for chaos subdomain check Re: [Dnsmasq-discuss] Malformed RRSIG Can Crash dnsmasq [Dnsmasq-discuss] Malformed NSEC/NSEC3 Can Hang dnsmasq [Dnsmasq-discuss] Malformed RRSIG Can Crash dnsmasq [Dnsmasq-discuss] Security - IMPORTANT Re: [Dnsmasq-discuss] Issue with circuit-id matching on dhcp requests Re: [Dnsmasq-discuss] Issue with circuit-id matching on dhcp requests Re: [Dnsmasq-discuss] Issue with circuit-id matching on dhcp requests [Dnsmasq-discuss] Issue with circuit-id matching on dhcp requests Re: [Dnsmasq-discuss] [PATCH] bpf.c: fix memory leak in arp_enumerate() on BSD Re: [Dnsmasq-discuss] [PATCH] bpf.c: fix memory leak in arp_enumerate() on BSD Re: [Dnsmasq-discuss] dnssec problem here and now Re: [Dnsmasq-discuss] dnssec problem here and now [Dnsmasq-discuss] dnssec problem here and now Re: [Dnsmasq-discuss] server= with interface parameter changes behavior over time Re: [Dnsmasq-discuss] [PATCH] bpf.c: fix memory leak in arp_enumerate() on BSD Re: [Dnsmasq-discuss] [PATCH] bpf.c: fix memory leak in arp_enumerate() on BSD Re: [Dnsmasq-discuss] [PATCH] Preserve existing log file permissions when adding group-write bit. [Dnsmasq-discuss] server= with interface parameter changes behavior over time
Re: [Dnsmasq-discuss] Shut down caused by device request ...
Matthias Andree via Dnsmasq-discuss · 2026-02-22 · via dnsmasq-discuss
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.



_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss