The bin always passes `tun::DEFAULT_MTU` (1500) to `general_run_async`,
which the userspace TCP stack then uses to derive the MSS of segments
written into the TUN. When the TUN traffic is forwarded onwards over a
link with a smaller MTU (a WireGuard underlay at 1420 is the common
case), the kernel either fragments or, with the DF bit set, silently
drops segments larger than the next-hop MTU, and the resulting
black-hole is hard to diagnose because the proxy-side TCP looks
healthy end to end. Setting the iface MTU alone is not enough because
the userspace stack derives MSS from the value passed at startup, not
from the live iface MTU.
`tun2proxy::general_api::general_run_for_api` already takes a `tun_mtu`
parameter from the C/JNI APIs, so this just plumbs the same value
through the CLI path. Default stays at 1500, so behaviour for existing
users is unchanged.
Signed-off-by: DL6ER <[email protected]>
- Add CancellationToken parameter to `UdpGwClient::heartbeat_task` and make sleep cancellation-aware
- Update `process_socket_requests` to accept a CancellationToken and exit when cancelled
- Pass shutdown token into spawned socket and heartbeat tasks and log errors from them
- Add start/exit log messages for heartbeat and socket request handlers
DL6ER
ssrlive
Alexander Olkhovoy
dependabot[bot]
Megatron King
B. Blechschmidt
Koi to Coco
Paper-Dragon