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 <si...@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
<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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@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
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
