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 <si...@thekelleys.org.uk
<mailto:si...@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@lists.thekelleys.org.uk
<mailto:Dnsmasq-discuss@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@lists.thekelleys.org.uk
<mailto:Dnsmasq-discuss@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@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
