XP clients sometimes ignore DHCPOFFERs

[Jonathon Hvizdos]

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