Posted: Mon Dec 31, 2018 22:51 Post subject: [SOLVED] DHCP Asigned Address Do Not Fall in Range Specified
I've just installed dd-wrt on our router and all is functioning except the dhcp assigned addresses do not match the IP range specified in the Network Server Settings table.
For example the Table specifies a range starting with the address
10.151.227.100 but the addresses assigned to the devices are in a different range
10.0.0.105 or 10.0.0.112 so on.
They work on my lan because the subnet is 255.0.0.0 for the network, it is just odd.
This Router is connected to a bridged Comcast modem and the router is setup to provide the DHCP addresses for the lan and wireless hosts. I've also set up a guest VAP that has it's own set of DHCP addresses on a class C subnet.
The router is a Netgear WNDR4000 with dd-wrt v24-33555_NEWD-2_K3.x_ installed.
If this issue has been covered before it did not show up in the search terms I used.
Last edited by jbkt23 on Sun Jan 06, 2019 1:40; edited 2 times in total
I checked the modem again now and no there is no option to enable dhcp or set a lan address. In all appearances it is in Bridged Mode. When wired directly to it I can't get an IP address I create one and then I can access the admin GUI.
The router gateway address is left in the default 0.0.0.0 and the modem assigned WAN IP starts with 72.
I've saved the output to file of the command "nvram show" and scanned through the 1700 lines and did not see anything that correlated to the odd addressing.
Are there any utilities I can use to attempt a diagnosis? _________________ WNDR4000|WRT-33555-k3.MEGA
Setting an IP/subnetmask with high range of hosts will usually work
but you will likely see conflicting info in GUI vs CLI dnsmasq.conf.
e.g. router IP 10.55.7.10/8 will have starting DHCP address as 10.0.0.1 regardless
of what starting IP you put in GUI (because 10.0.0.1 is the first address in that range)...
That range would be 10.0.0.1 - 10.255.255.254 (16,777,214 available hosts) .. it'll work using the first 999 IPs
but it's a bit confusing for dd-wrt software ...unless they have recently done some changes
So dnsmasq picks the first available address in the range defined by the subnet mask. _________________ WNDR4000|WRT-33555-k3.MEGA
...although this only happens if for some goofy-ass reason you are using a netmask that allows thousands of IPs on the subnet for your home network
Ya, I had the corporate IT guy set me up back in 2001 and no wifi back then. We had a dailup internet connection till about 2006. Everything was hardwired back then. _________________ WNDR4000|WRT-33555-k3.MEGA
Since the dnsmasq.conf file is transient (/tmp directory is created from scratch on bootup), you cannot edit it directly to fix the address problem. The workaround I used was to put the following script in the firewall startup script through the UI (be careful of CRLF, lines must end in LF to work correctly or it messes up the file names). This will execute at boot time after dnsmasq.conf file has been created, with the above error, from the nvram name=value pairs and update it to the correct first three octets. The dnsmasq.conf has has probably not been created yet when the startup script is run as it did not seem to work in the startup script.
If you change the starting point or range in the UI it should still work, however if you change the base address of the lan you will need to update the sed command with new values for the search and replace.
This is a workaround and I continue to assert that this is a bug (albeit exposed when people use other than class C subnets) in the code that configures dnsmasq from the UI.
Posted: Mon Jun 22, 2020 5:50 Post subject: Um, no. the problem is the UI deciding the DHCP octet(s)
I tried to install a ddwrt router in a class B private network to support a set of devices within a class C address range, not make a class C subnet. Other devices might be in the in the rest of the class B address range (static mostly) and could be routed by this router. (hence the /16 or 255.255.0.0 not /24)
Bridging two of these type of networks with a VPN would create a single class B private network, with each of the two class C address ranges having their own gateways, but still be able to interact with the rest of the devices in the class B network range via the VPN link.
So just because my router was not at the bottom of the range (172.30.100.1 not 172.30.0.1) does not mean I wanted the DHCP assigned address to be in the 172.30.0.x e.g in a different class C subnet address range of the B.
The problem is the UI only lets you select the fourth octet of the dhcp address range. The logic is forcing the 3rd and or 2nd and 3rd octet to zero unless you use a subnet mask of /24 and create a class C network. The UI and the code that generates the DHCP range was not implemented to handle DHCP configuration on more than a class C network well.
My problem with the default behavior is that if you have more than one DD-wrt router (or vpn connecting two routers) in the same class B network) all DD-wrt DHCP servers will force you to 0 in the third octet (or second and third octets for class A), which might lead to handing out duplicate private address leases. To eliminate that risk the fourth octet range would have to mutually exclusive among all the routers in the class B range, since all DD-wrt served dhcp devices would be in a single class C address range.
Another way of looking at it is that the way the configuration utility is implemented currently there is a maximum of 255 available DHCP addresses in a class A or class B network and they must be the bottom 255, no matter how many DD-wrt routers in the network.
I'm not sure why the only place people seem to think this is the correct behavior (forcing the 3rd octet for the DHCP served addresses to be zero) is this product forum. No other router i have ever worked with (nor this same router using the factory firmware) behaves this way. If they supported class A or B networks at all (many soho ones did not), they let you specify the middle octets or did not change them to zero just because there was a zero in the subnet mask for that octet.
I understand that with other subnet masks (128, 224, etc.) one could specify an address for the DHCP served address that is not within the subnet, but that is not the case in my example and would never be the case for a 255.255.0.0 subnet mask. So I can understand the need for validity checking, but that is different from arbitrarily changing the value to zero regardless of the validity.
I have not tried using a subnet mask and router address where the 0 would be out of range to see if the config utility changed it to 128 or some other bottom of subnet range value.
So I stand by my workaround and agree with the original poster that the behavior on class A and B networks is sub-optimal. My original bug report https://svn.dd-wrt.com/ticket/6440
Posted: Mon Jun 22, 2020 6:27 Post subject: No, good idea but
Have you tried just adding your settings in Additional DNSMasq options?
the problem is it is not an "option", it is a base config value that is read when the dnsmasq process initializes, and whether dnsmasq processes the first config file entry only, or combines the two, you have to get the bad one out or it will use that address range (multiple ranges of addresses for the DHCP pool is a valid configuration). Certain dnsmasq config changes can be done on the fly without restarting the service, this is not one of them apparently.
Initially I tried to just issue a command to running dnsmasq process to change the configuration (failed) then
I just tried appending to the config file the corrected entry, hoping it would process the last of the duplicate named configuration lines, but to get it to work I had to replace the other entry and resorted to the sed search and replace of the generated config file.
Joined: 08 May 2018 Posts: 6879 Location: Texas, USA
Posted: Mon Jun 22, 2020 12:09 Post subject:
It seems you are expecting SOHO router behavior while using a non-SOHO subnet mask. Which "other routers" are you speaking of? This is *stock* firmware on a Linksys E2500v3. See the selections available for subnet mask. Had to use phone camera to show the subnet mask selections.
DD-WRT will do a 255.255.254.0 (/23) just fine cause that is what I used years ago.
Netmask that allows higher number of IP per subnet, even the 255.255.252.0 (/22) and DD-WRT will resort to
start assignment of first IP of that netmask no matter what DHCP is set at. Best I remember any set
static DHCP leases was fine no matter what netmask is as long as static lease is within that netmask.
I have NO ideal why in the hell you are trying to setup that type subnet on any type of router mentioned in any DD-WRT forums.
What you talk about makes absolutly NO sense at all.
So I will make a couple of points before I stop wasting my breath.
1) I don't care if people don't understand why I am building a particular network topology. The idea behind dd-wrt is to NOT be hamstrung by a UI when the router code supports the function you want to use.
2) There is no sane reason why if I picked an address of the router, it would force the third octet of the dhcp addresses to zero (in a class B network) as opposed to allowing me to choose it (the correct method) or leaving it the same as router address. No other router I have ever seen does this, AND PREVIOUS VERSIONS OF DD-WRT DID NOT EITHER. A bug is a bug. At the very least it is changed behavior with a lousy explanation for why.
3) It can't be an excuse for maximizing the number of dhcp addresses because the UI caps valid value for the length of the range well below the maximum.
4) At least one other person suggested this was weird behavior, and I posted a solution (work around) to configure DHCP more flexibly than the UI allows. I got a push back two years ago when I discovered and reported the bug, at that I realized meant it was never going to be fixed.
5) the sample solution I posted is a method that can than be used to choose the specific DHCP range to be used. It can also can be used to configure non-contiguous DHCP assigned address ranges which may be desirable in even some small soho networks.