"no address range available for DHCP request via br0" - dnsmaq/IPv6 experts needed...

[bengalih]

So let me start off by saying that everything appears to be working as normal, however I'm not sure exactly what this message means (though I have good idea), if I can get rid of it, and if perhaps I have a misconfiguration that is causing it (and therefore can do something to optimize my config). As the very least, I'll consider this an educational exercise to determine why it is happening and how to prevent it, or if it can't be prevented to understand why:

I'm getting the following messages in my syslog:

dnsmasq-dhcp[6913]: no address range available for DHCP request via br0

They appear to be happening whenever a client on my main WiFi is requesting an IP address.
It appears to be logged up to two times per client request. My assumption is once for IPv4 and once for IPv6 address.
(They may happen on the LAN interface too, but I don't have any devices using DHCP on that interface, so I can't confirm).
I did tests on multiple versions of Android clients and a Windows client. All but one android support IPv6 and those seem to log 2 entries when reconnecting to WiFi.
The Windows 10 client appears to log only one entry when disabling/enabling WiFi, but 2 entries if I do a manual "ipconfig release/renew"

I have quite a bit of customization on my device*, including multiple WiFi guest networks, but I'm not sure how relevant those are since this is happening on my main WiFi network.

I think the most important thing to note is that my router does *not* provide IP addresses for my main network (LAN + main WiFi).
DHCP is disabled in the GUI and I have a separate Windows DHCP server that provides IPv4 addresses to these clients.

I also do not provide IPv6 addresses via any DHCP server. Rather under the router's IPv6 configuration I am using a Static IPv6 config with "Stateless" Auto Configuration enabled along with RA.
My understanding of how this works is that the "LAN IPv6" prefix (64 bits) is provided to my clients through the Router Advertisements and then my clients create their own address based upon their MAC address.
dnsmasq on my router is configured to hand out IPv4 addresses via DHCP to my guest networks. Currently my guest networks do not get any IPv6 information (though I plan to look into configuring how to get the RAs to send to send to those interfaces as well for SLAAC).

Here are the relevant portions of my dnsmasq.conf file (some definitely non-essential stuff removed):

no address range available for DHCP request via br0

no address range available for DHCP request via br0 - dnsmasq.conf

gist.github.com

If I add the following to dnsmasq.conf the issue disappears:

no-dhcp-interface=br0

However, this also prevents the RAs from going out and therefore no clients get proper IPv6 configuration.

Is this message wholly informational and if so, is there no way to suppress it?
Is there anything wrong with my configuration that would be causing this?
I've tried manipulation of several things including the line:

dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

tried using ra-only instead of ra-stateless under the hope that it would let the DHCP server no that I am not trying to serve out an range, only RAs, but still no luck.
It seems to me strange that sending out RAs is dependent on having dhcp-range set as RAs should not technically be a feature of DHCP.
So I can't turnoff the interface from listening on DHCP if all I want to do is sent out the RAs.

 

[drinkingbird]

The fact that you have DHCP disabled

I think the most important thing to note is that my router does *not* provide IP addresses for my main network (LAN + main WiFi).
DHCP is disabled in the GUI and I have a separate Windows DHCP server that provides IPv4 addresses to these clients.

There is your key. Disabling DHCP means no DHCP scopes are assigned, but the router is still hearing the requests. You could probably use some scripts to clean it up and make dnsmasq not listen at all but the errors are cosmetic, if your DHCP is working fine using the external server then it isn't hurting anything.

It is possible if you did a full factory reset with WPS button and then reconfigured from scratch disabling DHCP, it might clear out the extra configs, but that's a big "maybe".

 

[bengalih]

The fact that you have DHCP disabled


There is your key. Disabling DHCP means no DHCP scopes are assigned, but the router is still hearing the requests. You could probably use some scripts to clean it up and make dnsmasq not listen at all but the errors are cosmetic, if your DHCP is working fine using the external server then it isn't hurting anything.

It is possible if you did a full factory reset with WPS button and then reconfigured from scratch disabling DHCP, it might clear out the extra configs, but that's a big "maybe".

I don't think there are any "extra configs". When the router is first configured, I never configured DHCP in the first place because I always use my external server for DHCP.

I understand that that the "key" issue here is that dnsmasq is saying I don't have any addresses available for that interface *because* I have not configured any addresses for that interface - that point is clear.

This however seems like an error with dnsmasq and IPv6 configurations. In order for the IPv6 RA to function it appears that the following line needs to exist:

interface=br0

Additionally, you can't disable dhcp on this interface with the following:

no-dhcp-interface=br0

This is because in order for RAs to send they have to be both enabled, and configured for that interface with the following:

