dhcp options questions

[Thad Thompson]

Question(s):
1. Must the options field in a DHCPOFFER or DHCPACK packet sent to a =
dhcp
client, dhclient in this case, be terminated with an 'End Option'? =
(Looking
at the RFC's, I don't think so)
2. Should dhclient process a packet past the end of the calculated UDP
payload? (It currently does)
3. Must the OS running dhclient strip the Ethernet CRC off of the packet
before handing it up. (?)

Background:

Version - dhcp-3.0pl2 (Pure source from ISC)
OS - Netbsd 1.5

One of my companies' customers went to install one of our NetBSD based
systems in their network using dhcp to get an IP address from their =
Cisco
Firewall. It failed with an error message along the lines of:

dhclient: parse_option_buffer: option #145 (254) larger than buffer.

Knowing that this was way bogus we got some packet traces, and started =
doing
some digging. Since we use dhclient quite a bit we got a comparative =
trace
from a Win2k DHCP server to see what it was doing. The packets were =
almost
identical except that the Windows server was terminating the options =
field
with an 'End Option', and the Cisco box was not. Taking the same packet =
from
the Windows machine and pulling off the 'End Option' resulted in the =
above
error. Digging further, and running dhclient from the command line, we =
also
saw these messages:

'ip length 329 disagrees with bytes received 333'
'accepting packet with data after udp payload.'

Digging into the code and packet traces, it seems that several of the
drivers in NetBSD don't cut off the Ethernet CRC before handing it up to =
the
bpf level. When dhclient gets this packet, it looks at the total length =
of
the packet (including the CRC) throws up the above messages about the =
length
being off, and keeps on processing it. When it gets to parsing the dhcp
options, it uses this test:

common/options.c line 137

for (offset =3D 0; buffer [offset] !=3D DHO_END && offset < length; ) {

This means that if there is no 'End Option', then this loop will =
continue
processing packet data till it gets to the length it thinks it should =
be. In
this case, the length includes the frame CRC, which gets processed and =
looks
like some sort of insane option.=20

Our quick solution was to change the particular driver that we were =
using to
strip off the CRC, and everything works nicely. However, there are other
drivers in NetBSD which don't do this, and I'm unsure about this =
behavior in
other OSs. Since my knowledge in this area is rather weak, I thought I'd =
ask
the experts to find out who should get the wet noodle. Cisco (no End
Option), dhclient (parsing too much), or NetBSD (not pulling off the =
CRC)?
Or did we miss something and are really the ones who deserve the noodle =
;)
Thanks!

Thad Thompson
Test Engineer
Network Storage Solutions
=20