Win XP discover/offer/req/ack loop (Help!)
Jeff A. Earickson
jaearick at colby.edu
Thu Aug 24 20:31:28 UTC 2006
Dear DHCP developers,
This smells like a bug to me, maybe in DHCP, maybe in a router setting,
maybe a rogue DHCP server on the affected subnet, maybe in Windoze.
I just upgraded to 3.0.5rc1 on both my primary and failover. Then I
watched the traffic from my problem subnet. Observe the behavior for
one MAC, probably a Windoze box:
1) DHCPREQUEST for 192.168.1.3 (192.168.1.1) from 00:14:38:9d:ce:0d
via 18.104.22.168: wrong network.
The machine thinks it is on a 192.168 address and makes a DHCP request
in that space. I think our routers are configured to drop unroutable
addresses like 192.168 on the floor. But the dhcp helper on the router
at 22.214.171.124 at least passed along the bogus request to the ISC DHCP
2) DHCPNAK on 192.168.1.3 to 00:14:38:9d:ce:0d via 126.96.36.199
The ISC DHCP server says "no way", rightly so.
3) DHCPDISCOVER from 00:14:38:9d:ce:0d via 188.8.131.52
DHCPOFFER on 184.108.40.206 to 00:14:38:9d:ce:0d via 220.127.116.11
The Windoze box comes back to discover what subnet it is on and
the ISC DHCP server offers it an address in the right subnet.
4) DHCPREQUEST for 192.168.1.3 (192.168.1.1) from 00:14:38:9d:ce:0d via 18.104.22.168: wrong network
The offering gets lost, and the box tries again. Why the request got
lost is a mystery.
Question: does ISC DHCP (or the RFCs) have any protocol for dealing with
machines that repeatedly decline/loose/ignore an offered number?
On Thu, 24 Aug 2006, Alex Moen wrote:
> Date: Thu, 24 Aug 2006 14:12:25 -0500
> From: Alex Moen <alexm at ndtel.com>
> Reply-To: dhcp-users at isc.org
> To: dhcp-users at isc.org
> Cc: 'Daniel S. Siff' <dsiff at colby.edu>
> Subject: RE: Win XP discover/offer/req/ack loop (Help!)
> Jeff and all,
> FYI, I never did find a resolution to this problem. We do notice, however,
> the following:
> 1. If we put a MAC reservation (a host entry) for the affected device, it
> immediately acquires that address and is happy with life.
> 2. Most cards that are affected (including in Jeff's post) seem to be Dell
> or Broadcom GigE adapters. It is not only Dell PC's that have this problem.
> 3. Different versions of DHCP (to no avail).
> What we haven't tried:
> 1. An OS other than Solaris (Jeff: the Win2k that you tried: a client or
> 2. A different DHCP server than ISC
> My guesses (with absolutely no proof or ability to garner proof):
> 1. Bad Win drivers for the affected cards
> 2. Library problems with Solaris (which is why the Win2k box is interesting)
> My DHCP server is NOT in a failover situation, so it seems to be independent
> of that portion of code.
> Hope this helps... I kind of gave up when we found the host entry solution,
> as the network affected is small. If this would begin on our public
> networks, it would gain much more attention from me.
> -----Original Message-----
> From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
> Of Jeff A. Earickson
> Sent: Thursday, August 24, 2006 1:20 PM
> To: dhcp-users at isc.org
> Cc: Daniel S. Siff
> Subject: Re: Win XP discover/offer/req/ack loop (Help!)
> I'll add that we tried a Win 2000 box on this subnet with
> the same results.
> Jeff Earickson
> On Thu, 24 Aug 2006, Jeff A. Earickson wrote:
>> Date: Thu, 24 Aug 2006 12:08:16 -0400 (EDT)
>> From: Jeff A. Earickson <jaearick at colby.edu>
>> Reply-To: dhcp-users at isc.org
>> To: dhcp-users at isc.org
>> Cc: Daniel S. Siff <dsiff at colby.edu>
>> Subject: Win XP discover/offer/req/ack loop (Help!)
>> Alex Moen posted a query just like mine to the list on 4/21/2006 just
>> like mine, but I didn't find an answer that helped him. I am having
>> the same problem.
>> My Setup: version 3.0.4 running on Solaris 9 (primary) and Solaris 10
>> (secondary) boxes. Failover mode has been running great for months.
>> Yesterday our network admin lowered the lease times on some networks
>> and also reduced the pool sizes for some other networks.
>> Today one network (not any that were changed yesterday) chokes if Win
>> XP machine are plugged into it. The loop looks like (for one MAC
>> magma dhcpd: DHCPREQUEST for 22.214.171.124 (126.96.36.199) from
>> 00:14:22:f7:8f:76 (d620-015549) via 188.8.131.52 magma dhcpd: DHCPACK
>> on 184.108.40.206 to 00:14:22:f7:8f:76 (d620-015549) via
>> 220.127.116.11 (repeats ad nauseum, quickly)
>> Apple systems have no problems on this network. If the network guy
>> moves the switch ports to different subnets/vlans then the same
>> machine nicely gets a IP number from the other subnet. The problem is
>> only with one subnet.
>> I stopped both DHCP servers, cleaned out all leases for subnet
>> 137.146.202 from the lease file (I have a perl script to do this),
>> copied the new lease file to the secondary, restarted the secondary,
>> then restarted the primary. Subnet 202 went right back to its bad
>> What is the problem?? The fix?? Help!!
>> Jeff Earickson
>> Colby College
More information about the dhcp-users