ISC DHCP server offers fixed IP addresses to ANY device!

[Foggi, Nicola]

> I think it should unset if you set the lease state to 'reset'.  The
> reset state is supposed to completely wipe a lease, like a blank
> slate.

I'll definitely give this a try when i get back in the office...

> We normally only hear from people when things are broken; it's good to
> hear that something's working (fairly) for a change!

We've used it for many years as just a single server and it's been great!  In the past few months we've enabled failover and started using reserved leases and have gone through some pains, but 3.1.2.b1 has been the most stable so far.  I was glad to see the fix for the "peer holds all free leases" as we frequently ran into that, but we no longer do since the new release.

We have a recurring problem with reserved leases, and i'm no coder, but i had one of our guys take a look at it and we narrowed it down to this:

mdb.c - line 1054 - the case FTS_FREE and FTS_BACKUP

were causing:

"Lease with binding state free not on its queue"
"Lease with binding state backup not on its queue"

after we "reserved" a lease.  It took awhile to figure out, or what we think we figured out, and that was if you use a case statement similiar to the ones used near line 2117 it is much more stable.  Is that appropriate, I'm not sure, as i mentioned I'm no coder :)  I mentioned it in bug #18226 (not sure what info i submitted there it was awhile ago) but since we applied our homemade fix it seems to have worked.

> Ah, the DISCOVER/OFFER should go through allright, but yeah if a
> client is requesting another lease that is available, we'll give it.

we've mainly had problems with HP printers, they for some reason like to just request random ip's, very annoying, haven't looked at a jetdirect upgrade yet, maybe that would help... 

> The trouble is that REQUEST processing is nicely simple; it names a
> single IPv4 address.  We can do a hash table lookup to find that
> single address, do a quick "permission" check, and then pass/fail.  No
> loops (well, except the permission check ACL's), just a pesky disk
> access/fsync tick.
>
> We don't know if the client has other leases, much less just reserved
> ones, unless we search the by-chaddr or by-client-id hash tables,
> which potentially need some loop iterations.  I think we can look at
> doing that again now, at least gated by a config parameter.  My memory
> is the leases weren't sorted in their respective buckets when we were
> filling in the edges around reserved leases; so a search was
> potentially very expensive, and we need to do two of them.  I think we
> sorted those buckets now, if I recall correctly, so we can look at
> doing something like this again.

we do have "one-lease-per-client true;" set but I'm guessing that doesn't check against reserved leases?

> In terms of reserved lease evolution for your use case, I think the
> CLI work we've been thinking about would be the most helpful.  You
> really should be able to use some tool to get and set the status of a
> lease by IPv4 address ("rndc-alike status/set state/etc 192.168.0.1"),
> and although OMAPI can fill in that gap if you're willing to read
> enough text, there needs to be a simpler tool.

a CLI like rndc would be great, one feature would be able to pre-create a lease that was reserved, so let's say printer/client is moving from network x to network z, we could pre-create the lease in network z and set it to reserved so when the printer/client moves the lease is already reserved.  we've used and abused omshell as a way into omapi and it's solved a lot of our problems, but it definitely could use an overhaul, and if i had any coding skills i'd definitely help out, maybe I can find a grad student looking for a project!

Nicola Foggi
Networks and Telecom
DePaul University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5189 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20081229/bf3cc952/attachment.bin>