[Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA
Simon Kelley
simon at thekelleys.org.uk
Wed Apr 12 22:09:07 UTC 2023
On 11/04/2023 14:04, Ben Hendin wrote:
> " 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?
Affirmative. I've just implemented them for the next release.
> 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.
Correct
>
> 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?
>
It doesn't. You need to specify which one gets used with tags. Just
using the automatically provided interface name tags is enough in this case.
dhcp-option=tag:eth1,ABC
dhcp-option=tag:eth2,XYZ
tagged options are used when the tag(s) match, with fallback to untagged
options. If there's more than one possible option, which one actually
gets used is undefined.
Simon.
> thanks!
>
>
>
> On Mon, Apr 10, 2023 at 4:29 PM Simon Kelley <simon at thekelleys.org.uk
> <mailto: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>
> > <mailto: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>
> > <mailto: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> <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>
> > <mailto: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> <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
> <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
More information about the Dnsmasq-discuss
mailing list