Win XP discover/offer/req/ack loop (Help!)

Jeff A. Earickson jaearick at
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 ( from 00:14:38:9d:ce:0d 
via 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 at least passed along the bogus request to the ISC DHCP

2) DHCPNAK on to 00:14:38:9d:ce:0d via

The ISC DHCP server says "no way", rightly so.

3) DHCPDISCOVER from 00:14:38:9d:ce:0d via
    DHCPOFFER on to 00:14:38:9d:ce:0d via

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 ( from 00:14:38:9d:ce:0d via 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?

Jeff Earickson
Colby College

On Thu, 24 Aug 2006, Alex Moen wrote:

> Date: Thu, 24 Aug 2006 14:12:25 -0500
> From: Alex Moen <alexm at>
> Reply-To: dhcp-users at
> To: dhcp-users at
> Cc: 'Daniel S. Siff' <dsiff at>
> 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
> server?)
> 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.
> Alex
> -----Original Message-----
> From: dhcp-users-bounce at [mailto:dhcp-users-bounce at] On Behalf
> Of Jeff A. Earickson
> Sent: Thursday, August 24, 2006 1:20 PM
> To: dhcp-users at
> 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>
>> Reply-To: dhcp-users at
>> To: dhcp-users at
>> Cc: Daniel S. Siff <dsiff at>
>> Subject: Win XP discover/offer/req/ack loop (Help!)
>> 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
>> addr):
>> magma dhcpd: DHCPREQUEST for ( from
>> 00:14:22:f7:8f:76 (d620-015549) via magma dhcpd: DHCPACK
>> on to 00:14:22:f7:8f:76 (d620-015549) via
>> (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
>> behavior.
>> What is the problem??  The fix??  Help!!
>> Jeff Earickson
>> Colby College

More information about the dhcp-users mailing list