I'm hoping there's a DHCP guru here that can help me. A customer of
the company I work for is complaining of a problem with one of our
Ethernet instruments.

Setup:

A DHCP capable Ethernet instrument connected to the 192.160.10.x
network segment. Router between instrument and DHCP server. Router
configured as relay agent.

Issue:

(I know I am glossing over some of the protocol details, but I don't
think they are material.)

Instrument powers up. (assume for the first time (no existing lease))
Broadcasts a request for IP to 255.255.255.255. Router relays to DHCP
server. Server has and assigns an address in the 192.160.10.x
segment, sends reply back to router. All OK so far.

Here's the rub. Router must now relay response back to instrument.
Customer has router configured to broadcast the response using
192.160.10.255 instead of 255.255.255.255. The instrument does not
recognize this as a response to its request and eventually times out
with failure to obtain address.

If the router is reconfigured to use 255.255.255.255 to broadcast
reply to instrument all is well, but customer does not want to do that
for some unstated reason, and insists that instrument should respond
to the segment specific broadcast address.

Third-party vendor of the stack and DHCP client in the instrument
claims this is normal and instrument *should* only react to
255.255.255.255 broadcasts.

I've checked the relevant RFCs but to my muddled mind this is a fine
point that is not specifically addressed.

Can anyone help? Is the customer correct and the stack vendor all
wet, or it t'other way round? I'd greatly appreciate it if anyone can
shed some light on this.

TIA,

Paul

pffranklin.nospam@hotmail.com
(you know what to leave out to email)

On Fri, 12 Mar 2004 20:49:21 -0500, Paul Franklin
<pffranklin.nospam@hotmail.com> wrote:

>I'm hoping there's a DHCP guru here that can help me. A customer of
>the company I work for is complaining of a problem with one of our
>Ethernet instruments.
>
>Setup:
>
>A DHCP capable Ethernet instrument connected to the 192.160.10.x
>network segment. Router between instrument and DHCP server. Router
>configured as relay agent.
>
>Issue:
>
>(I know I am glossing over some of the protocol details, but I don't
>think they are material.)
>
>Instrument powers up. (assume for the first time (no existing lease))
>Broadcasts a request for IP to 255.255.255.255. Router relays to DHCP
>server. Server has and assigns an address in the 192.160.10.x
>segment, sends reply back to router. All OK so far.
>
>Here's the rub. Router must now relay response back to instrument.
>Customer has router configured to broadcast the response using
>192.160.10.255 instead of 255.255.255.255. The instrument does not
>recognize this as a response to its request and eventually times out
>with failure to obtain address.
>
>If the router is reconfigured to use 255.255.255.255 to broadcast
>reply to instrument all is well, but customer does not want to do that
>for some unstated reason, and insists that instrument should respond
>to the segment specific broadcast address.
>
>Third-party vendor of the stack and DHCP client in the instrument
>claims this is normal and instrument *should* only react to
>255.255.255.255 broadcasts.
>
>I've checked the relevant RFCs but to my muddled mind this is a fine
>point that is not specifically addressed.
>
>Can anyone help? Is the customer correct and the stack vendor all
>wet, or it t'other way round? I'd greatly appreciate it if anyone can
>shed some light on this.
>


The customer is all wet and worried about nothing, since the reply is
not a broadcast, regardless of the ip address in the packet. The
packet will have the mac address of the requestor and therefore is not
actually a broadcast packet.

-Chris

chris@nospam.com wrote:

> The customer is all wet and worried about nothing, since the reply is
> not a broadcast, regardless of the ip address in the packet. The
> packet will have the mac address of the requestor and therefore is not
> actually a broadcast packet.

Only if the the client hasn't set the BROADCAST bit (see RFC 2131,
section 4.1). If it has, it implies that it cannot receive MAC unicasts
before it has a valid IP address.

That's probably the case, as the stack vendor claims that the DHCPOFFER
should go to an IP broadcast address.

Still, that stack at the very least doesn't follow the 'be strict in
what you send, and liberal in what you accept'-principle if it *insists*
on 255.255.255.255, as the RFC does not specify that. It only says
'preferably 0xffffffff' (again, section 4.1). A server or relay agent is
perfectly within its rights to use the subnet broadcast for it.

Perhaps setting the broadcast address of the interface to
255.255.255.255 (with 'ip broadcast-address 255.255.255.255') will help.

Regards,

Marco.

On Sat, 13 Mar 2004 10:31:53 +0100, M.C. van den Bovenkamp wrote:

> Still, that stack at the very least doesn't follow the 'be strict in what
> you send, and liberal in what you accept'-principle if it *insists* on
> 255.255.255.255, as the RFC does not specify that. It only says
> 'preferably 0xffffffff' (again, section 4.1). A server or relay agent is
> perfectly within its rights to use the subnet broadcast for it.
>

How does the client recognise the subnet broadcast when it doesn't know
what the subnet is? Does it have to inspect any packet with 2 or more
contiguous 1 bits from the right hand end?

--
Rgds,
Martin

Martin Gallagher wrote:

> How does the client recognise the subnet broadcast when it doesn't know
> what the subnet is? Does it have to inspect any packet with 2 or more
> contiguous 1 bits from the right hand end?

It already has looked at the frame (as it was sent to the MAC broadcast
address); what the IP destination at that point is doesn't (or at least
*shouldn't*) matter.

But if it wanted, it could look at the offered IP address and netmask.

But the BROADCAST DHCP flag actually means 'I can't look at packets
meant for me as long as I have no IP address. Send them to the MAC
broadcast, please'.

Technically, the stack that expects the IP destination to be
255.255.255.255 isn't *broken* per se; it's just overly critical. The IP
destination address shouldn't matter at all if you don't know what your
IP adress is.

Regards,

Marco.

> Third-party vendor of the stack and DHCP client in the instrument
> claims this is normal and instrument *should* only react to
> 255.255.255.255 broadcasts.

I'm with them. Since you don't yet know what subnet you are on, how can you
know what a subnet broadcast is? The appropriate local braodcast is always
255.255.255.255. Even if you send a packet to 192.160.10.255 from a distant
network, the IP packet sent out the interface will be 255.255.255.255.

There is no good reason in this moren era when you should use a non default
broadcast address.

You might want to dig into what 'unspecified reason' is.

Again, if a mac broadcast to ffffff:fffffff and ip 192.160.10.255, there is
no reason to believe that
is a broadcast if you don't already have a MAC address If the mask is
255.255.248.0, 192.160.10.255 is a host and not a broadcast.

The only unequivocal way to express a local subnet broadcast is
255.255.255.255.

DHCP RFC 2131:

If unicasting is not possible, the message
MAY be sent as an IP broadcast using an IP broadcast address
(preferably 0xffffffff) as the IP destination address and the link-
layer broadcast address as the link-layer destination address.

So the RFC clearly prefers 255.255.255.255. The RFC may implicitly allow
non-ff IP addresses, but it seems that is not how the third party stack
chose to implement.

Seems like you are best of reverting to standard IP boradcast. I con't
think of a good reason not to.

Thanks to all for your help!