Adapt dj-oyu/microlink fixes: TAI64N replay-after-reboot, DERP-to-direct re-handshake, LOCK_TCPIP_CORE no-op, DISCO PONG rate-limiting

[fudio101]

Source

dj-oyu/microlink — 21 commits, actively developed through Feb 2026, merged upstream through v1.2.0 with substantial original work on top. Uses upstream's original pre-refactor file naming (microlink_wireguard.c, microlink_disco.c, etc., not our ml_*.c layout) — nothing here cherry-picks cleanly; every item needs re-implementation against our current file layout, not a diff apply. Bundled as one research/adaptation issue since the effort-per-fix is higher and they share a "needs porting" character.

Fixes worth adapting

1. TAI64N timestamp via gettimeofday() instead of a monotonic counter — fixes replay-rejection after reboot (the Noise handshake timestamp resets to near-zero on every boot with a monotonic counter, which a real clock avoids). Check our ml_noise.c handshake timestamp handling for the same class of issue.
2. DERP→direct WG re-handshake bugs (3 commits: a30160a8, eb3dce06, c505539d): direct path discovered via DISCO but WireGuard kept using stale DERP-relay handshake state. Fixed via wireguardif_connect_direct() forcing a re-handshake on path switch, and properly reverting via wireguardif_connect_derp() on stale-path detection. Exactly the kind of bug that could affect our ml_wg_mgr.c DISCO/rebind logic.
3. Thread-safety fix (83a74688): LOCK_TCPIP_CORE() is a no-op without CONFIG_LWIP_TCPIP_CORE_LOCKING set, causing NULL-deref crashes on concurrent packet injection — fixed via tcpip_try_callback() to run wireguardif_network_rx() inside the tcpip thread. Check whether our ml_net_io.c/ml_zerocopy.c zero-copy path has the same exposure (our zero-copy module bypasses some of the normal netif RX path, worth specific attention here).
4. DISCO PONG rate-limiting (bde4bffc): responding to every NAT-keepalive PING with an encrypted PONG wastes CPU — rate-limited to 1 per 5s per peer once the direct path is established, plus a last_seen_ms race fix between the 30s probe interval and a 30s stale threshold.

Also noted (lower priority, for awareness)

• dj-oyu's own zero-copy WG receive rewrite (raw lwIP PCB + SPSC ring buffer, e7d2e33d) is conceptually similar to our existing ml_zerocopy.c — worth a comparative skim for design ideas, though ours is likely further along as a dedicated module upstream doesn't have. Not an action item on its own.
• A source/dest IP validation fix in this fork's wireguardif is the same bug class independently found in GrieferPig/microlink — already confirmed present and correct in our components/wireguard_lwip submodule, no action needed.

Target files

components/microlink/src/ml_noise.c, components/microlink/src/ml_wg_mgr.c, components/wireguard_lwip/src/wireguardif.c, components/microlink/src/ml_net_io.c, components/microlink/src/ml_zerocopy.c (verification only for the last two).

Tier 2 — higher effort per fix due to file-layout mismatch; consider splitting into individual issues once triaged further. See FORK_PRS.md row 23.

[fudio101]

Item 1 (TAI64N via gettimeofday()) is done — landed via a cleaner source than this bundle originally proposed. Rather than porting dj-oyu's version (pre-refactor file naming, needs adaptation), it came from upstream CamM2325/microlink#22 commits 6a4447c5/a8d769e3, applied directly to components/wireguard_lwip/src/wireguard-platform-esp32.c:

• fugo101/wireguard-lwip#13 (merged, released as v1.0.1)
• fugo101/microlink#46 — submodule pointer bump

Items 2–4 (DERP→direct re-handshake trilogy, LOCK_TCPIP_CORE no-op, DISCO PONG rate-limiting) are still open — leaving this issue open for those. FORK_PRS.md row 23 updated accordingly.