ra-param=br0,10,600
enable-ra
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600

In other words, dnsmasq seems to require a dhcp-range command in order to deliver RAs, which seems a bit strange since RAs are not dependent on DHCP.

This could be a minor *bug* in dnsmasq that it didn't account for these configurations where someone would be running only RAs and not any DHCP ranges. However, it could be that I have not configured it optimally, which is why I am seeking review by someone who knows these services intimately.

I have some confusion over the interface being set to br0, but the dhcp-range being lan as here:

interface=br0
...
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
dhcp-option=lan,option6:23,[::]
dhcp-option=lan,option6:24,XXXXXX.local

And wondering if there was maybe another way to construct this on this device (I've never been great at understanding all the interfaces: br0, lan, ethX, etc on the device).

If there is nothing I can do but live with the error/warning, so be it, but something about this doesn't sit right with me.

 

[drinkingbird]

I have some confusion over the interface being set to br0, but the dhcp-range being lan as here:

interface=br0
...
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
dhcp-option=lan,option6:23,[::]
dhcp-option=lan,option6:24,XXXXXX.local

And wondering if there was maybe another way to construct this on this device (I've never been great at understanding all the interfaces: br0, lan, ethX, etc on the device).

If there is nothing I can do but live with the error/warning, so be it, but something about this doesn't sit right with me.

BR0 is a combination of the LAN switch and the wifi interfaces (non-guest ones). BR0 is where the LAN IP is put and the DHCP range associated. BR1 and BR2 get used if you have guest wireless 1 in use (may differ between router models though).

My guess would be they did not account for people wanting RAs but not DHCP. LAN is just the name of the DHCP range/scope, br0 is the interface it is bound to. I'm not intimately familiar with dnsmasq and v6 but normally to disable DHCP you just comment out all the DHCP related lines in the config file (which you can do with a dnsmasq.postconf script). That should not affect RA as those are configured using other parts of the config file. Give it a try, restart dnsmasq, see how it works.

Do you have the router set to stateless? One would think that would disable DHCP leaving only RAs.

 

[bengalih]

BR0 is a combination of the LAN switch and the wifi interfaces (non-guest ones). BR0 is where the LAN IP is put and the DHCP range associated. BR1 and BR2 get used if you have guest wireless 1 in use (may differ between router models though).

Thanks - I have at least that basic understanding of BR0. On my device the guest wireless are wl0.1, wl0.2, wl1.1, etc.

My guess would be they did not account for people wanting RAs but not DHCP.

That's my guess as well, though I'm sure I'm not the only one who doesn't use the on-box DHCP for IPv4 yet depends on the router for IPv6 RAs.

LAN is just the name of the DHCP range/scope, br0 is the interface it is bound to.

This is what I was most confused about because "lan" is not s special term for dnsmasq, nor does it appear to be an interface (nothing with ifconfig). For instance I have the following lines for my wifi:

interface=wl0.1
dhcp-range=wl0.1,172.20.20.150,172.20.20.199,255.255.255.0,86400s
dhcp-option=wl0.1,3,172.20.20.1
dhcp-option=wl0.1,6,1.1.1.1,1.0.0.1


interface=wl1.1
dhcp-range=wl1.1,172.20.30.150,172.20.30.199,255.255.255.0,86400s
dhcp-option=wl1.1,3,172.20.30.1
dhcp-option=wl1.1,6,1.1.1.1,1.0.0.1


interface=wl0.2
dhcp-range=wl0.2,10.10.20.50,10.10.20.199,255.255.255.0,86400s
dhcp-option=wl0.2,3,10.10.20.1
dhcp-option=wl0.2,6,1.1.1.1,1.0.0.1

The interface lines I believe each state for dnsmasq to listen on each interface I have a line for. I though that the dhcp-range option first value (i.e. wl0.1) was required to match the interface. But, upon reviewing the dnsmaq man page it appears that is simply a tag to match it to the dhcp-option fields and does not need to match the interface name. So I see the term "lan" here is purely arbitrary (though descriptive) and probably would have been better to say "br0" so it matches the actual interface name. I suspect "lan" is used instead since the interface may be different on different models.

I'm not intimately familiar with dnsmasq and v6 but normally to disable DHCP you just comment out all the DHCP related lines in the config file (which you can do with a dnsmasq.postconf script). That should not affect RA as those are configured using other parts of the config file. Give it a try, restart dnsmasq, see how it works.

Yes - no unnecessary DHCP is configured since DHCP is disabled via the GUI and the only DHCP commands that exist are the ones I added to support my guest WiFi. As I stated above if you remove the basic DHCP options for br0, then RAs don't function. I've tried multiple scenarios.

Do you have the router set to stateless? One would think that would disable DHCP leaving only RAs.

Yes I have been using stateless. I did a test moving to stateful and it did not help.
Even if it did, I would be unable to use that since Android clients don't properly support stateful implementations (dumb!).
The only way I was able to prevent that message from appearing (while still getting RAs) was to actually enable an IPv4 range.
Of course, I don't want that because I have another server as DHCP.

These are the possible solutions:
1) enable dhcp logging and redirect to another file and while you will get more output overall, you won't see this noise in syslog
2) enable IPv4 range of a single address and then also set a client reservation for a non-existent client. That way a range will exist, but no clients will get any. I haven't actually tried this yet, but it should work theoretically. I do wonder though if it will slow down other DHCP requests from the main server (?).
3) Just ignore it - which honestly I'm happy to do assuming that it really is just a dumb cosmetic message for a poorly tested case scenario. I just want to make sure that my configuration is optimal and this couldn't be avoided.

