Browse Source
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]>pull/252/head
2 changed files with 11 additions and 1 deletions
Loading…
Reference in new issue