This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 191470

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: dhcpAssignee: Jason Vas Dias <jvdias>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: 3.0.4-2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-17 06:53:44 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
tcpdump showing successful windows xp client boot
none
dhcpd.conf used by dhcp-3.0.4 dhcpd to boot windows xp client OK none

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: jvdias@redhat.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,202.89.128.17
            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,202.89.128.17
            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.