I have posted this to the dnsmasq mailing list in hope to find out if this is expected and/or a better way to configure.
If I get any feedback there I will update the thread.

 

[drinkingbird]

Thanks - I have at least that basic understanding of BR0. On my device the guest wireless are wl0.1, wl0.2, wl1.1, etc.

That's my guess as well, though I'm sure I'm not the only one who doesn't use the on-box DHCP for IPv4 yet depends on the router for IPv6 RAs.

This is what I was most confused about because "lan" is not s special term for dnsmasq, nor does it appear to be an interface (nothing with ifconfig). For instance I have the following lines for my wifi:

interface=wl0.1
dhcp-range=wl0.1,172.20.20.150,172.20.20.199,255.255.255.0,86400s
dhcp-option=wl0.1,3,172.20.20.1
dhcp-option=wl0.1,6,1.1.1.1,1.0.0.1


interface=wl1.1
dhcp-range=wl1.1,172.20.30.150,172.20.30.199,255.255.255.0,86400s
dhcp-option=wl1.1,3,172.20.30.1
dhcp-option=wl1.1,6,1.1.1.1,1.0.0.1


interface=wl0.2
dhcp-range=wl0.2,10.10.20.50,10.10.20.199,255.255.255.0,86400s
dhcp-option=wl0.2,3,10.10.20.1
dhcp-option=wl0.2,6,1.1.1.1,1.0.0.1

The interface lines I believe each state for dnsmasq to listen on each interface I have a line for. I though that the dhcp-range option first value (i.e. wl0.1) was required to match the interface. But, upon reviewing the dnsmaq man page it appears that is simply a tag to match it to the dhcp-option fields and does not need to match the interface name. So I see the term "lan" here is purely arbitrary (though descriptive) and probably would have been better to say "br0" so it matches the actual interface name. I suspect "lan" is used instead since the interface may be different on different models.


Yes - no unnecessary DHCP is configured since DHCP is disabled via the GUI and the only DHCP commands that exist are the ones I added to support my guest WiFi. As I stated above if you remove the basic DHCP options for br0, then RAs don't function. I've tried multiple scenarios.


Yes I have been using stateless. I did a test moving to stateful and it did not help.
Even if it did, I would be unable to use that since Android clients don't properly support stateful implementations (dumb!).
The only way I was able to prevent that message from appearing (while still getting RAs) was to actually enable an IPv4 range.
Of course, I don't want that because I have another server as DHCP.

These are the possible solutions:
1) enable dhcp logging and redirect to another file and while you will get more output overall, you won't see this noise in syslog
2) enable IPv4 range of a single address and then also set a client reservation for a non-existent client. That way a range will exist, but no clients will get any. I haven't actually tried this yet, but it should work theoretically. I do wonder though if it will slow down other DHCP requests from the main server (?).
3) Just ignore it - which honestly I'm happy to do assuming that it really is just a dumb cosmetic message for a poorly tested case scenario. I just want to make sure that my configuration is optimal and this couldn't be avoided.

I have posted this to the dnsmasq mailing list in hope to find out if this is expected and/or a better way to configure.
If I get any feedback there I will update the thread.

So you're using DHCP on the router for your guest but not for your LAN? I doubt you're going to be able to find a way to eliminate those messages then, as you have to have DHCP enabled.
But if you completely comment out the lines related to DHCP on the BR0 that should do it, you may have to add in a line to re-enable RAs.

Here is one thing that came up in a search:

[Dnsmasq-discuss] How to run dnsmasq as RA with A bit and O bit but without dhcpv6

dnsmasq-discuss.thekelleys.org.narkive.com

And another

[Dnsmasq-discuss] Sending RA without dhcp-range

