<div dir="ltr"><div dir="ltr">" looks like we need</div>--no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly<br>solve your problem."<div><br></div><div>Just to clarify - you are stating that these options don't currently exist and would need to be implemented in a future version?</div><div>I have blocked the request via ebtables on my device for now and this seems to work until a more supported solution is available.</div><div><br></div><div>Also, in regards to the dhcp-options/tag syntax. What is the preferred way to define multiple dhcp-options statements for different scopes?</div><div>It sounds list if I have:</div><div><br></div><div>eth1 with 192.168.1.1</div><div>eth2 with 10.10.10.1</div><div>and</div><div>dhcp-range=192.168.1.50-192.168.1.100<br></div><div>dhcp-range=10.0.0.100-10.0.0.150</div><div><br></div><div>That when the requests come in on those interfaces they will be "automagically" tagged with eth1/eth2. </div><div>You can add additional tags, but they are not strictly necessary.</div><div><br></div><div>dhcp-option=ABC</div><div>dhcp-option=XYZ</div><div><br></div><div>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?</div><div><br></div><div>thanks!</div><div><br></div><div><br></div><div><br><div dir="ltr">On Mon, Apr 10, 2023 at 4:29 PM Simon Kelley <<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 05/04/2023 19:04, Ben Hendin wrote:<br>
> Thanks Simon (apologies - my first reply went to your direct email <br>
> instead of back to the list which was not my intent!)<br>
> <br>
> There are dhcp4 ranges defined, but none with ranges for those interface.<br>
> For example, the interface which should give out the RAs is br0, and the <br>
> relevant lines are:<br>
> <br>
> ra-param=br0,10,600<br>
> enable-ra<br>
> quiet-ra<br>
> dhcp-range=lan,::,constructor:br0,ra-stateless,64,600<br>
> <br>
> But the device has other interfaces, for example br1 and br2 which have <br>
> the following configuration:<br>
> <br>
> interface=br1<br>
> dhcp-range=br1,192.168.101.2,192.168.101.254,255.255.255.0,86400s<br>
> dhcp-option=br1,3,192.168.101.1<br>
> interface=br2<br>
> dhcp-range=br2,192.168.102.2,192.168.102.254,255.255.255.0,86400s<br>
> dhcp-option=br2,3,192.168.102.1<br>
> <br>
> My understanding is that the line "interface=X" (e.g. interface=br1) is <br>
> needed to actually enable dnsmasq to listen *at all* on that interface.<br>
Almost. If there are no "interface=X" options at all, then dnsmasq will <br>
listen on all interfaces.<br>
<br>
> But the use of br1 on the range/option lines is an arbitrary tag to <br>
> simply associate those two options together.<br>
That usage seems to be common folklore, actually it does nothing in this <br>
case. dhcp-option=br1,..... is the same as dhcp-option=set:br1,.... for <br>
long-dead backwards compatibility reasons. So it sets the tag "br1" for <br>
DHCP transactions which arrive via br1. But a tag with the same name as <br>
the interface is always automagically set so a "br1" tag exists anyway, <br>
and the presence of br1 in the dhcp-option has no effect.<br>
<br>
> <br>
> IOW, a particular dhcp-range is not associated with an interface using <br>
> any explicit command, rather if a dhcp-range is defined and an interface <br>
> that is defined with "interface=X" is bound to that subnet it will serve <br>
> requests from the defined range?<br>
<br>
That's correct.<br>
> <br>
> So I do have dhcp4 ranges defined, and I want those serving out those <br>
> IPs on the interfaces that are on those ranges, but I don't expect any <br>
> DHCPv4 traffic to be answered on br0.<br>
> <br>
> I'm sure I can write iptable rules to block that, but something tells me <br>
> that isn't the elegant way and perhaps there is a dnsmasq configuration <br>
> methodology that I am overlooking???<br>
<br>
<br>
The whole interface= access control started when dnsmasq only did DNS, <br>
and when DHCP was added it defaulted to doing both services on the same <br>
set of interfaces, which is sensible default. To account for <br>
configurations where DNS would be provided on interfaces where DHCP <br>
wasn't wanted, the --no-dhcp-interface option was added. (Providing DHCP <br>
on an interface but not DNS is not supported.) Logically, now that DHCP <br>
has bifurcated into DHCPv4 and DHCPv6 it looks like we need <br>
--no-dhcpv4-interface and --no-dhcpv6-interface. That would certainly <br>
solve your problem.<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
> <br>
> On Wed, Apr 5, 2023 at 12:33 PM Simon Kelley <<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a> <br>
> <mailto:<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>>> wrote:<br>
> <br>
> <br>
> <br>
> On 03/04/2023 16:54, Ben Hendin wrote:<br>
> > I'm running Dnsmasq version 2.85-openssl-5-g989ee98 on an embedded<br>
> > device (Entware installation)<br>
> ><br>
> > I am seeing log entries that state the following when clients<br>
> come onto<br>
> > the network to request IP addresses via DHCP:<br>
> ><br>
> > "no address range available for DHCP request via br0"<br>
> ><br>
> > br0 is a bridged interface that includes the LAN and main WiFi of<br>
> the<br>
> > embedded device.<br>
> ><br>
> > The issue is that I do not use dnsmasq on this device for DHCP on<br>
> this<br>
> > interface.<br>
> > (I do have it configured to deliver dhcp-range information to<br>
> some other<br>
> > wireless interfaces.)<br>
> > The main function on this interface is DNS and to deliver RAs for<br>
> IPv6.<br>
> ><br>
> > It appears, in order to deliver RAs to my clients the following<br>
> lines<br>
> > must be configured:<br>
> ><br>
> > -------------------<br>
> > interface=br0<br>
> > ra-param=br0,10,600<br>
> > enable-ra<br>
> > dhcp-range=lan,::,constructor:br0,ra-stateless,64,600<br>
> > -----------------------<br>
> ><br>
> > In other words, dhnsmasq must be configured to deliver the<br>
> "dhcp-range"<br>
> > option in order to deliver RAs (enable-ra isn't enough)<br>
> > Because of this you can't use the "no-dhcp-interface=br0" option<br>
> or else<br>
> > the dhcp-range and therefore the RA will not get delivered to<br>
> clients.<br>
> ><br>
> > When a client joins the network, it requests an IPv4 address,<br>
> which will<br>
> > not be served by dnsmasq, but by another authoritative server on the<br>
> > network.<br>
> > However, because dnsmasq is configured to provide DHCP services,<br>
> yet has<br>
> > no IPv4 range defined it spits out the "no address range available"<br>
> ><br>
> > I have tried changing the "ra-stateless" option to "slaac" or<br>
> "ra-only"<br>
> > as the description of "ra-only" seems to indicate that dnsmasq<br>
> will then<br>
> > be made aware it is only to deliver RAs and not DHCP (though perhaps<br>
> > this only registers for v6). I have also tried to use<br>
> "quiet-dhcp" to<br>
> > suppress these unsuccessfully. Because the message is still<br>
> logged, it<br>
> > would fall under "error or problem" according to "quiet-dhcp"<br>
> > specifications.<br>
> ><br>
> > Is this behavior expected? If so, is it considered preferable or<br>
> should<br>
> > dnsmasq have some configuration where it should not assume that<br>
> an IPv4<br>
> > range being unconfigured is an issue worth notifying about in<br>
> scenarios<br>
> > like this?<br>
> ><br>
> <br>
> That's not expected behaviour. The log does indeed imply that this is a<br>
> DHCPv4 request (it would say no address range available for DHCPv6) but<br>
> unless there's a valid IPv4 dhcp-range defined dnsmasq should not even<br>
> be listening on the DHCPv4 port. The current code doesn't, and I don't<br>
> remember any fixes to this the 2.85-2.89 timeframe.<br>
> <br>
> What does dnsmasq log when it starts up? The most obvious explantion<br>
> for<br>
> this is that Entware's startup is defining a DHCPv4 range somewhere in<br>
> the config that gets passed to dnsmasq.<br>
> <br>
> <br>
> Cheers,<br>
> <br>
> Simon.<br>
> <br>
> <br>
> > thank you<br>
> ><br>
> > _______________________________________________<br>
> > Dnsmasq-discuss mailing list<br>
> > <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a>><br>
> ><br>
> <a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a> <<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>><br>
> <br>
> _______________________________________________<br>
> Dnsmasq-discuss mailing list<br>
> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <mailto:<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a>><br>
> <a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a> <<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>><br>
> <br>
> <br>
> _______________________________________________<br>
> Dnsmasq-discuss mailing list<br>
> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div></div></div>