Re: [Dnsmasq-discuss] Defending IP address
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-
[Dnsmasq-discuss] Monthly posting
Hi, "How To Ask Questions The Smart Way" has immediately after the introduction an advice on before you ask. http://www.catb.org/esr/faqs/smart-questions.html#before Following that advice is still no guarantee for a (good) response. So when you are still stuck with something that you think it is dnsmasq related, you have to make more effort. Greatest challenge is most likely being persistent in solving the problem. ( Not being persistent in demanding an answer. ) The dnsmasq man page is feature complete. And known as "hard to read" for those who are new to it. But still do read it and try to understand it. Reading it again is known being effective for getting better understanding. Find a copy of it in source code of dnsmasq and read it by `man man/dnsmasq.8`, or when installed by `man dnsmasq` or at https://dnsmasq.org/docs/dnsmasq-man.html Pattern seen on the mailing list is unawareness of network-server-client-model. Expressing such problems is indeed hard, but also the road to a solution. Know that you are the main stake holder of the problem that you are facing. The highest reward for finding a solution goes to you. Keep the eco system that you are consulting healthy by sharing also your success stories. Avoid "DNS doesn't work", make it "My DNS client gets odd replies from dnsmasq", "My DNS requests don't get forwarded" or another non-generic issue. Use real DNS client tools like `dig` or `host` (instead of `ping`). Set the configuration --log-queries. That will allow you to see if the queries are getting to dnsmasq, and it will give you a full dump of the DNS cache (including DHCP derived names) if you send the dnsmasq process SIGUSR1. Both of these will help in diagnosing the problem. For non-biased views is networksniffing recommented. When `tcpdump` or `wireshark` is used for such examinations, provide the mailinglist with an URL to `.pcap`-file. Karma bonus points for providing an URL that can be `wget`. So prevent that your community members get exposed to websites that scream advertisements or the need for JavaScript. Text version output of network sniffs don't show up well after being put in an email. Please take the pain of uploading an .pcap file insteadof multipling the pain of malformed netsniffer output. In case of got stuck in finding a solution, describe also the original problem you wanted to solve. ( See also https://xyproblem.info/ which starts with: The XY problem is asking about your attempted solution rather than your actual problem. This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. ) Dnsmasq is a mature project, meaning not often a release. However we constantly want to improve. Yes, patches welcome. Patches are not always reviewed within three days. Retransmit of your review request after four days is not too pushy. Aim for common interest. If you find it here, fine. If you cannot find it here, you might found a clue for looking elsewhere on "common interest". Do know there are real humans behind the email addresses. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Defending IP address
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
Re: [Dnsmasq-discuss] Defending IP address
On Sat, 6 May 2023 19:03:21 +0200, Geert Stappers wrote: > Let's assume there is > > } xx:xx:xx:xx:xx:aa,192.168.1.10,dnsmasq.squirrel.nl,24h True. System name is srv1 but that does not matter. > > # 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. As I mentioned earlier... > My stab on how it breaks: > * a new DHCP client asks for 192.168.1.10 It does not ask -- that would be a DHCPREQUEST, e.g. DHCPREQUEST(eth0) 192.168.1.10 xx:xx:xx:xx:xx:xx If merely says 'I have' (claims). > * dnsmasq unaware that 192.168.1.10 is intended for its self If it were a DHCPREQUEST, dnsmasq would DENY since the address is tied to a different mac. But it's not. It is totally unrelated to dnsmasq. It is dhcpcd that reacts to the 'claim'. > There is an unknown ascpect on this interesting problem: > Why are the IoT devices asking for 192.168.1.10? The suspect IoT devices run ESPHome on BK7231 chips. Support for these chips is under development. They still crash frequently. My guess is that the device stores the IP number of the DHCP/DNS server somewhere in flash and when recovering from a crash by mistake take this to be their own address. Preliminary conclusion is that 1. dnsmasq is not involved, and that 2. dhcpcd may be behaving according to the rules. In short: * The system starts, dhcpcd starts, and brings up the interface with the static address 192.168.1.10 as configured in /etc/dhcpcd.conf . (I don't think it does DHCP since it has a static address.) * Some time later, someone else tells dhcpcd "Hey! *I* am 192.168.1.10" * If within 10 seconds there is a second "Hey! *I* am 192.168.1.10" dhcpcd assumes it is not correctly configured and drops the interface. For my setup the correct solution is, as Geoff mentioned, to disable dhcpcd and set the static address in /etc/network/interfaces instead. As for the probably misbehaving IoT devices, I have filed and issue at the developer site. -- Johan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Defending IP address
On Sat, 6 May 2023 11:17:22 -0700, A C wrote: > 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. If so, I have been unable to find it... Sorry for that. Can you give the link? -- Johan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Defending IP address
I lost the link, I did t a lot of searching which kept coming up with the dhcpcd.conf method and by all accounts many people have problems similar to what you did where the interface has issues in multi-device environments. There's a bunch of threads on places like stackexchange and the Rasberry Pi foundation blog about the correct way to do this and the vast majority indicate that the originally suggested method of dhcpcd.conf (which was introduced in 2015) is too fragile so the two fallback methods are /etc/network/interfaces and systemd-networkd files or even NetworkManager (which I don't particularly like in general) but according to this[1] post on the foundation blog NetworkManager replaced dhcpcd as the suggested method for handling network interfaces. I redid a search and came up with this nice long and heated thread about it: https://raspberrypi.stackexchange.com/questions/37920/how-do-i-set-up-networking-wifi-static-ip-address-on-raspbian-raspberry-pi-os Here is systemd-networkd static IP: https://wiki.archlinux.org/title/systemd-networkd And of course /etc/network/interfaces: https://wiki.debian.org/NetworkConfiguration In any event, you're operating a server (because you're running dnsmasq on your Pi) therefore you should not be running DHCP on your server's interfaces so there's no reason to involve dhcpcd at all[2]. Switch to a known working method of assigning a static IP (either the interfaces file, systemd-networkd, or NetworkManager) and you will be far better off in the long run. [1] https://www.raspberrypi.com/news/the-latest-update-to-raspberry-pi-os/ [2] The only exception to this would be a Pi running as a router in which case the WAN interface might likely use DHCP to obtain an IP from the ISP/modem but otherwise DHCP should be disabled on anything but the WAN interface if the router is also your internal DHCP server. On 2023-05-06 12:00, Johan Vromans wrote: On Sat, 6 May 2023 11:17:22 -0700, A C wrote: 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. If so, I have been unable to find it... Sorry for that. Can you give the link? -- Johan ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
