Red Hat Bugzilla – Full Text Bug Listing
|Summary:||dhcpd 3.0.4-1 will not lease addresses to dhcp clients (x86_64 only)|
|Product:||[Fedora] Fedora||Reporter:||Reuben Farrelly <reuben-redhatbugzilla>|
|Component:||dhcp||Assignee:||Jason Vas Dias <jvdias>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||3.0.4-2||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-05-17 06:53:44 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Reuben Farrelly 2006-05-12 06:10:43 EDT
Description of problem: dhcp 3.0.4 does not handle Windows XP clients properly, and they cannot get a lease on an address. The clients attempt to get a lease but eventually time out and have no connectivity. At the time this happens, we see this logged: May 12 21:17:15 tornado dhcpd: DHCPDISCOVER from 00:0d:61:5e:8b:b3 via eth0 May 12 21:17:15 tornado dhcpd: DHCPOFFER on 192.168.0.20 to 00:0d:61:5e:8b:b3 via eth0 May 12 21:17:20 tornado dhcpd: DHCPDISCOVER from 00:0d:61:5e:8b:b3 via eth0 May 12 21:17:20 tornado dhcpd: DHCPOFFER on 192.168.0.20 to 00:0d:61:5e:8b:b3 via eth0 May 12 21:17:28 tornado dhcpd: DHCPDISCOVER from 00:0d:61:5e:8b:b3 via eth0 May 12 21:17:28 tornado dhcpd: DHCPOFFER on 192.168.0.20 to 00:0d:61:5e:8b:b3 via eth0 May 12 21:17:45 tornado dhcpd: DHCPDISCOVER from 00:0d:61:5e:8b:b3 via eth0 It repeats over and over until the client gives up. In this case the client above has a static entry for the host, but I have a laptop from work which is not on a fixed address and it has the same problem. Version-Release number of selected component (if applicable): 3.0.4-1 How reproducible: Every time. Steps to Reproduce: 1. Upgrade to 3.0.4-1 2. Restart the service 3. Attempt to obtain an address with a Windows XP client Actual results: No lease is obtained by the client. Expected results: A lease should be obtained. Additional info: I have three Windows XP clients on this network, and none of them work with the latest version. I've worked around by downgrading to 3.0.3-26 which with an identical config file works fine. I cannot say whether this is a specific x86_64 bug (unlikely) nor have I tested against other versions of Windows. This may well be a problem upstream, and if it is I guess it's good to at least track it here until someone somewhere comes up with a fix.
Comment 1 Jason Vas Dias 2006-05-12 14:46:35 EDT
I've had a look at this, and I was able to boot up a Windows-XP client from an FC-6 dhcp-3.0.4 server just fine ( see attached tcpdump log ). Please check you are using all the latest Rawhide packages if you're running dhcp-3.0.4 from Rawhide - particulary kernel, libgcc and glibc . There are many settings for an XP client that might cause it to reject a lease. It would be a great help in tracking down the cause of your problem if you could please append a tcpdump gathered on the FC-6 dhcp server host showing the traffic between dhcpd from dhcp-3.0.4 and a windows XP client that fails to boot, and also please append your dhcpd.conf or send it to me: email@example.com. The tcpdump command I used to gather the attached tcpdump log showing a successful lease request from a windows XP client to a dhcp-3.0.4 server was: # tcpdump -i ethX -nl -vvv -s 8192 -X port bootpc or port bootps 2>&1 | \ tee /tmp/tcpdump-windows-xp-client.dhcp.log Please gather a similar log showing the packets between the server and client and and your dhcpd.conf and send it to me / attach it to this bug report - thanks!
Comment 2 Jason Vas Dias 2006-05-12 14:47:32 EDT
Created attachment 128949 [details] tcpdump showing successful windows xp client boot
Comment 3 Jason Vas Dias 2006-05-12 14:50:02 EDT
Created attachment 128952 [details] dhcpd.conf used by dhcp-3.0.4 dhcpd to boot windows xp client OK
Comment 4 Reuben Farrelly 2006-05-13 01:13:07 EDT
I've just attempted to use your dhcpd.conf and it made no difference. The only change I made to it was the range of addresses to allocate and also the subnet and netmask statements. Attempting to packet dump now. I am presently running an -mm kernel, so that is obviously a possibility too (but then, with the previous 3.0.3 version it was ok so...)
Comment 5 Reuben Farrelly 2006-05-13 01:34:19 EDT
Ok some progress. I've done some looking at the differences between a working 3.0.3 dhcp request and a 3.0.4 one, and there's *one* difference. Here's the original request (same for both versions): 17:33:29.626362 IP (tos 0x0, ttl 128, id 1378, offset 0, flags [none], proto: UD P (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP /DHCP, Request from 00:14:22:cd:f0:9d, length: 300, xid:0xa1e40c6f, flags: [Broa dcast] (0x8000) Client Ethernet Address: 00:14:22:cd:f0:9d Vendor-rfc1048: DHCP:DISCOVER NOAUTO:Y CID:[ether]00:14:22:cd:f0:9d RQ:192.168.0.31 HN:"DC00112" VC:"MSFT 5.0" PR:SM+DN+DG+NS+WNS+WNT+WSC+RD+SR+T249+VO The 3.0.3 server replies with: 17:33:30.000867 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.0.5.bootps > 255.255.255.255.bootpc: [udp sum ok] BOO TP/DHCP, Reply, length: 300, xid:0xa1e40c6f, flags: [Broadcast] (0x8000) Your IP: 192.168.0.31 Client Ethernet Address: 00:14:22:cd:f0:9d Vendor-rfc1048: DHCP:OFFER SID:192.168.0.5 LT:86400 SM:255.255.255.0 DN:"reub.net" DG:192.168.0.1 NS:192.168.0.5,184.108.40.206 WNS:192.168.0.5 The 3.0.4 server replies with: 17:32:06.002514 IP (tos 0x10, ttl 16, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.0.5.bootps > 255.255.255.255.bootpc: [udp sum ok] BOO TP/DHCP, Reply, length: 300, xid:0xb452b192, flags: [Broadcast] (0x8000) Your IP: 192.168.0.31 Client Ethernet Address: 00:14:22:cd:f0:9d Vendor-rfc1048: DHCP:OFFER SID:192.168.0.5 LT:86400,0 SM:255.255.255.0 DN:"reub.net" DG:192.168.0.1 NS:192.168.0.5,220.127.116.11 WNS:192.168.0.5 Note the difference - an extra ,0 in the Lease Time (LT) field. I wonder if this is the cause of the problem. Jason does that extra ,0 value look like it's supposed to be there?
Comment 6 Reuben Farrelly 2006-05-13 04:54:11 EDT
Problem also happens on a non-Redhat standard .tar.gz 3.0.4 build of dhcpd downloaded from ISC, and with no lease times specified in dhcpd.conf. Which rules out a config problem. The problem is observed with the Redhat kernel as well as the -mm kernel I have been running, thus also eliminating the kernel. dhcp-3.0.4-1 also works fine on i386 using the same config file and same kernel version and glibc. But not on the x86_64. Despite my initial guess, it certainly does now look like an x86_64 specific problem, beit the platform or maybe the compiler. Is there anything else I can do to help take this bug any further towards being fixed?
Comment 7 Reuben Farrelly 2006-05-13 08:29:36 EDT
Also confirming that this affects more than just Windows XP, I am testing a Cisco 831 router which also cannot get a DHCP lease with this package. Downgrading to the previous 3.0.3-26 and it too works fine. Changing the summary to reflect this.
Comment 8 Jason Vas Dias 2006-05-13 13:37:06 EDT
Many thanks Reuben - yes, that extra ',0' on the lease time does look suspicious - and it does not happen when dhcpd runs on my i386. I'll need to wait til Monday to get access to an x86_64 for testing, but then I'll get this fixed ASAP.
Comment 9 Jason Vas Dias 2006-05-16 16:00:47 EDT
This bug is now fixed with dhcp-3.0.4-2 in FC-6/Rawhide - you can also download it from: http://people.redhat.com/~jvdias/dhcp/FC-6 . Please try out the new packages and let me know of any issues - thanks!
Comment 10 Reuben Farrelly 2006-05-17 06:53:44 EDT
Thanks, fix works fine, so closing the bug. Looks like it will be accepted upstream real soon, some mention on the DHCP users list about making a new release just to fix this problem.