Appears there may be an "ra-only" switch you can put on to prevent it from actually assigning IPs.

 

[bengalih]

So you're using DHCP on the router for your guest but not for your LAN? I doubt you're going to be able to find a way to eliminate those messages then, as you have to have DHCP enabled.

DHCP is enabled per interface. If you don't specify the interface in the config file it won't listen. As shown above I have an interface line for each WiFi network. This would have no effect on br0 whether those existed or not.

But if you completely comment out the lines related to DHCP on the BR0 that should do it, you may have to add in a line to re-enable RAs.

As I mention from the beginning, this is not the case. RA do not work without being specified in a dhcp-range option and a dhcp-range option does not get applied unless dhcp is enabled for that interface. This is the whole problem.

Here is one thing that came up in a search:

[Dnsmasq-discuss] How to run dnsmasq as RA with A bit and O bit but without dhcpv6

dnsmasq-discuss.thekelleys.org.narkive.com

And another

[Dnsmasq-discuss] Sending RA without dhcp-range

Appears there may be an "ra-only" switch you can put on to prevent it from actually assigning IPs.

You're just retreading everything I've already discussed above. I have tried the ra-only switch to no avail. The root issue appears to be that it only refers to whether or not DHCPv6 services should occur or not and has no effect on v4. So again, the root issue is that the message appears to come from no IPv4 range being configured while a dhcp-range entry for the RAs is required. Therefore you *must* enable DHCP on the interface.
The links you provide to the mailing list basically back up everything I said.

I did hope that maybe the "--dhcp-ignore=tag:XXX" might do something, but it doesn't seem to effect this.

I'll await a reply from Scott Kelly on the mailing list.

 

[drinkingbird]

DHCP is enabled per interface. If you don't specify the interface in the config file it won't listen. As shown above I have an interface line for each WiFi network. This would have no effect on br0 whether those existed or not.

As I mention from the beginning, this is not the case. RA do not work without being specified in a dhcp-range option and a dhcp-range option does not get applied unless dhcp is enabled for that interface. This is the whole problem.


You're just retreading everything I've already discussed above. I have tried the ra-only switch to no avail. The root issue appears to be that it only refers to whether or not DHCPv6 services should occur or not and has no effect on v4. So again, the root issue is that the message appears to come from no IPv4 range being configured while a dhcp-range entry for the RAs is required. Therefore you *must* enable DHCP on the interface.
The links you provide to the mailing list basically back up everything I said.

I did hope that maybe the "--dhcp-ignore=tag:XXX" might do something, but it doesn't seem to effect this.

I'll await a reply from Scott Kelly on the mailing list.

At least some of your guest wireless interfaces are part of br0, so it is listening on br0, that's what I'm trying to tell you. If you upgrade to the latest code (386 code base) and use guest wireless 1, those get a totally separate VLAN and bridge interface, that may give you the flexibility you need to completely disable it on BR0. But if you use guest wireless 2 and/or 3, even on the latest code, those are under br0. In fact you should not be assigning different DHCP scopes to interfaces within BR0 as that will cause issues, may be part of the problem here.

Just tossing out ideas to help, not saying they are the solution. The ra-only looks promising as it allows you to define a scope but it gets ignored. But if you've tried it and it doesn't work, maybe not compatible with this implementation of dnsmasq, or the your configuration is confusing the router.

Each LAN subnet should have its own BRx interface and the interfaces under it removed from BR0.

 

[bengalih]

At least some of your guest wireless interfaces are part of br0, so it is listening on br0, that's what I'm trying to tell you. If you upgrade to the latest code (386 code base) and use guest wireless 1, those get a totally separate VLAN and bridge interface, that may give you the flexibility you need to completely disable it on BR0. But if you use guest wireless 2 and/or 3, even on the latest code, those are under br0. In fact you should not be assigning different DHCP scopes to interfaces within BR0 as that will cause issues, may be part of the problem here.

Just tossing out ideas to help, not saying they are the solution. The ra-only looks promising as it allows you to define a scope but it gets ignored. But if you've tried it and it doesn't work, maybe not compatible with this implementation of dnsmasq, or the your configuration is confusing the router.

Each LAN subnet should have its own BRx interface and the interfaces under it removed from BR0.

I am on 386.3_2. I know it is not the latest, but it is the 386 base. Could you explain a bit more about the differences in the interfaces?
As far as I recall (and it has been a while). I enabled the guest WiFi in the GUI (2 2.4 networks and 1 5.0). When this was done ifconfig showed these interfaces as wl0.1, wl0.2, and wl1.1.

I then configured them with the following:

