<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 22.02.26 um 11:33 schrieb Colin
Finnis:<br>
</div>
<blockquote type="cite"
cite="mid:004b01dca3e6$a73d99f0$f5b8cdd0$@finnis.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Aptos;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;
mso-fareast-language:EN-US;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Feb 21 16:14:07 pilot dnsmasq-dhcp[2061]:
DHCPACK(eth0) 192.168.0.242 02:ef:dd:91:3a:f3 Wild-s-S21<o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:09 pilot dnsmasq-dhcp[2061]:
DHCPREQUEST(eth0) 192.168.0.242 02:ef:dd:91:3a:f3 <o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:09 pilot dnsmasq-dhcp[2061]:
DHCPACK(eth0) 192.168.0.242 02:ef:dd:91:3a:f3 Wild-s-S21<o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:09 pilot dhcpcd[377]: eth0:
hardware address 02:ef:dd:91:3a:f3 claims 192.168.0.8<o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:10 pilot dhcpcd[377]: eth0:
hardware address 02:ef:dd:91:3a:f3 claims 192.168.0.8<o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:10 pilot dhcpcd[377]: eth0: 10
second defence failed for 192.168.0.8<o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:10 pilot dhcpcd[377]: eth0:
deleting route to 192.168.0.0/24<o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:10 pilot dhcpcd[377]: eth0:
deleting default route via 192.168.0.1<o:p></o:p></p>
<p class="MsoNormal">Feb 21 16:14:10 pilot avahi-daemon[279]:
Withdrawing address record for 192.168.0.8 on eth0.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Colin Finnis</p>
</div>
</blockquote>
<p><br>
</p>
<p>Colin,</p>
<p>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?<br>
<br>
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?</p>
<p>What dhcpcd and version is it? Is there a tcpdump or tshark dump
or something, possibly combined with a dhcpcd debug log, so we
could see what's up? This does not *obviously* look like a dnsmasq
bug.</p>
<p>For an approach to solving this, outside dnsmasq, I wouldn't
configure "pilot" (the RPi) through DHCP but give it a static
address instead, possibly also from 192.168.0.* but then also
reducing the DHCP address pool so its static address isn't part of
the pool - and avoid running dhcpcd.</p>
</body>
</html>