Windows ignoring DHCPOFFER is broadcast

[Jamie Savage]

David!.........removing the ip broadcast-address did the trick!!!! 

My traffic captures showed the packets being broadcast to 1.2.3.255 but 
when that statement is removed the packets are now broadcast to 
255.255.255.255.

Putting this statement on all router interfaces is something we've done 
all along so I included it as usual.  It's a statement we viewed as 
important a long time ago but we can probably live without it now.

........thanks so much, I've been messing around with this for 
some........................Jamie


James Savage                                   York University 
Senior Communications Tech.       108 Steacie Building
jsavage at yorku.ca                            4700 Keele Street
ph: 416-736-2100 ext. 22605            Toronto, Ontario
fax: 416-736-5701                                M3J 1P3, CANADA 



"David W. Hankins" <David_Hankins at isc.org> 
Sent by: dhcp-users-bounce at isc.org
03/27/2008 02:35 PM
Please respond to
dhcp-users at isc.org


To
dhcp-users at isc.org
cc

Subject
Re: Windows ignoring DHCPOFFER is broadcast






On Thu, Mar 27, 2008 at 02:17:32PM -0400, Jamie Savage wrote:
>    I have a situation where I have setup a subnet with DCHP 
> relay...ie....A Cisco router in this case with the subnet interface 
> config'd with the IP-helper command pointing to a DHCP server on another 

> subnet.   I fire up my XP-SP2 laptop which starts looking for an IP 
> address.  The 'remote' DHCP server sees the DHCPdiscover come in and 
sends 
> out a DHCPoffer which is broadcast out to the originating subnet.   My 
> XP-SP2 machine sees the broadcast (which carries the laptops MAC address 

> buried in the Bootstrap Protocol portion of the frame) but ignores 
> it...ie...it does not send a DHCPrequest back.   However, when I plug a 

first thing to check; do you have 'ip broadcast-address' configured
on the first Cisco with the ip-helper set up?

Windows boxes, when they receive broadcasts, are very conservative in
what they receive; it MUST be sent to 255.255.255.255 as dictated in
rfc2131, and cisco relays in this configuration will use the
configured broadcast address instead.

> with their MAC in the Bootstrap Protocol should respond.   Should 
> DHCPoffers be unicast or broadcast or both?? Can someone point me in a 
> direction to start looking?....I'm not sure if this is a Windows issue, 
a 
> DHCP server issue or some networking issue. 

DHCP is a funny protocol.  clients have to be able to talk and get
replies using IP without having an IP address.  servers have to be
able to send replies to the client when it might not be ARPing for
the address they want to unicast to yet (unicast offers go to the
IP destination of the offered address, with the ethernet mac
destination of the client).

the easy rules of thumb;

  - if the client set the broadcast bit, replies are broadcast.  this
    bit is an advertisement that the client cannot receive unciasts when
    it is not yet configured with an ip address.

  - if the server or relay can not support unicasting a specific ip
    address and mac address pair without arping, then the server or relay
    may still elect to broadcast even if the bit is cleared.

  - if an administrator has over-ridden any of the above (for example
    in ISC DHCP with the always-broadcast config option), then obviously
    these replies are always broadcast.  these are generally used as
    workarounds to the above (clients that do not set the broadcast bit,
    but do rely upon broadcasts, relays or servers that think they can
    unicast without arping - but are wrong for some reason).

in the future, i expect we are going to have to create an
always-unicast flag, as we have discovered that windows Vista does
set the broadcast bit (which is strange since XP doesn't), but does
not require a broadcast response.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?           
https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins                 "If you don't do it right the first time,
Software Engineer                                     you'll just have to 
do it again."
Internet Systems Consortium, Inc.                                -- Jack 
T. Hankins


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080327/9b7a1cc9/attachment.html>