<div dir="ltr">On our guest network we often have visitors that stay for a few days coming and going. We also have a few itinerant workers who show up every few weeks for a few days. Then there is the set of one-time visitors.<div><br></div><div>The current mechanism of address assignment uses hashing of the hardware address to pick a starting point and then searching for an available address. This works fairly well, but in looking at the logs, hash collisions happen often enough that most recurring visitors have been assigned at least 2 different addresses and some have had 4 or more. </div><div><br></div><div>This is a problem for our firewall reporting. The firewall does some analytics by IP address trying to learn typical behaviour. It would be very helpful if there was a very high probability of being assigned the same address without having to setup static addresses.</div><div><br></div><div>We could create a very large pool of dynamic addresses to reduce the chances of hash collisions. A /24 or smaller network has pretty high collision probability for a fairly small number of visitors so you are probably limited to a fairly big chunk of the 10. private network for this approach. Since we already have several 192.168.x networks, I looked at another approach. This was to use a least-recently-used address reuse policy. I developed a patch that does this. This involved a few steps.</div><div><br></div><div>1) Currently leases go from the "leases" list to the "old_leases" list when they expire. Once the script has processed them, they get deleted. The main change here was to add a "past_leases" list. After being on the "old_leases" list, they get put on a past_leases list which is maintained in order sorted by expiration time from oldest to newest. When adding an item to this list, it is inserted in order and all other entries for the same hardware ID are deleted.</div><div><br></div><div>2) Added some routines in leases.c for detecting if there is a past lease for a hardware ID and for finding the least-recently-used past lease.</div><div><br></div><div>3) Changed the routine for saving leases to the lease database file to include writing the old_leases and the past_leases lists. The reload logic didn't need to change at all. The expired leases get loaded and then pruned which pushes them back onto the "past_leases" </div><div><br></div><div>4) In address_allocate, change the search strategy to use a past lease if one exists, otherwise find an address that has no past lease associated with it if one exists in the pool, otherwise use the address from the least recently used lease that is compatible with the network.</div><div><br></div><div>5) In the dhcp_reply handler when handling the DHCPDISCOVER message, check if there is a past lease for the incoming request and offer that if there is. Otherwise use address_allocate to find one.</div><div><br></div><div>6) In the dhcp_reply handler when handling the DHCPREQUEST message, if there is a past lease for the requested address for a different hardware address, deny the request forcing the caller to discover to get an address.</div><div><br></div><div>7) Added a command line option "--dhcp-remember-ip" to enable the behaviour.</div><div><br></div><div>So, does this sound like a useful feature to include generally? Is there a better way to do it? It has helped our reporting immensely without adding any IT overhead of maintaining a static lease database. I am not sure if there are other use cases. If this has some interest I will flesh out our patch, which currently does not include DHCPv6 and offer it for inclusion.</div><div><br></div><div>Cheers,</div><div>Todd Sankey</div><div><br></div><div><br></div></div>