Created attachment 606697 [details] good, working pxe boot process (2 Discover-Offer-Request-ACK sequences in a row) Description of problem: We use LTSP thin clients, and the redhat/isc/nominum dhcpd daemon. When the server software is updated, LTSP clients are unable to retrieve a DHCP lease, and finish booting. The typical operation is: 1. Thin station PXE boot functionality requests an IP address. This is shown in packets 1-4 in packet capture 2. After retrieving a boot kernel from the server, the station loads this, and then from *that* operating system, again requests an IP address, repeating the sequence as before. Note that this second sequence kicks off 9 seconds after the first successful lease. If successful, a second Discover-Offer-Request-Ack sequence takes place. With the update to X, the process stalls out after the client issues the 2nd discover (packet 5). The server issues no response, and in fact does not log a message in /var/log/messages. Thinking something in the server daemon must be hung or otherwise not responding at that point. Version-Release number of selected component (if applicable): good dhcp-3.0.5-31.el5.x86_64 bad dhcp-3.0.5-31.el5_8.1.x86_64 How reproducible: -update dhcpd to Steps to Reproduce: 1. update dhcpd to the "bad" version 2. restart daemon 3. boot an LTSP thin client workstation -or- perhaps depending on whether the issue is purely timing, you should be able to recreate by forcing the client to "DHCP Discover" 9 seconds after the first successful lease. Actual results: 2nd DHCP discover from client meets with no response from server Expected results: 2nd DHCP lease takes place successfully, and think client finishes booting from the network Additional info: Attached packet captures show "good" and "bad" (broken) behavior
Created attachment 606698 [details] bad, broken pxe boot dhcp process - stalls after 2nd DHCP Discover
Hi, thank you for the thorough description and the invaluable packet captures. Problem is that the dhcp client (probably udhcpc) sends client-identifier (option 61) with length 0. RFC2132 [1], section 9.14 states that minimum length of client-id is 2. The "bad" server version, i.e. dhcp-3.0.5-31.el5_8.1 fixes CVE-2012-3571 [2] by (among others) refusing to process messages with client-identifier of length 0. You should see "Dropped DHCPv4 packet with zero-length client-id" message in servers log when log level is set to debug. [1] http://www.ietf.org/rfc/rfc2132.txt [2] https://kb.isc.org/article/AA-00712