README for Princeton mods version 4 February 7, 1997 irwin@princeton.edu This file contains information about version 4 of the Princeton mods to CMU-dhcpd 3.3.7. The patch is available via: http://www.princeton.edu/~irwin/dhcpd.html --------------------------------------------------------------------- APPLYING THE PATCH The patch is against dhcpd version 3.3.7 as distributed by CMU, with Princeton patches 1, 2, and 3 already applied. So if you are starting from scratch, first get dhcpd 3.3.7 from CMU, then apply Princeton patches 1, 2 and 3 in order; each of the Princeton patches via available at the URL above. If you have any local changes to dhcpd, you'll need to reconcile them against these patches. --------------------------------------------------------------------- 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 Changes since PU patch 3: --- The documentation said that a SIGINT caused the server to exit gracefully, but the server actually just caught the signalled and continued. Now we exit gracefully. We *also* will now exit gracefully if we get a SIGQUIT. (And we continue to do so on a SIGTERM.) --- On some SVR4 systems, init_interface_tab() (called at startup to determine each interface's IP address/broadcast address/netmask), would fail, displaying at ioctl error. I've fixed this, I hope. --- Fixed the following bug that caused the current bindings hash tables to become incorrect or inconsistent. When we processed a DHCPDISCOVER packet, we failed to initialize cl.clhashcode. As a result, the current binding's entry in boundhshtbl was entered using the wrong key (the value of this uninitialized variable). This would turn up later when we tried to locate the entry or remove it; a typical error message was: dhcp_request(): INIT-REBOOT: ReqIp (140.180.14.9) found in ipboundhshtbl with correct cliid... Client id: 01 08 00 07 BD 4F 89 len=7 but cliid *NOT* found in boundhshtbl! freeing binding I think it's possible that this error could also have led to later hash_Insert() errors. --- In the newest draft of the DHCP spec (draft-ietf-dhc-dhcp-09.txt), section 4.1 further defines "Server Identifier." It specifies that when a client specifies a Server Identifier option, the server must recognize *any* of the server's own IP addresses as valid. Previously, we were only recognizing 'my_ip_addr' (essentially, the server's primary IP address; see dhcpd(8) for details). Now we'll recognize any of the IP addresses associated with the server interfaces (the list we learn by walking the host's interfaces at startup). (Note that if you reconfigure the server to remove one if its IP address, DHCP clients current bound to the server may not be able to renew their leases, if they happen to be bound the Server Identifier corresponding to the IP address you removed.) ---- For some reason, the use of sigaction(), if available, was disabled; instead we always used old-style signals for the signals we expected to return from. I've re-enabled the use of sigaction() if available for those signals. (As a result, you no longer need to (nor should) manually add the SYSV symbol to CFLAGS in the top-level Makefile.) --- If you specified the 'bootp' access flag for a dynamic cable range in the dhcpd.conf file (to restrict these addresses to BootP clients), the server would still hand out these addresses to DHCP clients. Fixed access_network() so this no longer happens. --- There were problems with the implementation of the "roaming" access policy. When attempting to locate a dynamic IP address for a client, the server didn't properly take into account whether the client had the ":ro:" tag specified in its bootptab entry. Fixed. At startup, when the server read the lastbindings directory to determine what bindings should be re-instated as current bindings, it could fail to re-instate those for DHCP clients which were obtained via the 'roaming' access policy. Fixed. I've fixed the doc to better describe the roaming feature. --- At startup, when the server read the lastbindings directory to determine what bindings should be re-instated as current bindings, it did not check *current* access policies for dynamic addresses. Now it checks those, and will not re-instate a binding if the IP address is no longer allowed based on the *current* access policies. --- Added a new tag 'ba' to those understood in a bootptab file. This lets you specify an IP broadcast address (option 28). E.g. ':ba=140.180.192.255:'. --- If you specified the following tags in bootptab, their values were not returned to DHCP clients, even when the client specifically requested them via a Parameter Request List option: bootsize (bs), dumpfile (df), extension file (ef), root path (rp), swap server address (sw), time offset (to), and nis domain name (yd). This is fixed. --- Most bootptab tags you specified were not inserted into DHCPOFFER and DHCPACK messages *unless* the client specifically requested them via a Parameter Request List option. (The only ones that were always returned were: the IP address, bootfile (if specified), tftp server address (if specified) lease time, renewal time, rebinding time, and user class (if specified).) E.g. even if the bootptab entry had a 'ds' (domain name servers) tag, if a client did not specifically request the domain name servers, they would not be returned in DHCP replies. You can now specify the new ":nr:" (Send Non-Requested Options) boolean tag in the bootptab entry, to cause the server to return *all* bootptab tags to DHCP clients. (The tag was previously defined in the code, but not documented nor fully implemented.) Why didn't I simply change the code so the behavior specified by ':nr:' is the default? Well, I didn't want to break anyone who may be (unwittingly) relying on the old behavior. Note that if you specify the :nr: tag, we'll still attempt to insert any options specifically requested by the client in a Parameter Request List *before* we try to insert any remaining options. --- If a client specified a Parameter Request List option in a DHCPDISCOVER packet, the server would ignore that option when constructing the DHCPOFFER packet. Fixed. --- Added new '-x' commandline option to allow you to override the compile-time default for the config file (normally "/etc/dhcpd.conf"). --- Documented a pre-existing bug: if the server finds it must overload the 'file' or 'sname' fields (DHCP Option Overload), any values in those fields are overwritten, *without* being moved to the new options designed to hold them. --- Documented a pre-existing bug: if you specify a presently-unrecognized bootptab option using the generic (:Txxx:) tag, that option will *not* be returned to DHCP clients. (That's true even if the DHCP client requests it via a Parameter Request list option, or you specify the new ':nr' option.) (The option *is* still returned to BootP clients.) --- If you removed a dynamic IP address from the bootptab (or simply made it static instead of dynamic) while the IP address was part of a current binding, then when the server detected the change it would remove the binding, *but* put the address back in the pool of available dynamic addresses. Fixed so the address is no longer put back in the pool of available dynamic addresses. --- When sending a DHCPOFFER or DHCPACK, the server is permitted to put its hostname in the sname field. Previously it left this field alone (was copied from request packet), except if the field needed to use it for overflow options. Now we put the server hostname there (it will still be overwritten if the field is used for overflow options). --- If the bootptab entry had a TFTP server address tag (sa) set, we failed to insert that IP address in the siaddr field in DHCPOFFERs and DHCPACKs. (It was included in BOOTPREPLYs.) This is fixed. --- Added a new -a commandline option. Specifying this tells the server to log address assignments in a form convenient to parse (e.g. to to create reports). See the dhcpd man page for details. --- The boottpab man page claimed that specifying :to: (Time Offset) as a boolean tag was the same as specifying :to=auto:, but in reality, the server treated the boolean case as a syntax error. Now the server behaves as the man page describes. --- Documented a pre-existing bug: when sending a DHCP reply, any bytes in the options field following the END option are supposed to be filled with PAD options. We don't do this yet. --- Previous version of the man page noted that the daemon could be started by inetd, but recommended starting it from your host's startup scripts. That recommendation has been changed to be more emphatic. The startup overhead is just too high to make inetd a good choice here. (I've also stopped testing the daemon to make sure it works properly when started by inetd.) --- Added note to Installation document, explaining the 'port already in use' error message you may see at startup could be because you already have another process bound to the standard SNMP port (udp 161). --- Message fixes/enhancements: When we see a request with some must-be-zero bits *set* in the 'flags' field, we produced a message if the debuglevel was 3 or higher. Now the message is only produced at debuglevel 10 or higher. When we see a DHCPREQUEST from a client in the INIT-REBOOT state requesting an IP address inappropriate for client's present subnet, the message we produce (at debuglevel 2 or higher) has been changed to mention the Requested IP Address and the Boot Relay Agent IP address. When we see a DHCPREQUEST from a client in the SELECTING state that requests an IP address differing from the IP address presently bound (offerred) to that client, the message we produced (at debuglevel 4 or higher) didn't correctly print the two IP addresses; now it should. When we see a DHCPREQUEST from a non-local client in the REBINDING state requesting an IP address differing from the IP address presently bound to that client, the message we produced (at debuglevel 4 or higher) didn't correctly print the two IP addresses; now it should. A number of error messages that cited the Client Identifier would print it on a separate line from the rest of the message, making it difficult to understand interleaved syslog messages. The Client Identifier has been moved into the body of these message. Removed repetitious text from some error messages (e.g. "Client is confused!", "Something is wrong!"). When the client specified an Ethernet chaddr of twelve bytes of zero, or the client specified a Client Identifier option of twelve bytes of zero, we could produce a few lines of messages. Now we'll produce just one line. --------------------------------------------------------------------- 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.