BootP Flags in DHCPOFFER Packet

[Benjamin Wiechman]

Here is what I am seeing:

This DHCPOFFER is ignored by WinXP clients (I've tested on several)
http://www.wisperhighspeed.com/images/bootp-bcast-ignored.png


This DHCPOFFER is acted on by the client
http://www.wisperhighspeed.com/images/bootp-ucast-used.png

What I have seen with this device is that when it sends a bcast message to
the device, the device responds in kind. When it sends a unicast message to
the device, the device once again responds in kind.

MS DHCP responds to bcast requests with a ucast response. 

However I see that ISC responds to bcast requests with a bcast response and
my box does respond to those messages... 
Looking at the packets I see that ISC sets the yiaddr, siaddr, and giaddr
fields, which are not set by my device. Is this the source of the issue? Why
would the client ignore a packet without these fields set?

Thanks

Ben Wiechman
Wisper High Speed Internet
ben at wisper-wireless.com

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
Of Glenn Satchell
Sent: Tuesday, August 28, 2007 7:53 AM
To: dhcp-users at isc.org
Subject: Re: BootP Flags in DHCPOFFER Packet


>From: "Benjamin Wiechman" <benw at meltel.com>
>To: <dhcp-users at isc.org>
>Subject: BootP Flags in DHCPOFFER Packet
>Date: Mon, 27 Aug 2007 12:16:10 -0500
>
>I haven't seen this issue in the ISC dhcp server, but since there are many
>people here who are deeply familiar with the RFC and behaviors I was
curious
>if someone could explain this to me. 
>
>We are trying to enable NAT on some network devices and I am seeing this
>issue (among others!)
>
>When the device responds with a DHCPOFFER it isn't consistently setting the
>bootp flags in the bootstrap protocol packet.
>
>See the two wireshark captures to demonstrate this:
>
Err, the list software strips attachments. You'll need to post them in
the body of the email.
>
>In one the bootp flags are set to broadcast - this packet is ignored by the
>client (winxp in this case - running realtek card)
>
>In the other the bootp flags are set to unicast - this packet is accepted
>and processed by the client.
>
>Is one of these a violation of the RFC, or is there some other reason the
>first would be ignored by the client while the second is accepted?

I believe this is allowed. There is a flag in the request where the
client indicates whether it wants the response broadcast or unicast.
The reply can be overridden using the always-broadcast statement. This
is from the dhcpd.conf man page:

     The always-broadcast statement

       always-broadcast flag;

       The DHCP and BOOTP protocols both require DHCP  and  BOOTP
       clients to set the broadcast bit in the flags field of the
       BOOTP message header.  Unfortunately, some DHCP and  BOOTP
       clients  do  not  do  this,  and therefore may not receive
       responses from the DHCP server.   The DHCP server  can  be
       made  to always broadcast its responses to clients by set-
       ting this flag to 'on' for the  relevant  scope;  relevant
       scopes  would  be  inside  a  conditional  statement, as a
       parameter for a class,  or  as  a  parameter  for  a  host
       declaration.    To avoid creating excess broadcast traffic
       on your network, we recommend that you restrict the use of
       this  option to as few clients as possible.   For example,
       the Microsoft DHCP client is known not to have this  prob-
       lem, as are the OpenTransport and ISC DHCP clients.

regards,
-glenn