Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-12 Thread Simon Kelley 



On 11/04/2023 14: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?


Affirmative. I've just implemented them for the next release.

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.

Correct


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?




It doesn't. You need to specify which one gets used with tags. Just 
using the automatically provided interface name tags is enough in this case.


dhcp-option=tag:eth1,ABC
dhcp-option=tag:eth2,XYZ


tagged options are used when the tag(s) match, with fallback to untagged 
options. If there's more than one possible option, which one actually 
gets used is undefined.


Simon.



thanks!



On Mon, Apr 10, 2023 at 4:29 PM Simon Kelley > 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
mailto:si...@thekelleys.org.uk>
 > >>

Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-11 Thread Petr Menšík 
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  
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
 > wrote:
>
>
>
>     On 03/04/2023 16:54, Ben Hendin wrote:
>      > I'm running Dnsmasq version 2.85-openssl-5-g989ee98

Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-11 Thread Ben Hendin 
" 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 
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  > > 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

Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-10 Thread Simon Kelley 



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 > 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.   

Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-05 Thread Ben Hendin 
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.
But the use of br1 on the range/option lines is an arbitrary tag to simply
associate those two options together.

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?

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???

On Wed, Apr 5, 2023 at 12:33 PM Simon Kelley 
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
> > 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
>
___

Re: [Dnsmasq-discuss] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-05 Thread Simon Kelley 



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
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] "no address range available for DHCP request via br0" when using for IPv6 RA

2023-04-03 Thread Ben Hendin 
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?

thank you
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss