Re: [ECOS] DHCP server xid

[Martin Buck <martin dot buck at ascom dot ch>]

Hugo Tyson wrote:
> You'll have to ask the ASCOM Dudes, I'm afraid.  The patches came from
> Anssi and Anand via Andrew - I merged them in in good faith around
> 2001-12-03 along with that one from Andrew; I don't remember the analysis.

I don't know whether this is the same change I have in mind, but last
June I filed this Ascom-internal bug-report (isn't it great that
Bugzilla remembers all the stuff that I already forgot a long time ago?
:-)

-----------------------------------------

DHCP client does bogus retransmits        Opened: 2001-07-23 17:21

The DHCP client in the eCos version currently used for PLC1G doesn't
retransmit 
DHCPDISCOVER requests properly. Whenever it does a retransmit, it will
send a 
new ID with the request. However, it should stick with the one it
previously 
used if nothing in the request changed.

This bug causes very slow DHCP response times.

What happens is this: The DHCP client's initial timeout is pretty small 
(~300ms). The DHCP server usually doesn't respond within this time, so
the 
client will retransmit with a new ID. Later, the original DHCPOFFER
reply from 
the server will arrive at the client, but because it already
retransmitted, it 
will have forgotten the original ID and will drop the reply because its
ID isn't 
known. The DHCP server will refuse to send a DHCPOFFER to the second
request, 
because it already sent a DHCPOFFER to that Ethernet address, but with a 
different ID (the syslog will contain entries like "already acking
lease..."). 
Fortunately, the DHCP server will forget its initial DHCPOFFER after
some time, 
giving it the chance to send another offer with a new ID. Usually, the
client 
will have increased its timeout by now, so it will receive the DHCPOFFER
before 
it does another retransmit. This time the ID will be OK, so the client
will 
accept it. However, it can take 1-2 minutes until this state is reached.

The problem is in 
...ecos/packages/net/tcpip/current/src/lib/dhcp_prot.c, lines 491-497.
There, a recalculation of the ID is done, within the while(1) 
loop. This code should be outside the loop, e.g. at line 446.

This problem only exists in eCos for PLC1G. UTS still uses ecos-1.4.4
which does 
it right. However, ecos-1.4.4 has another problem in that all the nodes
always 
use the same ID on startup. I guess when this problem was fixed, the
other one 
was introduced.

----------------------------------------

BTW, PLC1G and UTS are Ascom products that used different versions of
eCos at that time. I don't know which release PLC1G used, but it was
newer than the 1.4.4 UTS had.

> Hmmm, you're right that it uses the hwaddr before it's been set; that's
> bogus; the SIOCGIFHWADDR in case DHCPSTATE_INIT is what gets the ESA to use
> there.  That's a bug.

Certainly.

> At a glance I would have thought one wants to keep the same xid for a
> particular station for as long as you retain the same IP address - which is
> why it took care only to initialize it in case DHCPSTATE_INIT.

If I remember the RFC correctly, you're supposed to use the XID to match
requests and replies, i.e. each time you send a new reqeuest, you
generate a new XID. If you simply retransmit an old request, you reuse
the same ID. It's a transaction ID and my understanding of a transaction
here is one request and one reply, not a complete session with a DHCP
server that could last as long as you're able to renew you lease.

Robin: The DHCP server is supposed to keep its clients apart by looking
at their Ethernet addresses, not their XIDs. And even if two clients
happend to use the same XIDs, they also should compare the Ethernet
addresses in the DHCPOFFER/DHCPACK with their own one and drop the reply
if it contains the wrong address. This way, you can't end up with
duplicate IP addresses.

Martin