[CLUE-Tech] DHCP server and bogus siaddr in DHCPOFFER?

[Jim Ockers]

Hi everyone,

I wonder if anyone else has seen this problem.  I've done lots of
googling and still don't have an answer.

A satellite system vendor provided a firmware upgrade to their
satmodems (all upgradeable remotely of course) which changed the
behavior of the DHCP server.  A Linksys BEFSR41 firewall router,
which was connected directly to a satmodem, stopped working.
It reported that it could not obtain an IP address using DHCP.

Of course we are using the BEFSR41v2 with the latest firmware.
I'm not sure if the problem affects the Cisco/Linksys BEFSR41v3.

Ethereal revealed that the Linksys was sending DHCPDISCOVER packets,
and the satmodem was sending DHCPOFFER packets, but the Linksys
would not proceed to the DHCPREQUEST and instead would resend the
DHCPDISCOVER.  This process repeated continuously.  Clearly the
Linksys didn't like something about the DHCPOFFER.

Ethereal also revealed that the satmodem was setting the siaddr
(Next Bootstrap Server IP Address) to a bogus value (0x64203D20).
The previous satmodem firmware set the siaddr to 0x00000000.  I
observed with ethereal that the Windows 2003 Server DHCP server
sets siaddr to its own IP address.  (Of course 0x64203D20 is not
the IP address of the satmodem, nor is it the IP address of any-
thing else on the satellite network.)

The bogus siaddr is ignored by Windows 2000, Linux dhclient, and 
other DHCP clients, which are able to obtain an IP address from
the satmodem with no problems.  However it seems to be a 
showstopper for the Linksys unit.  Anyone have any idea why?

When the satellite vendor changed their DHCP server to return
0x00000000 for siaddr, the Linksys units' DHCP clients started
working again.  Why?

More information: the siaddr is supposed to indicate the IP address
of the server from which the client should obtain a bootstrap
file via TFTP.  The RFC2131 is very non-specific about what the
client is supposed to do with the siaddr.  RFC1541 says a bit
more than RFC2131 does:

   RFC1541:
   In some environments, a DHCP server will have to consider the values
   of the 'chaddr' field and/or the 'class-identifier' option included
   in the DHCPDISCOVER or DHCPREQUEST messages when determining the
   correct parameters for a particular client.  For example, an
   organization might have a separate bootstrap server for each type of
   client it uses, requiring the DHCP server to examine the 'class-
   identifier' to determine which bootstrap server address to return in
   the 'siaddr' field of a DHCPOFFER or DHCPACK message.

According to this web page:
http://edge.mcs.drexel.edu/GICL/people/sevy/network/dhcp.html

    There are other fields that could seemingly be eliminated - for 
    example, the siaddr field, which isn't used at all for DHCP 
    messages. However, since DHCP was developed as an extension to 
    the BootP Protocol, and is designed to operate concurrently 
    with it [5], some of these fields do in fact play an important 
    role in the latter protocol and are thus justified in being 
    retained in DHCP messages.

Anyway this was a weird problem and I still don't understand why.
If anyone knows all of the things a client is supposed to do
with siaddr I'd love to know.  This post is partly just for the 
record...

Thanks,
Jim

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/