XP clients sometimes ignore DHCPOFFERs
coreyg at iowatelecom.com
Tue Mar 21 22:06:04 UTC 2006
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.
> Jonathon Hvizdos
> IBM Global Services
> IP Services
> hvizdos at us.ibm.com
> 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
> dhcp-users at isc.org
> 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
> John Wobus wrote:
>>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.
>>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
More information about the dhcp-users