[Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA
Ben Hendin
bhendin at gmail.com
Tue Apr 11 13:04:25 UTC 2023
" looks like we need
--no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly
solve your problem."
Just to clarify - you are stating that these options don't currently exist
and would need to be implemented in a future version?
I have blocked the request via ebtables on my device for now and this seems
to work until a more supported solution is available.
Also, in regards to the dhcp-options/tag syntax. What is the preferred way
to define multiple dhcp-options statements for different scopes?
It sounds list if I have:
eth1 with 192.168.1.1
eth2 with 10.10.10.1
and
dhcp-range=192.168.1.50-192.168.1.100
dhcp-range=10.0.0.100-10.0.0.150
That when the requests come in on those interfaces they will be
"automagically" tagged with eth1/eth2.
You can add additional tags, but they are not strictly necessary.
dhcp-option=ABC
dhcp-option=XYZ
How does dnsmasq know which of those two defined options to provide to
clients in their respective scopes if I have not configured a tag, or
somehow correlated them to each individual range?
thanks!
On Mon, Apr 10, 2023 at 4:29 PM Simon Kelley <simon at thekelleys.org.uk>
wrote:
>
>
> On 05/04/2023 19:04, Ben Hendin wrote:
> > 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.
> Almost. If there are no "interface=X" options at all, then dnsmasq will
> listen on all interfaces.
>
> > But the use of br1 on the range/option lines is an arbitrary tag to
> > simply associate those two options together.
> That usage seems to be common folklore, actually it does nothing in this
> case. dhcp-option=br1,..... is the same as dhcp-option=set:br1,.... for
> long-dead backwards compatibility reasons. So it sets the tag "br1" for
> DHCP transactions which arrive via br1. But a tag with the same name as
> the interface is always automagically set so a "br1" tag exists anyway,
> and the presence of br1 in the dhcp-option has no effect.
>
> >
> > 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?
>
> That's correct.
> >
> > 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???
>
>
> The whole interface= access control started when dnsmasq only did DNS,
> and when DHCP was added it defaulted to doing both services on the same
> set of interfaces, which is sensible default. To account for
> configurations where DNS would be provided on interfaces where DHCP
> wasn't wanted, the --no-dhcp-interface option was added. (Providing DHCP
> on an interface but not DNS is not supported.) Logically, now that DHCP
> has bifurcated into DHCPv4 and DHCPv6 it looks like we need
> --no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly
> solve your problem.
>
>
> Cheers,
>
> Simon.
>
> >
> > On Wed, Apr 5, 2023 at 12:33 PM Simon Kelley <simon at thekelleys.org.uk
> > <mailto: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
> > <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
> > >
> >
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss <
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss>
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
> >
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss <
> 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
>
> _______________________________________________
> 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/20230411/fc50269d/attachment.htm>
More information about the Dnsmasq-discuss
mailing list