Dhcp doesn't work anymore when router IP is inside dhcp range

Installing and Using OpenWrt
42

nobody cared for this for years. it just worked properly. i don't see posts complaining about it. i cannot accept the argument for "sudden awakening" of the community for such configurations. i also don't like the fact that something is not forbidden but someone finds just one way to deal with it using a method that restricts more than specs. i believe there was some other reason which i would like to know.

43

since we are talking about personal preferences here, if I were the author of the post I would close the post, as there is no solution to personal preferences (it's like driving in the city center at 130km/h) you can do it by accepting the consequences.

45

in fact it is not a matter of preference, it is a matter of what RFC allows/denies.

46

try to put yourself in the shoes of the person who wrote an RFC at that instant and expected normal things not all possible solutions.

if I wrote an RFC about how you go to the mountains, I would describe what is appropriate to wear (boots, etc.), certainly I would not write it is forbidden to jump off a mountain.

you understand me there's no with you it's just common sense

47

Looks like the PR https://github.com/openwrt/openwrt/pull/9857 broke this (specifically commit https://github.com/openwrt/openwrt/pull/9857/commits/4fe106afd1870cfeb6a45d40f1dbb69e890f1756),
and the PR https://github.com/openwrt/openwrt/pull/12925 aims to fix things, at least partially.

You might test with the changes from PR12925 and test if those fix it.

cc @ansuel

48

everyone thinks that computer science/programming/network is completely foolproof but it's not.


ps: not only the author of the cartoon

49

Hi :slight_smile:

The question "is it compliant" is not the most relevant question here.

ipcalc.sh is a fairly 'generic' tool in Openwrt that's used to calculate ranges for DHCP servers.
It just so happens that dnsmasq automatically skips addresses that are used by the server itself.
Any server that doesn't (like isc-dhcpd - to my knowledge) would happily spew out addresses which would then be claimed by two hosts - which has a good chance of bringing down the network if that address happens to be that of the gateway (like in @geos's example).

That possibility is reason enough for Openwrt to want to forbid configurations that include the address of the server itself inside the DHCP range. Passing overlapping ranges is not a "feature" that should be brought back to life. Instead, we can talk about re-enabling the functionality "allow users to enter sketchy ranges" by wrapping the ranges around the server address.

For that to work, ipcalc.sh would have to be able to output multiple ranges (one before the server address and one behind). That would probably have to be a switch in order to not break other software using ipcalc.sh. I will try to find some time to do that but remember that I'm a volunteer and providing time to fix some sketchy use-case is not something that can be expected.
I'm only doing this because - being a 12-kind-a-guy myself - I respect wanting to keep .13 as the server address.

1 Like
50

But that would be a bug in the client, as clients are expected to check whether an address they were assigned is unique.... (says the RFC so it is unclear what real clients actually do, and as always, existing clients behaviour trumps RFC prose).

1 Like
51

@yogo1212 thank you for your response! I really appreciate this as very valuable input to this discussion.

52

I would think this becomes the responsibility of the calling script instead of a job for a helper script. In my opinion, ipcalc.sh should have a single job to output the start/end of a given subnet, but not try to second-guess the variables passed.

53

I do agree about the dodgy nature of the script (especially given its name) - but not without expressing reservations.

  1. The last two parameters to ipcalc.sh serve no other purpose than the calculation of DHCP range boundaries and, under that premise, the purpose of the variables is very clear and the range check is simply input validation. At the moment, user input is not validated in dnsmasq.init.
  2. For calling scripts to take on the responsibility of sanitizing the parameters, they would have to do pretty much that what ipcalc.sh doing now: Determine integer representations of the addresses and compare them, likely using AWK. It is fairly cheap to just do that in the existing script and I would argue the wider interface/stronger coupling is a reasonable price.
54

I've just seen your comment on the PR - over there is probably the better place for a discussion.

55

This thread is quite old, but I have provided a solution to this problem on OpenWrt that restores the old behaviour. The dnsmasq (version 2.90) now also seems to be more intelligent and omits the IP if it is in this range.

56

Because it's an error.
You have two ways.

  1. Remove the address from the pool, aka make the pool smaller.
  2. Which should work too. Reserve this address so it is excluded from the pool.

Edit. Urghs I missed someone bumbed this necro thread

57

The feckert PR https://github.com/openwrt/openwrt/pull/18641 has been merged by hauke into 2 commits in main:

I think it must be backported into 23.05 and 24.10?