[Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

[Ben Hendin]

Thanks Simon (apologies - my first reply went to your direct email instead
of back to the list which was not my intent!)

There are dhcp4 ranges defined, but none with ranges for those interface.
For example, the interface which should give out the RAs is br0, and the
relevant lines are:

ra-param=br0,10,600
enable-ra
quiet-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

But the device has other interfaces, for example br1 and br2 which have the
following configuration:

interface=br1
dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s
dhcp-option=br1,3,192.168.101.1
interface=br2
dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s
dhcp-option=br2,3,192.168.102.1

My understanding is that the line "interface=X" (e.g. interface=br1) is
needed to actually enable dnsmasq to listen *at all* on that interface.
But the use of br1 on the range/option lines is an arbitrary tag to simply
associate those two options together.

IOW, a particular dhcp-range is not associated with an interface using any
explicit command, rather if a dhcp-range is defined and an interface that
is defined with "interface=X" is bound to that subnet it will serve
requests from the defined range?

So I do have dhcp4 ranges defined, and I want those serving out those IPs
on the interfaces that are on those ranges, but I don't expect any DHCPv4
traffic to be answered on br0.

I'm sure I can write iptable rules to block that, but something tells me
that isn't the elegant way and perhaps there is a dnsmasq configuration
methodology that I am overlooking???

On Wed, Apr 5, 2023 at 12:33 PM Simon Kelley <simon at thekelleys.org.uk>
wrote:

>
>
> 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 at lists.thekelleys.org.uk
> > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20230405/3a15f8be/attachment-0001.htm>