Fix nRF52 AsyncUDP multicast TX/RX race on W5100S

[PhilipLykov]

Summary

Fix a TX/RX race condition in the nRF52 AsyncUDP implementation that causes garbled multicast packets on RAK4631 Ethernet gateway boards (W5100S).

Root cause: The W5100S socketSendUDP() function calls yield() while polling for SEND_OK. On nRF52 (cooperative multitasking), this allows AsyncUDP::runOnce() to execute and call parsePacket() on the same UDP socket while a send is still in progress. When the multicast loopback packet arrives from the network switch during this window, parsePacket() reads a garbled 8-byte RX header from the W5100S, producing an incorrect source IP (e.g. 3.192.168.30 instead of the real sender) and wrong payload length. This corrupted packet then fails protobuf decoding in UdpMulticastHandler.

Fix: Add a volatile bool isSending flag to AsyncUDP. writeTo() sets this flag around the entire send operation (beginPacket / write / endPacket). runOnce() checks !isSending before calling parsePacket(), skipping the poll when a send is active. Loopback packets remain safely buffered in the W5100S hardware RX buffer and are read cleanly on the next 5ms poll cycle.

Changes

• src/platform/nrf52/AsyncUDP.h — add volatile bool isSending member
• src/platform/nrf52/AsyncUDP.cpp — guard writeTo() with the flag; skip parsePacket() in runOnce() when sending

Test plan

• Build rak4631_eth_gw target — SUCCESS
• Flash on RAK4631 + RAK13800 (W5100S) Ethernet gateway with PoE
• Verify multicast mesh traffic has no garbled source IPs in logs
• Verify no protobuf decode errors for incoming multicast packets
• Confirm API connectivity and radio operation remain stable

[PhilipLykov]

That's how it looks in the logs:
DEBUG | 22:09:17 10 [AsyncUDP] UDP broadcast from: 0.0.0.0, len=512
DEBUG | 22:09:17 10 [AsyncUDP] Decoding MeshPacket from UDP len=512
ERROR | 22:09:17 10 [AsyncUDP] Can't decode protobuf reason='zero tag', pb_msgdesc 0xaa9bc
DEBUG | 22:09:17 11 [AsyncUDP] UDP broadcast from: 3.192.168.30, len=512
DEBUG | 22:09:17 11 [AsyncUDP] Decoding MeshPacket from UDP len=512
ERROR | 22:09:17 11 [AsyncUDP] Can't decode protobuf reason='wrong wire type', pb_msgdesc 0xaa9bc

[robekl]

UdpMulticastHandler::onSend() ignores return value of udp.writeTo() and always return true. the return value is not documented there, should it care?

[robekl]

The new guard skips parsePacket() for the entire writeTo() window. If endPacket() blocks/yields for longer intervals (as described in the PR rationale), inbound packets can accumulate and be dropped by the W5100S RX buffer during bursts. This fixes corruption but may trade it for packet loss under load.

[PhilipLykov]

Hi @robekl, thank you for the review! Both points are valid and I've pushed an updated commit to address them:

1. onSend() return value (your first comment)

You're right — onSend() was silently discarding the writeTo() result. Fixed: it now returns the result of udp.writeTo() directly. The caller in Router.cpp currently discards it, but the API is now honest for any future consumer.

2. Narrowing the isSending window (your second comment)

Good catch on the blocked duration. I've narrowed the isSending flag to only wrap endPacket(), which is the sole yield point (socketSendUDP() → yield()). beginPacket() just writes destination registers and write() copies into the TX buffer — both are fast non-yielding SPI operations. So now runOnce() only skips parsePacket() for the minimal window where the race can actually occur, rather than for the entire writeTo() sequence.

The W5100S has a 2KB RX buffer per socket, which holds ~8 typical Meshtastic packets, so even during the brief endPacket() window there's no realistic risk of overflow. And packets arriving during that window were already being corrupted before this fix — so the net effect is strictly positive.