Fix #17 plus five more lwIP thread-safety violations (found via CONFIG_LWIP_CHECK_THREAD_SAFETY)

[antonmeyer]

Original fix (commit 1): ip_input()/ip4_input() is not thread-safe and must only run on lwIP's own tcpip_thread. This call site (in wireguardif_process_data_message()) runs on whatever task feeds received WireGuard packets into wireguardif_network_rx() — in a typical integration that's a dedicated WireGuard-management task, not tcpip_thread — so calling ip_input() directly here violates lwIP's core thread-safety contract.

Reproduced as a concrete crash on real ESP32-S3 hardware: sustained real TCP load through the tunnel (a firmware upload over a Tailscale-based integration built on this library) triggered a stack overflow at an unrelated call site (wg_udp_output_cb recursing via the WG netif's own broad route table entry). Traced back through several ruled-out causes — queue corruption, core-affinity races, MTU/fragmentation, PSRAM cache coherency, each checked with real evidence (tcpdump capture, targeted ENQ/DEQ tracing, a hardware stack watchpoint) — to this exact thread-safety violation letting this function's inline IP-stack processing race against other tasks' correct use of the socket API.

tcpip_input() is lwIP's own thread-safe dispatcher for exactly this situation (same signature, posts the pbuf to tcpip_thread's mailbox instead of processing it in place — the pattern every other lwIP netif driver uses).

Follow-up fix (commit 2): after the fix above, used Espressif's CONFIG_LWIP_CHECK_THREAD_SAFETY (makes every lwIP core function that requires tcpip_thread assert immediately, by name, with a backtrace, if called from the wrong task) to audit the rest of the codebase rather than assume this was the only violation. It found five more, all inside wg_init_interface()'s one-time interface setup and wireguardif.c's handshake/session-state handling:

• netif_set_up() and udp_new() in wg_init_interface()'s one-time bring-up — dispatched through tcpip_callback() + a semaphore (this project's own ml_zerocopy.c already uses exactly this pattern correctly elsewhere for its own PCB setup).
• wg_udp_output_cb()'s udp_sendto() — this callback runs both from tcpip_thread (when an app socket's send routes through the WG netif) and directly from the WireGuard-management task (handshakes/keepalives). Always dispatching would deadlock when already on tcpip_thread, so the fix checks sys_thread_tcpip(LWIP_CORE_LOCK_QUERY_HOLDER) first and only dispatches when actually needed.
• netif_set_link_up() (2 call sites) and netif_set_link_down() (2 call sites) — fixed with shared wrapper functions that also skip the tcpip_callback() dispatch once the netif's link-state flag already matches, so the per-data-packet call site costs one flag read in the steady state, not a queued callback on every packet.

Verified on real hardware, both fixes together, with the checker still enabled: clean boot through a full connection, 30+ seconds of normal operation, and a complete OTA-style push over a real tunnel with sustained TCP load — zero further assertions, zero anomalies.

Fixes #17.

[kedimuzafer]

Independent reproduction of the root cause in this PR, on separate hardware — details and a tcpdump capture in #17.

Short version: ESP32-S3 running a SOCKS5 proxy over the tailnet, every TCP transfer past a few tens of KB killed the device. Different assertion from the pbuf double-free reported originally:

assert failed: tcp_free_acked_segments tcp_in.c:1138 (tcp_receive: valid queue length)

which is the same corruption landing in TCP's send queue instead. Arrived at it the same way you did — ruled out MTU, queue depth and buffer exhaustion with packet captures first, then found ip_input() on the wrong task.

Confirming the fix works: routing RX through netif->input took this board from "50 KB transfer crashes it" to 30 MB end to end with no assertions.

I have not exercised the other five violations this PR fixes as hard, but the reasoning for each looks right to me, and the sys_thread_tcpip(LWIP_CORE_LOCK_QUERY_HOLDER) check in wg_udp_output_cb is definitely needed — that callback does run from both contexts here too.

One caveat worth flagging for whoever tests this next: with CONFIG_ML_ZERO_COPY_WG=y the receive PCB binds to an ephemeral port and that becomes the node's advertised endpoint, while s_wg_output_pcb still hardcodes local_port = 51820. Transmit and receive then sit on different ports and peers re-pin to the wrong one. Not caused by this PR, but it surfaces alongside it.