please show me in docs that such configuration is wrong. I mean "it is not allowed to have router IP within dhcp range". I understand you may not like this configuration.
OK we'll say that that configuration is not (no longer) supported by dnsmasq and/or OpenWrt.
Also it's not a networking best practice, which is to keep everything with a static IP outside of the DHCP range to simplify understanding the network. Also it's very conventional to have the router hold the first IP in its subnet, usually that means the rotuter's last number is 1.
That doesn't mean that what you are trying to do is wrong, but it is unlikely to ever be supported.
i'm on 22.03 and it works like a charm with dnsmasq. it worked since I remember. that's why it puzzles me now. that's why I made another thread "please help me to decide if this is a bug or not". usually when things break it means a bug. there is possibility it was a bug and because of this it work(s/ed), and now it is fixed.
I would like to keep away form the discussion of my preferences. this is pure technical question on 1) is it allowed or not 2) software behaviour on this.
if you think it is not supported then explain why it works on 22.03 and earlier and redirect me to the dnsmasq docs where is states "that configuration is not supported by dnsmasq and/or OpenWrt"
Bugs don't throw up error messages explaining why what you are trying to do doesn't work. The fact DNSmasq is telling you that the router IP address is in the DHCP range when you start the service is evidence that it is intended behaviour.
If it worked previously then that was either a bug or unintended behaviour.
The answer to your 'technical' question is: no, it is not allowed in the version of DNSmasq used in the 23.05 release of OpenWRT, hence the error message you see when you try that particular config.
1 Like
I needed to erase this message because I made an error before posting it. will be back soon 
The problem right now in 23.05 is that the recent changes to ipcalc.sh don't properly handle these newly invalid configurations (i.e. it allows an invalid/incomplete dhcp-range option to be added to dnsmasq.conf), and therefore, dnsmasq won't start. That's why it works in 22.03, because the ipcalc.sh changes aren't present there.
2 Likes
all right. I think you made quite fair statement regarding the situation. yes, there was a message with the error after restarting dnsmasq and the software -- since 23.05, for some reason -- recognizes such configuration as -- at least -- not supported. I don't think such configuration is wrong per se but it does convince me it has become unsupported since release 23.05. i see the difference between saying "not supported" and "wrong".
I think we can agree it was supported (intentionally or not) in earlier versions.
if it was working "not intentionally" then it was a bug then -- is it fair to say this?
now, if dhcp server pings host before assigning IP address it means it is reasonably to assume that before assigning .13 it would ping .13 (the router) to see that .13 is not assignable. dhcp would skip then to check next IP address. is this correct? when I see such behaviour I think that so far (pre 23.05) dhcp handled very well such configurations. even the router had ip address within the range that address was skipped during assignment.
[when I write this I see now that dave14305 explained why it worked then and now does not]
I made another test. does "1" belongs to the range 1-254 or not?
it looks like in 23.05 dnsmasq properly handles such configuration:
root@OpenWrt:/# uci show network
network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fde1:bb93:ad3f::/48'
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='eth0.1'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.@switch[0]=switch
network.@switch[0].name='switch0'
network.@switch[0].reset='1'
network.@switch[0].enable_vlan='1'
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device='switch0'
network.@switch_vlan[0].vlan='1'
network.@switch_vlan[0].ports='1 2 3 0t'
network.wan=interface
network.wan.device='eth0.2'
network.wan.proto='dhcp'
network.@switch_vlan[1]=switch_vlan
network.@switch_vlan[1].device='switch0'
network.@switch_vlan[1].vlan='2'
network.@switch_vlan[1].ports='0t 5'
network.@switch_vlan[1].vid='2'
network.@switch_vlan[1].description='wan'root@OpenWrt:/# uci show dhcp
dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].boguspriv='1'
dhcp.@dnsmasq[0].filterwin2k='0'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].nonegcache='0'
dhcp.@dnsmasq[0].cachesize='1000'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.d/resolv.conf.auto'
dhcp.@dnsmasq[0].nonwildcard='1'
dhcp.@dnsmasq[0].localservice='1'
dhcp.@dnsmasq[0].ednspacket_max='1232'
dhcp.@dnsmasq[0].filter_aaaa='0'
dhcp.@dnsmasq[0].filter_a='0'
dhcp.@dnsmasq[0].confdir='/tmp/dnsmasq.d'
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.start='1'
dhcp.lan.limit='254'
dhcp.lan.leasetime='2m'
dhcp.lan.dhcpv4='server'
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'
dhcp.lan.ra_flags='managed-config' 'other-config'
dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'
dhcp.odhcpd=odhcpd
dhcp.odhcpd.maindhcp='0'
dhcp.odhcpd.leasefile='/tmp/hosts/odhcpd'
dhcp.odhcpd.leasetrigger='/usr/sbin/odhcpd-update'
dhcp.odhcpd.loglevel='4'conf-file=/usr/share/dnsmasq/rfc6761.conf
dhcp-range=set:lan,192.168.1.2,192.168.1.254,255.255.255.0,2m
no-dhcp-interface=eth0.2if 1 is within the range then dnsmasq handles this unusual configuration properly. the question is: why it doesn't for 13 that is also within the range.
if 1 is not within the range then dnsmasq handles this unusual configuration properly by excluding 1 from the given range. the question is: why it doesn't exclude 13 for the same reason?
Just curious, i this a preference we should keep away from?
If so, assigning an IP outside of the DHCP scope as others noted seems wise.
Looking at RFCs, I honestly see nothing about the server itself being in a scope. They do say statically assigned hosts must coexist.
I agree with @krazeh's statement also, this seem related to the upstream dnsmasq software itself. Bugs [by definition] wouldn't have a programmed error message telling you your config isn't allowed. Just FYI, OpenWrt gets the dnsmasq software from upstream. script's error message.
If you wish to contact the developer, their information can be found here: https://thekelleys.org.uk/dnsmasq/doc.html
i replied about my love to 13 because I was asked about something that does not matter.
I just made such configuration. it worked for years. it stopped working. i don't see the docs referring to such configuration as "wrong" although many docs do mention about "wrong" things. i do accept the fact that it might have become unsupported. i recognize @krazeh 's statement about the error as fair. I made another test with 1 and the range 1-254. it works. no matter if 1 is treated as being within the range or not dnsmasq handles this. another thing is that dnsmasq seems OK with static dhcp ip that is within the range (after it is assigned). it just skips over such assignments.
This message comes from ipcalc.sh, not dnsmasq. There's no upstream problem with dnsmasq. dnsmasq.init emitted an invalid dhcp-range thanks to the bug introduced by the ipcalc.sh changes.
4 Likes
Oh cool, so it can be fixed here.
1 Like
here comes ChatGPT, the ultimate peacemaker for erring people :D:D:D
Q: is router's IP within DHCP range wrong in a sense that it is forbidden by documentation for DHCP?
ChatGPT: No, setting a router's IP address within the DHCP range is not explicitly forbidden by DHCP documentation or standards. The DHCP (Dynamic Host Configuration Protocol) itself doesn't dictate the specific IP address that the router should use; it is a protocol designed to dynamically assign IP addresses to devices on a network.
I noted that above. It's defnatly okay within RFCs.
yes, wanted to make some fun.
1 Like
If the intent is to exclude IPs inside the range, this compare is coded incorrectly. ip == start or ip == end is inside the range, but since the test does not include equal, the compare would allow it.
It looks like ipcalc.sh already has code to adjust the range if the router IP is the first or last address in the dhcp range.
if (start==ipaddr) start=ipaddr+1 and if (end==ipaddr) end=ipaddr-1
That occurs before it then checks if the IP address is between the start and end addresses.
1 Like
was there a different check before 23.05 or this is the first one ever introduced? if there was no such check, what would be the intention of introducing such check considering the fact that dhcp worked properly and rfc doesn't forbid such configurations as the one from my example? I don't suppose it would be just for making such configuration intentionally unsupported. i would expect some other reason for this, maybe a consequence of something different.
It looks like the check was added recently, rather than adapted from a previous check.
You'd have to seek out the author of the change to get a definitive answer. But, at a guess, the intention may be to enforce assumed best practice, i.e. not having addresses statically assigned outside DHCP within the DHCP range.
While you may not have had any issues with the config in the past it does introduce the possibility of a device in the network being assigned the same IP as the router. The DHCP server doesn't have any knowledge of addresses that it hasn't assigned, and it doesn't test whether addresses in the pool are available before assigning them.
You could try submitting a change to the code to revert the new checks to how it was before, but I suspect you'd be facing a difficult time convincing the developers that it's better to allow the previous behaviour.
1 Like
at least it is just this file. anyone interested can modify it. if there are no other dependencies then it would be probably safe. i will make tests this week to see if reverting this small change works for me.
anyway, this is a bit strange situation. the comment for the commit says "Make sure our own address doesn't lie in the calculated range". but why? i want to believe there was a reason.
if I was the author and the reason was just to avoid unusual configurations i just wouldn't do this by disabling configurations allowable by specs. making strong emphasis in documentation about good practices in that matter, maybe additional explanation there would be much better way to go. much better that assuming and forcing one kind of configuration. even the configuration of dhcp itself could introduce some additional checks in the script and warnings or dependencies even to make users conscious and knowledgeable of what he's doing. like "hey, what you're doing is unusual. this can break this and this. be aware of potential issues". but i wouldn't introduce restriction when it is not needed (assuming it is really not needed ie. there is a good motive for the change to be). but it is just me
try to imagine disabling checking, would you really like a client to get the ip address of the gateway/router.
it's like the advice before drinking alcohol (moderately) eat something, then people do what they want