Legacy Networking | Invariant dhcp transaction ID can confuse dhcp state machine. (#14)

[Trac Migrate (@tracmigrate)]

Trac Migrate created an issue: https://gitlab.rtems.org/rtems/pkg/rtems-net-legacy/-/issues/14

Assignee: Trac Migrate

Original author: timcussins

The dhcp code in rtems uses an unchanging transaction id (xid) in the dhcp discover and request packets.

It is possible (and in fact has been observed) that dhcp servers may issue multiple OFFER packets in response to multiple REQUEST packets from the same device.

The second OFFER packet could potentially be received while the dhcp state machine is waiting for an ACK packet - and this would cause the rtems dhcp process to fail needlessly.

A solution to this is to use the transaction id field (described in the bootp/dhcp protocols) to match server dhcp replies with rtems dhcp requests.

For details on the use of xid, see RFC 2131, Section 4.4.1 (http://www.networksorcery.com/enp/rfc/rfc2131.txt)

The patch creates a unique xid for each dhcp transaction: the DISCOVER/OFFER and REQUEST/ACK phases use different xid's, there is no confusion in the rtems state machine.

* [0001-libnetworking-rtems_dhcp.c-Fix-invariant-DHCP-transa.patch](/assets/tracmigration/ticket_attachments/0001-libnetworking-rtems_dhcp.c-Fix-invariant-DHCP-transa.patch)
* [dhcp-unique-xid.diff](/assets/tracmigration/ticket_attachments/dhcp-unique-xid.diff)


-- 
View it on GitLab: https://gitlab.rtems.org/rtems/pkg/rtems-net-legacy/-/issues/14
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250131/963752db/attachment.htm>