<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I think every incoming device tags dhcp requests with tag of that
interface name.</p>
<p>Therefore it should be possible:</p>
<div>dhcp-range=tag:eth1,192.168.1.50-192.168.1.100<br>
</div>
<div>dhcp-range=tag:eth2,10.0.0.100-10.0.0.150</div>
<div><br>
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.<br>
</div>
<p></p>
<div class="moz-cite-prefix">On 4/11/23 15:04, Ben Hendin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAd7aubQiP4V6j4M1nehiW=8Y2Hga06-BBDTO0fQgXZgAq-E5A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">simon@thekelleys.org.uk</a>
<br>
> <mailto:<a href="mailto:simon@thekelleys.org.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <mailto:<a
href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <mailto:<a
href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Dnsmasq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</a>
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>