BootP Flags in DHCPOFFER Packet
benw at meltel.com
Tue Aug 28 15:04:09 UTC 2007
Here is what I am seeing:
This DHCPOFFER is ignored by WinXP clients (I've tested on several)
This DHCPOFFER is acted on by the client
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?
Wisper High Speed Internet
ben at wisper-wireless.com
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
>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
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.
More information about the dhcp-users