Subject: [dhcwg] Broken DOCSIS dhcp client implementations

From: [email-masked]
Date: Fri, 17 Jan 2003 18:35:59 +0100

Hi

I've written the DHCP-Server part for our DOCSIS cablenetwork provisioning
suite.
It's an implementation from scratch not using ISC code or other available
implementations.

During testing I noticed that there a are quite a lot of DHCP-clients not
accepting offers from my server, i.e. some GE/Motorolla Modems, ELSA and
some old firmware versions for E-Tech.

I finally figured out that those clients all expect the dhcp-message-type
(option 53) to be the first option after the magic cookie, otherwise they
won't accept the DHCPOFFER message.

I can't find any reference in RFC 2131 defining a specific order of the
options. (besides the magic cookie and END option)

If fixed our implementation to always start with options 53,54,51; but
this is only a 'workaround' in my eyes.

Has anyone experienced similar problems with such 'non-conforming' dhcp
clients ?

Regards
	Patrick
--
Patrick Guélat, ImproWare AG Network Services, CH-4133 Pratteln
Mail: [email-masked] - Phone: +41 61 826 93 00 (ext: 13)

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jan 2003 13:41:06 -0600

That does sound familiar.   A quick examination of the ISC code shows 
that in fact the DHCP message type option is always sent first.

---

From: Bud Millwood <[email-masked]>
Date: Sat, 18 Jan 2003 03:25:41 +0100

> that in fact the DHCP message type option is always sent first.

I'm almost certain that this was specified in an RFC many years ago, but all 
trace of it seems to have disappeared. I think the idea was that if "message 
type" was not first, you could consider the packet to be BOOTP, and the rest 
of the option area would contain only BOOTP vendor extensions.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]