Dumb AP doesn't show up under Active DHCP(v6) Leases after leader router reboots

I have one leader router that also acts as the DHCP(v6) server with all the other Dumb APs as DHCP clients broadcasting over 2.4 and 5Ghz using FT

My struggle currently is that when the leader router reboots, if the other Dumb APs don't reboot right after as well, they disappear from showing up under Active DHCP(v6) Leases and I lose track of them until the next time they reboot

These Dumb APs are still connected and reachable over their IP address (when I save them before rebooting the leader)

All the devices are on the same subnet and connected over ethernet cable

  1. Any idea what's going on?
  2. Is there a way for me to discover what's connected over ethernet cable to the leader router without consulting the Active DHCP(v6) Leases table?

https://medium.com/openwrt-iot/lede-openwrt-using-arp-scan-82f3b82c3656

1 Like

There isn't really a way to change this, nor would this be a bug in itself. The state of dynamic(ally assigned) DHCP/ DHCPv6 leases is not retained over a reboot, you'll need to wait for (half of-) the lease time to expire, before the client (AP) gets active again and wants its lease refreshed by the router (only this action will notify the router about its presence again).

The sensible approach would be to assign static DHCP reservations for both IPv4 and IPv6 (based on the DUID) instead of relying dynamic leases to do their magic, shortening the DHCP lease time might also improve the usability (don't shorten it too much).

3 Likes

Does the DHCP server "lose" its database after restart?

That wouldn't make sense because it would atleast need to remember what IPs its handed out in the past, yes?

Yes (at least for IPv6).

Not really, it would certainly 'be nice', but not in the sense of 'required' (the client will kindly ask for its current IPs to be re-acknowledged, the server is free grant or reject that - that and heuristics trying to come up with semi-stable assignment strategies tend to keep IP assignments the same tend to work, but even a NACK and assigning a different IP wouldn't be actively harmful to the client (it will have to act upon that anyways, even more so considering prefix changes for the uplink)).

If you want dependable assignments, you have to fix them (static leases).

2 Likes

If a new client joined the network and asked for an IP from the DHCP server, how would it know not to hand out an IP that it has handed out already?

It checks for conflicts before granting the DHCP lease.

Look at it from a different angle, retaining state would imply writing to flash every time a client request a DHCP lease (or wants it to be refreshed), while that wouldn't be an issue on a SSD/ HDD and while you might get away with it on sdhc (as there is lots of spare space for wear levelling and as it's cheap to replace), doing so over and over again would be fatal within short time on spi-nor or NAND flash.

3 Likes

In that case, the arp-scan solution seems to be the best suited unless I wanted to apply static leases

1 Like

I assign ipv4 name & static lease in my router to the mac addresses of my AP's
at lest this way you an always contact them by name
lease known or not
could assign ipv6 address if not using both

To improve manageability, "permanent" parts of your network such as APs and downstream routers should have static leases.
Rebooting a main router tends to be a considerable disruption in the best case and should be avoided. If a reboot is planned, shorten the lease time and allow all clients to take a short lease, so they will seek a renewal soon after the reboot.

1 Like