ifconfig wl0.1 172.20.20.1 netmask 255.255.255.0
ifconfig wl1.1 172.20.30.1 netmask 255.255.255.0
ifconfig wl0.2 10.10.20.1 netmask 255.255.255.0

I then had to add a bunch of rules to iptables/ebtables. These were necessary either because these networks were not getting the DHCP requests from the server itself, or - more likely - I needed to add them so that these networks could route out to the internet, but not to my internal subnet.

I'm not sure exactly what you refer to when you say "use guest wireless 1" and not "2 and or/3" in context of my configuration. Can you explain or link me to a guide somewhere?

It is possible that my configuration was done on an older version and I ported it over after an upgrade and it continued to work so I didn't revisit it. I'm not sure that I can even configure it the way you detail if I am trying to use 3 different guest networks.

Let me know on this...I don't know if it is worth it solely to solve my issue of this errant logging problem, but if there is a more efficient/preferred way to do this I might convert over just for that.

EDIT: Reading what you wrote again, I still don't think this is going to help at all. I keep re-iterating that DHCP is *required* on the br0 interface for RA to work. If you disable it on the br0 interface, RAs don't happen - end of story. Therefore, it doesn't matter if I split the guest wireless out of br0, I still need to keep br0 interface configured in dnsmasq to send out the RAs. To state again, this code has to be in dnsmasq.conf for RAs to work (the documentation is pretty clear on that if you read the text for each of these options):

interface=br0
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
enable-ra

So even if I broke out the guest wireless, I still need the RAs to happen on br0 to go to my main WiFi and LAN clients - no way around that.

That being said, I'm still interested in this alternate config you speak of to see how it differs from mine.

thanks

 

[drinkingbird]

I am on 386.3_2. I know it is not the latest, but it is the 386 base. Could you explain a bit more about the differences in the interfaces?
As far as I recall (and it has been a while). I enabled the guest WiFi in the GUI (2 2.4 networks and 1 5.0). When this was done ifconfig showed these interfaces as wl0.1, wl0.2, and wl1.1.

I then configured them with the following:

ifconfig wl0.1 172.20.20.1 netmask 255.255.255.0
ifconfig wl1.1 172.20.30.1 netmask 255.255.255.0
ifconfig wl0.2 10.10.20.1 netmask 255.255.255.0

I then had to add a bunch of rules to iptables/ebtables. These were necessary either because these networks were not getting the DHCP requests from the server itself, or - more likely - I needed to add them so that these networks could route out to the internet, but not to my internal subnet.

I'm not sure exactly what you refer to when you say "use guest wireless 1" and not "2 and or/3" in context of my configuration. Can you explain or link me to a guide somewhere?

It is possible that my configuration was done on an older version and I ported it over after an upgrade and it continued to work so I didn't revisit it. I'm not sure that I can even configure it the way you detail if I am trying to use 3 different guest networks.

Let me know on this...I don't know if it is worth it solely to solve my issue of this errant logging problem, but if there is a more efficient/preferred way to do this I might convert over just for that.

EDIT: Reading what you wrote again, I still don't think this is going to help at all. I keep re-iterating that DHCP is *required* on the br0 interface for RA to work. If you disable it on the br0 interface, RAs don't happen - end of story. Therefore, it doesn't matter if I split the guest wireless out of br0, I still need to keep br0 interface configured in dnsmasq to send out the RAs. To state again, this code has to be in dnsmasq.conf for RAs to work (the documentation is pretty clear on that if you read the text for each of these options):

interface=br0
dhcp-range=lan,::,constructor:br0,ra-stateless,64,600
enable-ra

So even if I broke out the guest wireless, I still need the RAs to happen on br0 to go to my main WiFi and LAN clients - no way around that.

That being said, I'm still interested in this alternate config you speak of to see how it differs from mine.

thanks

What I'm trying to tell you is the misconfiguration you have may be the reason some of the stuff like ra-only isn't working right. You have multiple interfaces receiving the DHCP query (the wl interfaces are supposed to just be Layer2 sub-interfaces of brx). IPs should only be confgured on the main interfaces, brx, ethx etc. The documentation I saw does imply that you can totally disable DHCP and have RAs working, or leave it enabled and have it not hand out IPs with the "ra-only" command. If that doesn't work on the dnsmasq running on these routers, then you may just need to live with (or filter out) the log messages.

You can search through here for info on the way Guest Wireless 1 now works on 386 code base. It now separates out that guest wireless (1 only, not 2 or 3) into its own VLANs, DHCP ranges, etc.

If you're using the router DHCP for guests, why not just use it for everything? Or use VLANs and offload DHCP completely to your external server. Mix and match is probably going to be buggy either way.

Again, just giving you some ideas of stuff to look at, I'm not a paid support technician, no need to get attitude about it.

 

