XP clients sometimes ignore DHCPOFFERs

[Corey Gillespie]

You would think so, though packet captures show that this is not the 
case.  The cisco dhcp-helper does not work exactly as a relay would be 
expected to.  It forwards unicast requests as well, though they are 
formatted corectly as relayed requests when sent to the dhcp server.

Jonathon Hvizdos wrote:
> Doesn't that create an potential issue for renewals, which are not 
> broadcast's?  The initial lease extension DHCPREQUEST would be directed to 
> your gateway (unicast), which would not forward them since they aren't 
> broadcasts.  I guess he client would then broadcast its DHCPREQUEST before 
> breaking, but less broadcast traffic is better IMHO.
> Regards,
> 
> Jonathon Hvizdos
> IBM Global Services
> IP Services
> hvizdos at us.ibm.com
> 877-234-8167
> t/l 273-1896
> 
> 
> 
> Corey Gillespie <coreyg at iowatelecom.com> 
> Sent by: dhcp-users-bounce at isc.org
> 03/21/2006 11:34 AM
> Please respond to
> dhcp-users at isc.org
> 
> 
> To
> dhcp-users at isc.org
> cc
> 
> Subject
> Re: XP clients sometimes ignore DHCPOFFERs
> 
> 
> 
> 
> 
> 
> I've taken a different approach to this issue with win32 dhcp clients. 
>   All of our clients get addresses that are forwarded by cisco 
> dhcp-helper.  I set the dhcp-server option to the ip address of the 
> client machine's gateway, which seems to universally solve problems with 
> Windows machines ignoring offers for a lease (windows firewalls present 
> a different problem).  I'm not sure why at the moment, but setting the 
> broadcast address of your routers to 255.255.255.255 seems like a bad 
> idea.
> 
> John Wobus wrote:
> 
>>Hi Tom,
>>
>>I'm cc'ing this to the DHCP list in case others could use the info.
>>I posted some of this before, but when I was hunting for
>>solutions online, I came up with very little, it it would be
>>very good to have a bit about this in the mailing list archive.
>>
>>We made the change (xx.xx.xx.255 broadcast addresses
>>to 255.255.255.255 broadcast addresses in the routers)
>>a few months ago and it appears to have fixed the problem
>>of Windows clients sometimes ignoring DHCPOFFERS.
>>We made the change campus-wide, the change forced very little other
>>reconfiguration: throughout the campus, with tens of
>>thousands of devices, I heard about just one department
>>that had to reconfigure just one device that listened
>>to our routers' RIP broadcast of the default route,
>>and needed a configuration change to match.
>>
>>I was loaned a laptop that exhibited the DHCP problem,
>>thus I had the chance to watch instances of the failure,
>>try things, do various status commands, capture packets,
>>etc., and discover what was going on.  When we
>>reconfigured the broadcast address on one subnet, the
>>laptop no longer had problems on that subnet.
>>
>>Then we announced the change to technical staff
>>across campus and rolled the change out campus wide, but
>>unfortunately, I receive limited feedback from the campus
>>at large.  In general, if someone has problems, it might be
>>reported; if things go right, we're likely to hear nothing.
>>If we were truly successful eliminating a problem,
>>we will receive fewer problem reports about our DHCP
>>service in the future than we would have without
>>this change.  I asked a few folks who had reported
>>past problems, but received no definitive feedback regarding
>>whether the specific problems had gone away.
>>
>>Someone on staff here recalled that specific past versions of
>>Windows clients had this particular issue and that
>>current versions do not.  I did not experiment with
>>a variety of versions: only one, which I don't recall,
>>but I'm pretty sure it was not current.  Naturally, given the
>>solution was so painless that we were going to do it
>>in any case, spending effort getting the exact list
>>of clients to be "helped" was of less use.
>>
>>The failure was non-deterministic: it looked to me like
>>Windows' DHCP handling raced with its APIPA handling,
>>and if APIPA won, Windows had an address & mask that
>>would not accept the router's broadcast address.  The
>>laptop I borrowed had a tendency to fail but occasionally succeeded.
>>I can easily believe that the exact timing that determines
>>whether the failure occurs in any particular instance could
>>depend upon processor speed, other startup software installed, etc.
>>I could also easily believe that various Windows versions
>>have the problem to varying degrees.  However this
>>is my own speculation.
>>
>>John
>>
>>P.S. There are excellent explanations of Windows' APIPA
>>feature that Googling "APIPA" will turn up.
>>
>>On Mar 21, 2006, at 9:36 AM, Tom Greaser wrote:
>>
>>
>>
>>>your quite today.. ive been following this thread.. just wanted to
>>>know if the bcast fixed your problem.. Im having what seems to be
>>>the same kinda problem..
>>
>>
> 

-- 
Corey Gillespie			Desk:	641-269-7599
Systems Engineer		Cell:	641-990-5217
Iowa Telecom			coreyg at iowatelecom.com