[Dnsmasq-discuss] Defending IP address
A C
dnsmasq6pJH at acarver.net
Sat May 6 18:17:22 UTC 2023
One thing I'd like to point out is that the documentation demonstrating
setting a static IP using dhcpcd.conf is not from the Raspberry Pi
foundation but from a lot of other Rasberry Pi blogs online.
The official blog does not list using that method at all. Instead it
either points to using a systemd network file or through the
/etc/network/interfaces file.
The fact that it worked is probably just luck but it is likely a very
unstable configuration.
On 2023-05-06 10:03, Geert Stappers wrote:
> On Fri, May 05, 2023 at 11:02:49PM +0200, Johan Vromans wrote:
>> On Fri, 5 May 2023 22:13:24 +0200, Geert Stappers wrote:
>>> On Fri, May 05, 2023 at 08:47:14PM +0200, Johan Vromans wrote:
>>>>
>>>> ... The system is a Raspberry Pi running Raspbian.
>>>> It is DHCP/DNS server (dnsmasq) for my LAN.
>>>>
>>>> As said earlier, all information [for this type of system] points towards
>>>> setting the static address in /etc/dhcpcd.conf and apparently dhcpcd
>>>> handles this situation. At least, this has been working for several years
>
> Let's try to understand why it was working.
>
>
>>>> without problems. Until now, that is, thanks to some buggy(?) IoT devices.
>>>
>>> It is too early to blame the IoT devices.
>>
>> I don't blame them... They merely revealed there's something fishy.
>
> Let's try to find out what is going on in the dhcpcd-dnsmasq-combo.
>
>
>>>> I now have the static address setting in /etc/network/interfaces and
>>>> disabled dhcpcd so everything is fine again, and hopefully more robust.
>>>>
>>>> Thanks all for your valuable feedback that helped me to find the problem
>>>> and its solution.
>>>
>>> https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q2/017057.html has:
>>> }
>>> } On second thought:
>>> } The problem could be how dhcpcd and dnsmasq work together.
>>> }
>>> } Or more likely:
>>> } The problem could be how dhcpcd and dnsmasq are configured.
>>> }
>>> }
>>> } So far we have seen (parts of) dhcpcd configuration
>>> } and no dnsmasq configuration at al.
>>> }
>>>
>>> That text in other words:
>>>
>>> Share with the dnsmasq mailinglist (archive) the dnsmasq configuration.
>>> The original problem is most likely solvable with the original dhcpcd
>>> configuration in-place.
>>
>> Strange that you keep pointing towards dnsmasq,
>
> dnsmasq *plus* dhcpcd
>
>
>> while Geoff already clearly
>> explained that it is not dnsmasq, but dhcpcd that drops the address.
>
> Text from the email Geoff did reply to:
>
> }
> } ... a number of IoT devices. Occasionally, when they try to set up the
> } DHCP lease, some of them send wrong packets. The device effectively claims
> } the IP address of the DHCP server. From the system log:
> }
> } May 4 05:39:59 srv1 dhcpcd[449]: eth0: hardware address
> } xx:xx:xx:xx:xx::ce claims 192.168.1.10
> }
> } where 192.168.1.10 is the address of the DHCP server.
> }
> } If a second package arrives within 10 seconds,
> }
> } May 4 05:40:08 srv1 dhcpcd[449]: eth0: hardware address
> } xx:xx:xx:xx:xx::e7 claims 192.168.1.10
> }
> } dnsmasq shuts down the network connection
> }
> } dhcpcd[449]: eth0: 10 second defence failed for 192.168.1.10
> } dnsmasq-dhcp[24169]: DHCPRELEASE(eth0) 192.168.1.96 xx:xx:xx:xx:xx::e7
> } avahi-daemon[373]: Withdrawing address record for 192.168.1.10 on eth0.
> } avahi-daemon[373]: Leaving mDNS multicast group on interface eth0.IPv4 with
> } address 192.168.1.10. avahi-daemon[373]: Interface eth0.IPv4 no longer
> } relevant for mDNS. dhcpcd[449]: eth0: deleting route to 192.168.1.0/24
> } dhcpcd[449]: eth0: deleting default route via 192.168.1.1
> }
> } and slowly the LAN collapses.
>
> Note the
> } xx:xx:xx:xx:xx::ce claims 192.168.1.10
> } xx:xx:xx:xx:xx::e7 claims 192.168.1.10
> Two different MAC addresses wanting IP address 192.168.1.10.
>
>
>> But if it makes you happy,
>
> [1]
>
>
>> I've attached the dnsmasq configs.
>>
>> I left out the hosts part, it's just a long series of
>>
>> xx:xx:xx:xx:xx:xx,192.168.1.nnn,hostname.squirrel.nl,24h
>
> Let's assume there is
>
> } xx:xx:xx:xx:xx:aa,192.168.1.10,dnsmasq.squirrel.nl,24h
>
> So some kind of a claim on .10 for DNS-DHCP-server dnsmasq.
>
>
>> # dnsmasq_conf for squirrel.nl -- generated Mon May 1 10:29:58 2023
>>
>> # Do not forward simple name queries.
>> domain-needed
>>
>> # Do not forward reverse lku for private domains.
>> bogus-priv
>>
>> # Filter extraneous DNS requests by Windows.
>> filterwin2k
>>
>> # Do not use /etc/resolv.conf.
>> no-resolv
>> no-poll
>>
>> # FQDN.
>> expand-hosts
>> domain=squirrel.nl
>> # Do not forward to external servers.
>> local=/squirrel.nl/
>>
>> # External name servers.
>> server=1.1.1.1
>> server=1.0.0.1
>>
>> # Only use our own list of hosts.
>> no-hosts
>> addn-hosts=/etc/local/dnsmasq_hosts
>>
>> # TXT entries in separate file
>> # conf-file=/etc/local/dnsmasq_txt
>>
>> # Additional configs.
>> conf-dir=/etc/local/dnsmasq.d,*.conf
>>
>> # Logging.
>> #log-queries
>
>> # DHCP settings for squirrel.nl -- generated Mon May 1 10:29:58 2023
>>
>> dhcp-authoritative
>>
>> # Location of leases.
>> #dhcp-leasefile=/var/lib/misc/dnsmasq.leases
>>
>> # Local name servers.
>> dhcp-option=6,192.168.1.10,192.168.1.16
>>
>> # Default router.
>> dhcp-option=option:router,192.168.1.1
>>
>> # Addresses for dynamic hosts.
>> dhcp-range=192.168.1.33,192.168.1.50,6h
>
> Now we known that .10 is *outside* the DHCP range.
>
>
>> # NTP host(s).
>> dhcp-option=option:ntp-server,192.168.1.10
>>
>> # PXE boot image.
>> dhcp-boot=pxelinux.0,pxeboot.squirrel.nl,192.168.1.16
>>
>> # DHCP host names in separate file.
>> dhcp-hostsfile=/etc/local/dnsmasq_dhcp
>>
>> # Logging.
>> #log-dhcp
>
>> # TFTP settings for squirrel.nl -- generated Mon May 1 10:29:58 2023
>>
>> # TFTP server for PXE boot.
>> enable-tftp
>> tftp-root=/tftpboot
>>
>
> Qouting another email from Johan:
> } I have this in my /etc/dhcpcd.conf:
> }
> } interface eth0
> } static ip_address=192.168.1.10/24
> } static routers=192.168.1.1
>
>
> My stab on why it "worked":
> * server with dhcpcd and dnsmasq is started
> * dhcpcd does DHCP client thing
> * No answer, the static configuration of dhcpcd is activated
> * dnsmasq is started
> * ignorance is bliss
>
> Yet unknown:
> * The kind of reservation that dnsmasq has for .10
> * How to tell dhcpcd "keep 192.168.1.10"
>
>
> My stab on how it breaks:
> * a new DHCP client asks for 192.168.1.10
> * dnsmasq unaware that 192.168.1.10 is intended for its self
> * dhcpcd not doing a renew (remaining shortly the static config)
> * dhcpcd stepping aside, releasing its "static" .10 address
> * dnsmasq losing the addres it was using
>
>
> Preventing the breakage with having a true static IP address for the
> dnsmasq server is a good solution. Probably the best from the point of
> view from dnsmasq. I don't know if dnsmasq can send DHCPNAK, DHCP Negative
> Acknowlegde, when it sees requests for a reservation. It would help
> dhcpcd to defence its IP-address.
>
> With some luck is Roy Marples or another person with dhcpcd knowlegde
> on this list and can tell how to configure dhcpcd to keep an assigned
> IP-address. How to prevent
> } dhcpcd[449]: eth0: 10 second defence failed for 192.168.1.10
>
>
> There is an unknown ascpect on this interesting problem:
> Why are the IoT devices asking for 192.168.1.10?
>
> Answer to that question is in providing information on the IoT devices.
> Yeah, it might feel odd, but is a good thing to describe the clients
> that are supposed to talk to a server.
>
>
> Idea to help dhcpcd to defend it's address, is moving it to a place
> where it wouldn't be under heavy attack. Like moving to 192.168.1.9
> At that address it doesn't have to deal with requests for 192.168.1.10
> by the IoT devices. My guess is that 192.168.1.10 is some default for
> the IoT device. I think it is a good thing to move DNS away from the .10
> address that an IoT device likes to claim.
>
>
> Groeten
> Geert Stappers
>
> Foot note
> [1] Part of Happyness is knowing what you have.
> Knowning how dnsmasq behaves (in corner cases) is joyfull.
> Dnsmasq is a server, various clients make it usefull. (As in: There
> is no point in having a server when no clients connect to it.)
More information about the Dnsmasq-discuss
mailing list