randomly(!) assign ip's from dynamic address range

[Simon Hobson]

Arne Baeumler <slobo at br0tkasten.de> wrote:

>> For both of these, you'll need to look into OMAPI and what operations it supports. That's the tool for dynamically interacting with the ISC DHCP server and it's lease database.
> 
> We came up with such ideas ourself and refused them because of the risk to mess things up.

As is the way of things, when you take a break sometimes fresh ideas pop up.

I think the "best" method of forcing an IP change is to "mangle" the expired lease so that next time the client comes to get a lease, it's old address is now in use. This can be done without OMAPI or interacting with the leases file.

Knock up a script which watches for a lease to expire, and checks each one against a list which require a change. Now, instead of using OMAPI, use a dummy DHCP client to request that address, thus getting a new lease on that address and making it "in use". When the client comes back online, as long as the dummy client still has an active lease, the other client won't be able to have it's old address and so will get a different one - the least recently used expired lease.

I see a few wrinkles to work out ...

The dummy lease needs to be active until the dynamic client comes back. One way of achieving this would be to simply give it a long lease (say a few days/weeks). This needs no further work, the dummy client simply gets the lease and the rest is automagic by the server which will expire it and return the address to the free pool. An alternative is that you need to track clients and spot when the dynamic client has had a new address and then release the dummy lease or stop renewing it (if using short leases). How many spare addresses you have would be a factor in deciding how to do this.
You might consider using a self service portal (which can get their current address from the connection to the web server) - the user signs in, requests an address change, the portal then tells them how long they need to turn off their kit for (to force the lease to expire) and then the timeframe for turning it back on (so they get a new address before their old one becomes free).

The dummy client needs a new ID for each lease it takes. It can use the same MAC address and change the Client-ID each time. It doesn't matter what the client-ID is, as long as it's unique within the service realm of the server - so you might use some unique string plus (say) a timestamp.


So in summary :
A process to add IPs to a list to be changed.
A process to monitor expiring leases and check them against the list.
A process to take matches from the previous step and take dummy leases to temporarily "lock" the address.

That would seem to a fairly safe set of operations.