[ECOS] DHCP server xid

[Robin Farine]

Hi Martin,

I've read your e-mail after having sent mine. Yes, I completely agree
with you regarding the transaction ID stuff and duplicated IP addresses,
thank you for summarizing the situation very well.

Last year, we observed the case where two nodes booting simultaneously
were generating the same XID and then they both accepted the first
server reply which resulted in two nodes with the same IP address. I
think now that the DHCP client code didn't check the hardware address
from the reply.

Thanks,

Robin


On Tue, 2002-01-29 at 16:19, Martin Buck wrote:
> 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
> 
>