[bengalih]

What I'm trying to tell you is the misconfiguration you have may be the reason some of the stuff like ra-only isn't working right. You have multiple interfaces receiving the DHCP query (the wl interfaces are supposed to just be Layer2 sub-interfaces of brx). IPs should only be confgured on the main interfaces, brx, ethx etc. The documentation I saw does imply that you can totally disable DHCP and have RAs working, or leave it enabled and have it not hand out IPs with the "ra-only" command. If that doesn't work on the dnsmasq running on these routers, then you may just need to live with (or filter out) the log messages.

You can search through here for info on the way Guest Wireless 1 now works on 386 code base. It now separates out that guest wireless (1 only, not 2 or 3) into its own VLANs, DHCP ranges, etc.

If you're using the router DHCP for guests, why not just use it for everything? Or use VLANs and offload DHCP completely to your external server. Mix and match is probably going to be buggy either way.

Again, just giving you some ideas of stuff to look at, I'm not a paid support technician, no need to get attitude about it.

Not meaning to have an attitude, it's just that I've recounted both what the dnsmasq documentation states and what my personal tests show and that all points to DHCP being enabled on the interface to use RA.

--enable-ra
Enable dnsmasq's IPv6 Router Advertisement feature. DHCPv6 doesn't handle complete network configuration in the same way as DHCPv4. Router discovery and (possibly) prefix discovery for autonomous address creation are handled by a different protocol. When DHCP is in use, only a subset of this is needed, and dnsmasq can handle it, using existing DHCP configuration to provide most data. When RA is enabled, dnsmasq will advertise a prefix for each --dhcp-range, with default router as the relevant link-local address on the machine running dnsmasq.

So that makes it clear that enabling RAs cant' be done unless a dhcp-range is defined.

--dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-IPv6addr>[,<end-IPv6addr>|constructor:<interface>][,<mode>][,<prefix-len>][,<lease time>]
Enable the DHCP server. Addresses will be given out from the range <start-addr> to <end-addr> and from statically defined addresses given in --dhcp-host options. If the lease time is given, then leases will be given for that length of time. The lease time is in seconds, or minutes (eg 45m) or hours (eg 1h) or days (2d) or weeks (1w) or "infinite". If not given, the default lease time is one hour for IPv4 and one day for IPv6. The minimum lease time is two minutes. For IPv6 ranges, the lease time maybe "deprecated"; this sets the preferred lifetime sent in a DHCP lease or router advertisement to zero, which causes clients to use other addresses, if available, for new connections as a prelude to renumbering.
...
For IPv6, the parameters are slightly different: instead of netmask and broadcast address, there is an optional prefix length which must be equal to or larger then the prefix length on the local interface. If not given, this defaults to 64. Unlike the IPv4 case, the prefix length is not automatically derived from the interface configuration. The minimum size of the prefix length is 64.
...

If a --dhcp-range is only being used for stateless DHCP and/or SLAAC, then the address can be simply ::

--dhcp-range=::,constructor:eth0

That defines the specific dhcp-range format that can/should be used for stateless.

--no-dhcp-interface=<interface name>Do not provide DHCP or TFTP on the specified interface, but do provide DNS service.

Adding this option disables RAs from going out because it effectively disables any specified dhcp-range (since you saying not to provide DHCP services).

--interface=<interface name>Listen only on the specified interface(s). Dnsmasq automatically adds the loopback (local) interface to the list of interfaces to use when the --interface option is used.

Not having this set for br0 also likewise disables RAs from going out of br0 because you aren't binding to that interface, so no dhcp-range would be served to it.

Any documentation you have that is contrary to that I would welcome to see, because this is what the man pages state and they are also backed up by the answers provided in the mailing list links you provided above.

I don't think my current setup is considered a misconfiguration. It does exactly what it is intended to do and up until now has not caused any issues with anything else. Nor do I think my configuration is the root of these messages.

I went ahead and disabled all my dhcp from my guest wireless in dnsmasq and the issue still remains. So the guest wireless would be unrelated to this issue.

 

[drinkingbird]

Not meaning to have an attitude, it's just that I've recounted both what the dnsmasq documentation states and what my personal tests show and that all points to DHCP being enabled on the interface to use RA.


So that makes it clear that enabling RAs cant' be done unless a dhcp-range is defined.


That defines the specific dhcp-range format that can/should be used for stateless.


Adding this option disables RAs from going out because it effectively disables any specified dhcp-range (since you saying not to provide DHCP services).


Not having this set for br0 also likewise disables RAs from going out of br0 because you aren't binding to that interface, so no dhcp-range would be served to it.

