lwIP - A Lightweight TCP/IP stack - Bugs: bug #64424, PKTINFO race condition -...
You are not allowed to post comments on this tracker with your current authentication level.
bug #64424: PKTINFO race condition - ipi_ifindex may not be initialized
Submitter: | Christian Reese <chreese> | ||
Submitted: | Thu 13 Jul 2023 08:53:36 PM UTC | ||
Category: | IPv4 | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | 2.1.3 |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
Powered by Savane 3.13-caa5.
Corresponding source code
If a UDP packet is received early enough (with recvmsg), you'll still successfully get the PKTINFO from the cmsg ancillary data, but the ipi_ifindex member of the in_pktinfo struct will be 0 (uninitialized) instead of the correct interface ID. All other data, however, is initialized in this case - everything besides ipi_ifindex. Eventually (usually by the following packet) you'll get ancillary data that includes a valid ipi_ifindex - just not always the first time. So it appears to be a race condition where lwIP is not always immediately ready to provide the network interface ID the packet was received on, and gives 0 instead.
The LWIP_NETBUF_RECVINFO option is enabled. A socket is created with the IP_PKTINFO sockopt enabled and subscribed to a multicast address, at which point it begins receiving UDP packets. Receive events are detected via lwip_select - whenever they occur, lwip_recvmsg is used to receive the packets - then the cmsg ancillary data is processed. If this all happens early enough immediately after network initialization, the aforementioned defect occurs.
Codebase where the defect was initially seen, along with relevant locations: https://github.com/ETCLabs/sACN/tree/v3.0.0.21
https://github.com/ETCLabs/sACN/blob/v3.0.0.21/src/sacn/sockets.c#L544
https://github.com/ETCLabs/sACN/blob/v3.0.0.21/src/sacn/sockets.c#L544
https://github.com/ETCLabs/sACN/blob/v3.0.0.21/src/sacn/sockets.c#L366
In the case of the above code, the defect results in the netint of the initial packet being reported as netint 0, with all following packets reporting the correct non-zero netint ID.