BOOTP and TCP/IP networking

[Patrick Kelsey]

Hello,

    I am using bootp to get our rtems-4.5-beta3 system going on our ethernet
network.  Our dhcp server is running on a Redhat linux system (kernel
version 2.2.16).  I noticed that when responding to BOOTREQUEST messages,
the linux dhcp server puts together all of the options it wants to send back
and then partitions it among up to three buffers to fit them into the
BOOTREPLY message.  Anything that does not fit into the vendor options field
overflows into the 'file' and 'sname' fields using the dchp options
overloading mechanism.  RFC 1533 indicates that this options overloading is
to be used only with DHCP, but the linux dhcpd does it with bootp queries as
well.  The problem that this presents is not so much that the BOOTREPLY
coming back has overloaded fields, it's that the options aren't partitioned
between the three options fields (vend, file and sname) on option code
boundaries .  That is, the first 64 bytes of options goes into the vend
field, the next 128 into the file field and the last 64 into the sname
field.  The bootp code under rtems seems to assume that all options fields
that it processes begin with an option code and end with a 255, which will
only be true coincidentally when talking to (at least) the linux dhcpd.  Now
before I go tinkering with this, I am wondering if anyone else has seen or
felt the need to work around this issue before.

Thanks,

--
Patrick Kelsey

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