Any documentation you have that is contrary to that I would welcome to see, because this is what the man pages state and they are also backed up by the answers provided in the mailing list links you provided above.

I don't think my current setup is considered a misconfiguration. It does exactly what it is intended to do and up until now has not caused any issues with anything else. Nor do I think my configuration is the root of these messages.

I went ahead and disabled all my dhcp from my guest wireless in dnsmasq and the issue still remains. So the guest wireless would be unrelated to this issue.

Not saying anything about enable-ra. I've been talking about ra-only. You still have to specify a range (since RA has to include that) but it does not hand out DHCP, supposedly, letting your other server do it instead.

Just because something is working, does not mean it is configured correctly, often a symptom is odd errors that you can't explain.....

Personally I'd reset everything, and make use of the VLAN 501 and 502 that it creates for you, and the BR1 and 2 interfaces, etc. Then go from there.

 

[bengalih]

Not saying anything about enable-ra. I've been talking about ra-only. You still have to specify a range (since RA has to include that) but it does not hand out DHCP, supposedly, letting your other server do it instead.

I specified in my very first post that I tried the ra-only option and it did not have any effect. That was further qualified in a future post where I explained that the issue appears to be with a missing dhcp-range setting for an IPv4 range. Therefore, while the enable-ra might actually tell dnsmasq "hey only send out RAs, no DHCP" that seemingly is only effecting the DHCPv6 component. The error seems to be logged because DHCPv4 queries reach the server and with no range configured it spits out that error

Just because something is working, does not mean it is configured correctly, often a symptom is odd errors that you can't explain.....

Personally I'd reset everything, and make use of the VLAN 501 and 502 that it creates for you, and the BR1 and 2 interfaces, etc. Then go from there.

I would consider trying to set things up a different way, if only for the experience, but I can not find any guides that explain what you are referencing in any great detail. In fact, most of what I can find searching the forum lists all sorts of other issues people discovered trying to work with only the second and third interfaces (with no real references to the root causes).

My current config uses ebtables to kick the wlan interfaces up to the routing table and then iptables rules to control it. I can't delve into totally reworking my configuration without some type of documentation that actually explains what was changed.

 

[drinkingbird]

I specified in my very first post that I tried the ra-only option and it did not have any effect. That was further qualified in a future post where I explained that the issue appears to be with a missing dhcp-range setting for an IPv4 range. Therefore, while the enable-ra might actually tell dnsmasq "hey only send out RAs, no DHCP" that seemingly is only effecting the DHCPv6 component. The error seems to be logged because DHCPv4 queries reach the server and with no range configured it spits out that error

I would consider trying to set things up a different way, if only for the experience, but I can not find any guides that explain what you are referencing in any great detail. In fact, most of what I can find searching the forum lists all sorts of other issues people discovered trying to work with only the second and third interfaces (with no real references to the root causes).

My current config uses ebtables to kick the wlan interfaces up to the routing table and then iptables rules to control it. I can't delve into totally reworking my configuration without some type of documentation that actually explains what was changed.

OK, best of luck.

 

[bengalih]

OK, best of luck.

Thanks. I do appreciate your help, I just think we are on different pages regarding what the root issue is here.
I hope to hear back from Scott on the dnsmasq mailing list and will let you know when I do.

In the meantime, I'll make another post explaining my current WiFi configuration and asking for more detail in why it might be considered "wrong" and how to reconfigure it. I appreciate you making me aware that there are changes, even if my current configuration is still considered "proper" for my goals, I do want to know what the differences are. So, hopefully someone that understands both methods in detail can enlighten me.

 

[drinkingbird]

Thanks. I do appreciate your help, I just think we are on different pages regarding what the root issue is here.
I hope to hear back from Scott on the dnsmasq mailing list and will let you know when I do.

In the meantime, I'll make another post explaining my current WiFi configuration and asking for more detail in why it might be considered "wrong" and how to reconfigure it. I appreciate you making me aware that there are changes, even if my current configuration is still considered "proper" for my goals, I do want to know what the differences are. So, hopefully someone that understands both methods in detail can enlighten me.

As mentioned in the other post, I don't see how filtering out DHCP requests from hitting the router is any sort of hack. It is actually exactly what you want and prevents those rogue DHCP messages from hitting the router's DHCP server. That's much less of a hack than redirecting and hiding the log messages. Granted, the logs seem to be cosmetic in nature, but you were the one that wanted to get rid of them, so seems like a reasonable solution. Assuming you can't find a way to make dnsmasq ignore DHCP and only respond to RA solicitations, it seems like a rather elegant alternative.

