DHCPv4 needs to be running on other interfaces because there are guest networks.
E.g. May 5 18:15:14 dnsmasq-dhcp[9209]: DHCP, IP range 192.168.203.2 -- 192.168.203.254, lease time 1d May 5 18:15:14 dnsmasq-dhcp[9209]: DHCP, IP range 192.168.202.2 -- 192.168.202.254, lease time 1d May 5 18:15:14 dnsmasq-dhcp[9209]: DHCP, IP range 192.168.201.2 -- 192.168.201.254, lease time 1d Nothing in the log clearly explains what interfaces those ranges are assigned to, but in the config they are br1, br2, br3. The br0 interface does *not* have an IPv4 range configured and should be DHCPv6 only. Yet, Dnsmasq is still receiving DHCPv4 messages on br0, processing, and spamming the log saying that a range isn’t configured. > On Apr 29, 2021, at 4:10 PM, Simon Kelley <si...@thekelleys.org.uk> wrote: > > On 24/04/2021 04:28, Aaron Oneal wrote: >> Geert, thank you that is a creative solution. I wasn’t able to determine how >> to configure that so I determined a way to change my network topology >> instead to work around. >> >> Simon, thank you for your assistance. Let me see if I can help track this >> down. >> >> Dnsmasq is listening on 67: >> udp 0 0 0.0.0.0:67 >> 0.0.0.0:* PID/dnsmasq >> >> Nothing logged on startup in syslog other than: >> Apr 23 20:13:14 dnsmasq-dhcp[PID]: no address range available for DHCP >> request via br0 >> >> ASUS router with this firmware: >> https://github.com/RMerl/asuswrt-merlin.ng >> >> Dnsmasq version: >> Dnsmasq version 2.84-42-g433dc70 Copyright (c) 2000-2021 Simon Kelley >> Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN >> DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-auth cryptohash DNSSEC no-ID >> loop-detect no-inotify no-dumpfile >> >> Line generating the error (rfc2131.c Line 345): >> https://github.com/imp/dnsmasq/blob/master/src/rfc2131.c >> >> > > By far the simplest explanation for this is that the dnsmasq config is > enabling DHCPv4. If the Asus firmware is anything like OpenWRT, it will > do all sorts of stuff behind the scenes. Before doing anything else, we > need to find out what dnsmasq is reporting as its config. The easiest > way to do that might be to redirect all the dnsmasq logging to a file > using something like > > log-facility=/path/to/file > > and then restart dnsmasq (if you can) or reboot the whole system. > > > Cheers, > > Simon. > > >>> On Apr 23, 2021, at 10:48 AM, Simon Kelley <si...@thekelleys.org.uk> wrote: >>> >>> On 21/04/2021 19:41, Aaron Oneal wrote: >>>> I am trying to configure my gateway running Dnsmasq to serve IPv6 >>>> addresses via SLAAC+RA and I don’t see how to enable that in a way that >>>> doesn’t also require IPv4 DHCP to be turned on. >>>> >>>> interface=br0 >>>> dhcp-range=lan,::,constructor:br0,ra-stateless,64,600 >>>> ra-param=br0,10,600 >>>> enable-ra >>>> >>>> I already have a different server on the LAN that handles IPv4 DHCP so I >>>> don’t want Dnsmasq doing it. >>>> >>>> The problem is, Dnsmasq listens on IPv4 anyway and every time it receives >>>> an IPv4 DHCP message it spams my syslog with dozens of messages per second >>>> saying "no address range available for DHCP request via br0." I didn’t >>>> specify an IPv4 range because I don’t want one. >>>> >>>> I tried using `listen-address=<ipv6 addresses>` instead of `interface=br0` >>>> but then RA doesn’t seem to be active and my devices stop receiving IPv6 >>>> addresses. >>>> >>>> I can’t remove the IPv4 address from the interface because it’s a gateway. >>>> >>>> Is there a way to configure Dnsmasq for IPv6 only? >>> >>> >>> What you're doing should configure dnsmasq for IPv6 only, and a naive >>> attempt to reproduce you setup doesn't seem to have the same problem. >>> It's certainly not listening on IPv4 UDP port 68, which it would be if >>> serving DHCPv4. >>> >>> Please could you let us know what version of dnsmasq you are running, >>> and what it logs at start-up? That would help to reproduce the bug at >>> this end. >>> >>> >>> Simon. >> >>> On Apr 21, 2021, at 1:09 PM, Geert Stappers via Dnsmasq-discuss >>> <dnsmasq-discuss@lists.thekelleys.org.uk> wrote: >>> >>> Path I would go is configuring dnsmasq to only IPv4 DHCP reply to known >>> MAC-addresses. And than have a MAC address configured that none of the >>> clients has. No, I never have travelled that path. I do like to known >>> if it lead to the wanted goal. >>> >>> >>> Groeten >>> Geert Stappers
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss