fix: stop dropping WireGuard packets silently on the receive path

[kedimuzafer]

Problem

Three things on the receive path combine to lose packets under sustained TCP load, and none of them logs anything.

1. The queue is 8 deep and the enqueue cannot block. ML_WG_RX_QUEUE_DEPTH is 8, and route_udp_packet() in ml_net_io.c uses xQueueSend(..., 0):

case PKT_WIREGUARD:
    if (xQueueSend(ml->wg_rx_queue, &pkt, 0) != pdTRUE) {
        free(data);   /* silently */
    }

Anything that arrives while ml_wg_mgr is busy is freed and forgotten. It is busy for a while: disco_periodic_probes() takes ~113 ms once a second on a 15-peer tailnet (see #31 for why), and a handshake is longer still. At line rate that is far more than 8 packets.

2. The drain loop then sleeps a fixed 10 ms. Every packet waits up to a full tick before it is looked at, and the queue keeps filling in the meantime.

3. ml_net_io_task takes one datagram per select() round on the socket that carries all tunnelled traffic, so each packet costs a select() and a scheduler round trip.

Symptom on an ESP32-S3 Tailscale SOCKS5 proxy: transfers under ~10 KB worked, anything larger stalled after a few KB and never recovered. tcpdump on the peer showed the node simply stopping — no retransmissions from it, no response to FIN. Nothing in the device log, because the drop path does not log.

Change

• ML_WG_RX_QUEUE_DEPTH 8 → 64, ML_DISCO_RX_QUEUE_DEPTH 8 → 16. Each slot is an ml_rx_packet_t — a pointer and a few fields — not the packet, so this is a few hundred bytes.
• The manager loop's poll-then-vTaskDelay(10) becomes a blocking xQueueReceive with the same 10 ms timeout, followed by a non-blocking drain. The task now wakes the moment a packet lands. Idle cost is unchanged: with an empty queue it still blocks for 10 ms, exactly as the trailing delay did.
• ml_net_io_task drains the DISCO socket up to 32 datagrams per round with MSG_DONTWAIT, bounded so one busy socket cannot starve the STUN sockets below it.

Measured

ESP32-S3, peer on the same LAN, direct path, 1000-byte ICMP through the tunnel:

	before	after
50 pps	18% loss, RTT avg 190 ms	0% loss
100 pps	—	0% loss, RTT avg 6.2 ms

Independent of #30 and #31, though all three were measured on the same board and each helps the same bottleneck.

[antonmeyer]

Ported this onto our fork and live-tested on real ESP32-S3 hardware (two boards, OTA-pushed and rebooted) - can confirm the fix itself: build is clean, both boards come back up normally after the reboot (DERP reconnects, MQTT/BLE unaffected), and ml_wg_mgr/ml_net_io CPU usage stays low (1-6%) post-reboot with no busy-spin from the trailing vTaskDelay removal. No regressions observed.

We didn't reproduce the specific packet-loss numbers from the PR description (our traffic pattern is mostly DISCO/control-plane chatter plus periodic tunnelled polling, not a sustained high-pps bulk transfer), but the root-cause analysis matches what we independently found in the same codepath while investigating a separate probe-table pileup bug: ml_wg_mgr's own loop can be busy for a while (handshakes, disco_periodic_probes()), and the non-blocking 8-deep RX queue plus fixed-tick drain is exactly the kind of thing that loses packets silently under load. Good fix.

🤖 Generated with Claude Code