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.

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.

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.

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.

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.

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.

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"

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.

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.

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.

7) Added a command line option "--dhcp-remember-ip" to enable the behaviour.

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.

Cheers,
Todd Sankey
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to