(Not) serving same IP's via DHCP after a router restart

:wave:

So my old (non openwrt) router kept the IP's for device typically the same across restart even when it wasn't a "static lease". I kind of liked this behauvior and now experience something partially different since I went all-in on openwrt.

While most of the IP's served from openwrt vie DHCP (not talking about static leases here) are actually the same - some tend to change for unkown reasons to me.

Is there any logic involved why openwrt would change IP's even before the lease time is over? And also does openwrt not prefer to serve the same IP once it "refreshes" a lease?

Here for example 5 devices from my network:

image

While two of them kept their Ip (the ones on top) the three on bottom were served some new ones :thinking:

So from 36 devices I just checked 22 kept their old IP (with the new DHCP lease) while 12 devices were served different IP's. The pool of available IP's for the DHCP server is about 5 times the amount of active DHCP leases.

DHCP leases are assigned randomly.

If you want the same IPs every time, add static leases.

Dnsmasq, which is the default DHCP server in OpenWrt, chooses an IP by hashing the client's MAC address. If a device changes its MAC it will get a different IP. Otherwise it tends to be consistently assigned between sessions, unless already leased to something else.

Look at the MAC of the devices with changing IP. If it has the "local administered" bit set, it is a privatized MAC which is likely to be changed by the device.

Questions about the inner workings of dnsmasq should be directed to that group, or of course you can study the source code. OpenWrt doesn't have its own DHCP server, it is dnsmasq.

3 Likes

Any idea how openwrt handles persistence across soft/hard restarts? Is something saved to flash or eeprom?

Quick search revealed that if that would be the case the MAC should have one of this pattern:

    x2-xx-xx-xx-xx-xx
    x6-xx-xx-xx-xx-xx
    xA-xx-xx-xx-xx-xx
    xE-xx-xx-xx-xx-xx

None of my devices would fit in that.

I really don't think that is the case. Like @mk24 describes it tends to be consistently (re)assigned and that is what's true for almost 2/3 of the devices mentioned in my initial post.

The DHCP leases table is stored in RAM by default. Writing it to flash memory would rapidly wear out the flash chip (write cycles are the problem) and kill the storage medium (which may mean it kills the entire device if the memory is not removable).

The simple test is to see if a given device's MAC changes from reboot to reboot.

'Random' here refers to more of a pseudo-random approach. This is distinctly different than sequential (which is an option), where IPs are issued sequentially based on the order of the DHCP requests. In the 'random' case, it uses the hashed MAC address as an input as well as the DHCP pool's range as another input in order to assign an IP. It does tend to be consistent for most devices (provided the MAC doesn't change). So it's not actually random, but it appears so to the user and is not sequential.(and we're ignoring any idea of how random is random in an entropy context).

Just did reboot some of the devices which got reassigned a different IP and they all do not change their MACs

For the majority of my devices indeed but for some reason not for all :thinking:

And did they get the same IP when they renewed this time? What about if you restart the router? What about if you restart both simultaneously?

Yes, same IP's and the lease got "renewed"

This was the reason I created this post. Around 1/3 got a different IP (re)assigned while around 2/3 got the same IP (re)assigned.

This is something I would still need to test.

I understand that... I was asking if the same MAC appears and the same IP is issued when you reboot the router again. Or does a different MAC get presented? Or does the same MAC result in a different IP after the router is rebooted? Since you may not have been monitoring the MAC addresses of the clients prior to your router's reboot, it would make sense to run this experiment.

EDIT: Be sure you run this test with devices that did get different IPs based on your OP.

I would expect that but as I haven't keep track of the MACs before....

:+1:

I can confirm now that all MACs from devices stay the same. No difference if I restart (only) the devices or also restart the main router (=DHCP server).

But one thing I found out now when I restarted the main router (so WDS repeater and dumb AP's kept running).

It looks like that devices that are connected to Repeaters or AP's (mostly?) didn't got a new lease (maybe didn't requested one?) but that the devices that (re)connected to the main router (=DHCP server) go issued new IP's:

Looking at this colorful graphs all devices which "kept" the IP's (probably) from the old lease.

What could be done to mitigate such scenarios? Set the lease time to 120 seconds and accept this (maximum of) 2 minutes devices hanging?

I would actually expect the opposite, to a degree. IIRC, a wifi repeater (using relayd) will actually mask the MAC because it is actually a routed method under the hood. [Disclaimer: I could be wrong about this... others may have better info]. Because of the way that relayd passes DHCP requests, I think that this can mess up the typical process of mapping the IP addresses to the MAC address hash.

Now, the 'interesting' thing is that you see don't the problem happen on the hosts that are connected to the repeaters... but this actually makes some sense in that the DHCP leases will only be requested (instead of renewed) when the interface bounces. So hosts connected to a repeater (that stays up the whole time) will not need to request a new lease. OTOH, the hosts that had connected to the main router will obviously see their connection drop when that device reboots.

But then you might say "well, if the host connects directly to the router and not through the repeater, why is it getting a new IP?"

--> To this, I would posit two possible situations:

  1. The host that was connected to the main router via wifi will roam to another AP (repeater) and will attempt to get an IP address. While the main router is rebooting, the DHCP server is unavailable... but eventually the main router will come up and the DHCP server will issue an IP to the host, but it will be sent through the relayd repeater, thus causing the MAC hash to fail.

and/or

  1. The MAC address mappings are 'overloaded' (in that more than one IP is issued via the apparent MAC that is presented by the repeater with relayd), which may mess up the algorithm and prevent it from consistently issuing the same IP to the client hosts.

As I said earlier, I could be wrong about the mechanism for relayd with DHCP, but the way to test is as follows:

  • Test 1: turn off all of the repeater(s) and reboot the router. Observe that all wifi devices connect directly to your main router, and make a note of all of the IP addresses. Then, reboot the router -- all devices should drop wifi connections and clear their DHCP leases. When the router comes back up, wifi will re-establish and the IP addresses of each client should be the same as it was previously.

  • Test 2: use wired-backhaul and dumb-AP configurations for your additional APs (repeaters) and run the same test as you've done in your latest post and/or test 1 above. Obviously this may not be an option for practical deployment in your space (if you cannot run wires, for example), so this might just be a temporary test setup in close physical proximity (moving all devices into the same room for this test). And you'll likely need to reconfigure your APs to be simple dumb APs, so for each device you'll want to backup the existing configuration, reset to defaults, then configure as a dumb AP.

If wired backhaul is a possibility in your physical space, it is almost always the better option for connectivity. It avoids all of the pitfalls of relayd based repeaters by making the network operate at L2 except at the main router, thus fixing many of these types of issues (among many others). Even if it isn't possible to do this long term, you could still run the experiment to prove or disprove my theory.

1 Like

The Repeaters I use are all setup as a layer 2 (transparent) bridge utalizing WDS. All the wired AP's on the other hand are setup as dumb AP.

This setup (should) guarantee/allow all MACs for devices to be transparent in every part of the network at any time.

I now restarted the wired AP's (which are also the WDS Access Points) and here we go:

It probably forced the clients to reconnect (ether to another AP or again to the same one) which triggered a new DHCP lease.

Still I'm confused why my (default) DHCP server always changes the IP's and (by the looks of it) doesn't try to renew the same devices (same MAC) with the same IP?

Can you power-off all of your additional APs/repeaters. Just use the single main router and see what happens. This eliminates all of the variables that could be introduced with those other devices.