daniel-p-carvalho opened a new pull request, #20195: URL: https://github.com/apache/nuttx/pull/20195
## Summary #20161 first gated the `io_conn` reset in `iob_alloc_committed()` and `iob_tryalloc_internal()` on `CONFIG_NET_TIMESTAMPING` (be3446850a), then merged that symbol into `CONFIG_NET_TIMESTAMP` (cf78962356). The rename covered every user except `mm/iob/iob_alloc.c`, so both `#ifdef`s there test a symbol that no longer exists. They are never true, the reset is never compiled in, and IOBs taken from the pool keep the `io_conn` left by their previous owner. `io_conn` is what `pkt_input()` uses to recognise a looped-back TX timestamp packet (`dev->d_iob->io_conn == &conn->sconn`). With a stale value, an ordinary received frame that lands in a recycled IOB is treated as a TX timestamp loopback and queued on `conn->errahead` instead of `conn->readahead`, so the receiving socket silently never sees it. This PR renames the two `#ifdef`s to `CONFIG_NET_TIMESTAMP`. ## Impact - Only affects builds with `CONFIG_NET_TIMESTAMP=y`; with it disabled the code is compiled out exactly as before. - Cost with the option enabled: one pointer store per IOB allocation. - No API, Kconfig or documentation changes. ## Testing Found on a custom STM32F407 board (STM32 Ethernet MAC, `CONFIG_NET_PKT`, `CONFIG_NET_TIMESTAMP`, PTP over raw `AF_PACKET` sockets) against a Linux PTP master, with a driver that arms `io_conn` for TX timestamp loopback: `Sync`/`Pdelay_Resp`/`Follow_Up` frames stopped reaching the receiving packet socket, and the cause was traced to the stale `io_conn` described above. With this fix in place, together with the driver patches under review separately, PTP traffic ran stably in a 20 minute soak test. This change was not exercised in isolation on hardware. Build-tested with that configuration; `./tools/checkpatch.sh` passes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