Still not exactly sure what the reason for not using the router's DHCP is (for only the main LAN, and using it for guest), are you also redirecting DNS over to another server for local client lookups? Whatever it is that server is doing, you can configure the same stuff on dnsmasq most likely.

 

[bengalih]

As mentioned in the other post, I don't see how filtering out DHCP requests from hitting the router is any sort of hack. It is actually exactly what you want and prevents those rogue DHCP messages from hitting the router's DHCP server. That's much less of a hack than redirecting and hiding the log messages. Granted, the logs seem to be cosmetic in nature, but you were the one that wanted to get rid of them, so seems like a reasonable solution. Assuming you can't find a way to make dnsmasq ignore DHCP and only respond to RA solicitations, it seems like a rather elegant alternative.

Still not exactly sure what the reason for not using the router's DHCP is (for only the main LAN, and using it for guest), are you also redirecting DNS over to another server for local client lookups? Whatever it is that server is doing, you can configure the same stuff on dnsmasq most likely.

Again, my main goal wasn't to remove the error messages, it was to ensure that they were strictly informational and were not an indication that I had a misconfiguration. That's goal #1. If it turned out they were normal then my second goal was to try to ignore them. We haven't fully established normal or not (at least on the Asus config). In either case, I disagree that setting up IPtables rules is less hacky than redirecting a log. I suppose one could argue eitherway. Log redirection to different facilities is done all the time - the main point of it is in order to segregate logs based on some qualifier, which is exactly what I would be doing. And yes, while IPtables can be used to block traffic you don't want, I'm not necessarily looking to block traffic - I'm looking to not have a service respond to it that I don't want to/shouldn't be. So while IPTables can be used, I see it as more of a mask. That being said, I see nothing fundamentally wrong with that solution, its just not preferable to me.

I did get one follow-up back from the dnsmasq mailing list and was told this was indeed not normal behavior. He mentioned having other dhcp-ranges (which clearly there are), so I have provided some more data and am waiting for a follow up. The interesting thing is that, after that response, I decided to remove all my custom guest WiFi configuration from dnsmasq so that only these lines remain:

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

These are the lines automatically added when you turn on the guest WiFi. With those dhcp-range lines is still generates the message.
So, in short, it seems that as long as *any* dhcp-range option exists in dnsmasq that defines an IPv4 range, that message will go out on other interfaces that aren't bound to that range. I don't believe that is supposed to happen, but it appears to be what is happening. So there is either a bug, an configuration untested for, or a misconfiguration on my end (or in the default Asus config).

I'm still awaiting input from the mailing list, just keeping the thread updated.

 

[drinkingbird]

Again, my main goal wasn't to remove the error messages, it was to ensure that they were strictly informational and were not an indication that I had a misconfiguration. That's goal #1. If it turned out they were normal then my second goal was to try to ignore them. We haven't fully established normal or not (at least on the Asus config). In either case, I disagree that setting up IPtables rules is less hacky than redirecting a log. I suppose one could argue eitherway. Log redirection to different facilities is done all the time - the main point of it is in order to segregate logs based on some qualifier, which is exactly what I would be doing. And yes, while IPtables can be used to block traffic you don't want, I'm not necessarily looking to block traffic - I'm looking to not have a service respond to it that I don't want to/shouldn't be. So while IPTables can be used, I see it as more of a mask. That being said, I see nothing fundamentally wrong with that solution, its just not preferable to me.

I did get one follow-up back from the dnsmasq mailing list and was told this was indeed not normal behavior. He mentioned having other dhcp-ranges (which clearly there are), so I have provided some more data and am waiting for a follow up. The interesting thing is that, after that response, I decided to remove all my custom guest WiFi configuration from dnsmasq so that only these lines remain:

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

These are the lines automatically added when you turn on the guest WiFi. With those dhcp-range lines is still generates the message.
So, in short, it seems that as long as *any* dhcp-range option exists in dnsmasq that defines an IPv4 range, that message will go out on other interfaces that aren't bound to that range. I don't believe that is supposed to happen, but it appears to be what is happening. So there is either a bug, an configuration untested for, or a misconfiguration on my end (or in the default Asus config).

I'm still awaiting input from the mailing list, just keeping the thread updated.

Your entire setup is massively "hacky", blocking unwanted DHCP requests is exactly what you should be doing. If you are not serving DHCP from that particular segment, and are not able to disable DHCP listener, the next logical step is to filter the requests, since you want them going to your own DHCP server anyway. But obviously up to you how you want to do it.

No different than having an network segment with no DHCP listener and no helper address configured, it just drops the unwanted DHCP requests. That is normal operation for any professional router.

You keep asking for advice in various threads but arguing with the suggestions. If you're going to do it your way no matter what, just do it.