README for Princeton mods version 2 October 29, 1996 irwin@princeton.edu This file contains information about version 2 of the Princeton mods to CMU-dhcpd 3.3.7. This patch is also available at: http://www.princeton.edu/~irwin/src/CMU-dhcpd-3.3.7-PU-patch2.Z --------------------------------------------------------------------- APPLYING THE PATCH The patch is against dhcpd version 3.3.7 as distributed by CMU, with Princeton patch version 1 applied. So if you are starting from scratch, first get dhcpd 3.3.7 from CMU, then apply Princeton patch 1 (http://www.princeton.edu/~irwin/src/CMU-dhcpd-3.3.7-PU-patch1.Z), then apply this patch. You may have some local patches you'll need to reconcile against this. --------------------------------------------------------------------- PLATFORMS This code is currently in production at Princeton, but has NOT been tested extensively in all environments. In particular, I've only compiled and tested on SunOS 4.1.4 and Solaris 2.5.1. --------------------------------------------------------------------- WHAT'S CHANGED Here are the changes since Princeton patch 1: We could crash when we got a bootp request if that client currently was in our table of current bindings, but the IP address had been removed from the bootptab. Fixed. We could crash when we received a DHCPDISCOVER if the client had an appropriate static IP address listed in bootptab, and was presently bound via a DHCP assignment. Fixed. If you have defined pools of dynamic addresses, get_dynamic_ip() could spent a long time walking through all the free addresses/pools for a given gateway, every time we considered handing one out. This makes it appear the server is stuck for long periods of time. I sped this up, moving the time-consuming PING of the candidate address to the end, after all other possible tests have been done. Also, instead of testing each candidate's IP address against the gateway's IP address/netmask, instead just test a pool's IP address/netmask against the gateway's, once, before trying to walk a pool. When dumping bindings, show the binding "code" value, indicating how the address was assigned. Added call to create_lease() in dhcp_discover(), as published by Nancy L Wong on mailing list. Removed my less-correct fix in create_stub() that copied lease time from bootptab entry into stub. The result is that info in the bootptab DHCP and VEND dummy entries are now propagated properly to the client. When starting up, provide more detail about the bindings we are reading, assuming debug level is high enough. Added samples/dhcpd.conf.sample2, another sample dhcpd.conf file. This one contains more comments that may better illustrate the use of the various keywords. Added new feature to let you expire infinite (bootp-assigned) dynamic addresses; see section below. As a side effect of this new feature, we *lose* support for specifying 0xFFFFFFFF (infinity) as a possible lease time in bootptab. (I suspect I may have introduced some bugs for the 'roaming' (':ro:') feature, as that's not one I use/test.) --------------------------------------------------------------------- EXPIRE INFINITE DYNAMICS FEATURE I added the capability to expire those assignments made via bootp for dynamic addresses. BootP assignments must normally be recorded as infinite, as the client has no way to time out the assignment. But if you have some external means to ensure that the BootP clients being assigned dynamic addresses will timeout their assignments (e.g. power cycle clients periodically), then you can use the new feature to have the server reclaim those addresses as well, making them available again for re-assignment. To turn on this new server feature, specify the new "expire_infinite_dynamics" keyword in the dhcpd.conf file; it takes a required argument of a time (in seconds). The server will reclaim any infinite (i.e. bootp-assigned) dynamic address after that many seconds. (The reclaim will happen during regular dhcp garbage collection.) If you set expire_infinite_dynamics to 0, or simply leave it out of the dhcp.conf file (it is optional), you get the same old default behavior, which is to never expire these assignments. Note that we don't provide an expire_infinite_statics, since this server does not actually record infinite (bootp-assigned) static assignments in the first place. --------------------------------------------------------------------- LEGAL STUFF You may copy, modify, and redistribute these modifications and documentation (the "product"), as long as doing so will not violate any copyrights, patents, or other restrictions that may be imposed on the underlying product by Carnegie Mellon University. The product" is provided "as is" without warranty of any kind, either express or implied, including without limitation any warranty with respect to its mechantability or its fitness for any particular purpose. The entire risk as to the quality and performance of the product is with you. The author, and Princeton University, does not warrant that the functions contained in the product will meet your requirements or that the operation of the product will be uninterrupted or error-free, or that defects in the the product will be corrected.