On 03/04/2023 16:54, Ben Hendin wrote:
I'm running Dnsmasq version 2.85-openssl-5-g989ee98 on an embedded
device (Entware installation)
I am seeing log entries that state the following when clients come onto
the network to request IP addresses via DHCP:
"no address range available for DHCP request via br0"
br0 is a bridged interface that includes the LAN and main WiFi of the
embedded device.
The issue is that I do not use dnsmasq on this device for DHCP on this
interface.
(I do have it configured to deliver dhcp-range information to some other
wireless interfaces.)
The main function on this interface is DNS and to deliver RAs for IPv6.
It appears, in order to deliver RAs to my clients the following lines
must be configured:
-------------------
interface=br0
ra-param=br0,10,600
enable-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
-----------------------
In other words, dhnsmasq must be configured to deliver the "dhcp-range"
option in order to deliver RAs (enable-ra isn't enough)
Because of this you can't use the "no-dhcp-interface=br0" option or else
the dhcp-range and therefore the RA will not get delivered to clients.
When a client joins the network, it requests an IPv4 address, which will
not be served by dnsmasq, but by another authoritative server on the
network.
However, because dnsmasq is configured to provide DHCP services, yet has
no IPv4 range defined it spits out the "no address range available"
I have tried changing the "ra-stateless" option to "slaac" or "ra-only"
as the description of "ra-only" seems to indicate that dnsmasq will then
be made aware it is only to deliver RAs and not DHCP (though perhaps
this only registers for v6). I have also tried to use "quiet-dhcp" to
suppress these unsuccessfully. Because the message is still logged, it
would fall under "error or problem" according to "quiet-dhcp"
specifications.
Is this behavior expected? If so, is it considered preferable or should
dnsmasq have some configuration where it should not assume that an IPv4
range being unconfigured is an issue worth notifying about in scenarios
like this?
That's not expected behaviour. The log does indeed imply that this is a
DHCPv4 request (it would say no address range available for DHCPv6) but
unless there's a valid IPv4 dhcp-range defined dnsmasq should not even
be listening on the DHCPv4 port. The current code doesn't, and I don't
remember any fixes to this the 2.85-2.89 timeframe.
What does dnsmasq log when it starts up? The most obvious explantion for
this is that Entware's startup is defining a DHCPv4 range somewhere in
the config that gets passed to dnsmasq.
Cheers,
Simon.
thank you
_______________________________________________
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
