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.