BOOTP and TCP/IP networking

[Patrick Kelsey]

>
>I am using :
>
> Internet Software Consortium DHCP Server 2.0
> Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software
>Consortium.
> All rights reserved.
>
> Please contribute if you find this software useful.
> For info, please visit http://www.isc.org/dhcp-contrib.html
>
> $ uname -rv
> 2.2.17 #2 SMP Wed Oct 11 10:37:14 EST 2000
>
>on RedHat with only bootp with no problem. I only get the standard bootp
>reply. I am not using the RTEMS bootp client. I do not understand what
>you are seeing. Is the RTEMS forming the correct request ?
>
>--
> Chris Johns, mailto:cjohns at cybertec.com.au mailto:ccj at acm.org


Yes, RTEMS is forming the correct request, but it is interpreting the
response incorrectly.  (It took me a while to notice this because it is not
fatal in my case, but I consider that happy fact to be mere coincidence.)
Upon receiving the correctly formatted request from RTEMS, the DHCP server
prepares a reply whose contents depend on what you have in your dhcpd.conf.
The DHCP server takes all of the network configuration info specified in
dhcpd.conf and formats each piece as [option code] [length] [data ....]
where the first two fields are 1 byte and the third is as long as the second
field says it is.  There is an option code for specifying the domain name,
one for specifying a time server, etc (check out RFC 1533 for a catalogue of
them).  This 'options string' terminates with the special option code 255.
Ok, then the server tries to stick this options string into the 'vendor
options' field of the response packet.  At this point, it says aha! you are
using bootp (not full-blown dhcp), so the vendor options field is only 64
bytes long.  In my case, there are more than 64 bytes of options, so dhcpd
puts the excess options into an otherwise unused field in the response
packet that would normally be used to specify a boot filename, if that's
what you wanted to do.  Since it is overloading the 'file' field in the
response packet, it puts a special code in the vendor options field that
tells the receiveing end that the 'file' field contains more options.  Now,
if I were an old,old bootp client, I would entirely miss this fact, because
old bootp clients would not recognize this relatively new option code
defined for use by DHCP.  So old, old bootp clients would only get the
options in the 64 bytes of the vendor options field.  RTEMS does not behave
like an old, old bootp client - it recognizes this 'overloaded fields'
option code and dutifully processes the overloaded fields.  However, the
code in the RTEMS bootp client assumes that in this case where options
appear in multiple fields in the response packet, each field contains a
complete options string nicely terminated with a 255 code. dhcpd does not
use the multiplefields this way - it simply puts the first 64 bytes in the
vendor options field and the remainder in the file field.  In my case, the
split occurs in the middle of the data field of an option.  This then
exposes two problems with the RTEMS bootp code:

Problem 1:
    The RTEMS options processing code processes the vendor options field
until it reaches the 255 code (signalling the end of options) or until it
reaches the end of the options buffer (based on the size of the options
buffer).  The size of the vendor options field is taken to be the size
declared in the bootp packet data structure, but it should be based on the
length of the received packet.  For some reason, the vendor options field is
declared to be 256 bytes long in the RTEMS bootp code.  For original bootp
it should be 64 and for full-blown dhcp it would be 312.  I don't have any
idea where the 256 came from.  In any event, we know that the linux dhcpd
only sends up to 64 bytes in this field for bootp responses, but RTEMS will
try to process 256 bytes if no 255 code is reached.  When dhcpd sends > 64
bytes of options, this becomes problem number 1, since RTEMS will be
processing garbage after the first 64 bytes, up until it reaches the 256
byte mark.

Problem 2:
    When dhcpd sends >64 bytes of options, it sends an option code telling
the receiving side to look in these additional places.  RTEMS recognizes
this and tries to process these additional fields.  However, unless the
first 64 bytes happens to contain exactly a full set of options,
these addiontal fields will not being with option codes as RTEMS expects -
instead they will begin with the continuation of the data field of the
option that overflowed the vendor options area.  So again, the RTEMS bootp
code will be processing garbage (In my case, it thinks it is seeing useful
option codes, but is really looking at the middle of an ip address).

Both of these problems present memory corruption risks - for instance in the
case where the bootp code is processing garbage and sees an option code that
it recognizes and then tries to strdup some very long string (since the
length field is not really a valid length field) into a data structure that
assumes a not-so-long string.  I have made some relatively minor changes to
the RTEMS bootp code such that it correctly interoperates with the linux
dhcpd and will also function correctly in the case that some other dhcpd
fills each field with independent, terminated options strings (as the RTEMS
bootp codes seems to assume is the case).

If anyone out there wants to give my version a whirl, I'd be glad to post
it.

--
Patrick Kelsey

Woodward McCoach, Inc.        (voice) 877.284.4804 x126
pjk at wmi.com                            (fax) 610.436.8258