[Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA
Petr Menšík
pemensik at redhat.com
Tue Apr 11 14:43:12 UTC 2023
I think every incoming device tags dhcp requests with tag of that
interface name.
Therefore it should be possible:
dhcp-range=tag:eth1,192.168.1.50-192.168.1.100
dhcp-range=tag:eth2,10.0.0.100-10.0.0.150
If you enable --log-dhcp for extra details logged, it should log for
each query all tags it has set. Incoming device should be among those
tags. Similarly with dhcp-option, specific tag can be changed to apply
only on some interface.
On 4/11/23 15: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?
> 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
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20230411/b1201e2f/attachment-0001.htm>
More information about the Dnsmasq-discuss
mailing list