XP clients sometimes ignore DHCPOFFERs

[Corey Gillespie]

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