mirror of https://github.com/ospab/ostp.git
ospab
321365efe3
A user's log showed the same two failures on all 9 connects, 198 route errors total: Added 0 bypass routes via 192.168.88.1 (if_index=11) Could not find ostp_tun index in routing table after 15s — traffic will NOT be captured Two independent bugs in the Windows route layer: 1. The TUN interface index was looked up by matching FriendlyName == "ostp_tun" through GetAdaptersAddresses. WinTun does not set the FriendlyName to the adapter name, so the match never succeeded — every connect burned the full 15s window and gave up. The tun crate hands the real index back directly via AbstractDevice::tun_index() (WinTun's own adapter index), which is instant and correct; the name lookup remains only as a fallback. 2. Every route add — the server-IP bypass and the TUN default route alike — went through the legacy CreateIpForwardEntry, which failed with error 160 (ERROR_BAD_ARGUMENTS) on this machine for all of them. With the server-IP bypass never installed, the server's own packets were routed INTO the tunnel: a loop that stalls the link for seconds under load (the reported "VPN drops ~8s into a game" — the tunnel never actually disconnected, it froze; the log showed gap recovery skipping up to 402 frames with no packet loss on the wire). add_ipv4_route now shells to route.exe, which resolves the interface and validates the gateway itself and is already what the teardown path uses; its command form was verified to be accepted (fails only on elevation, not syntax). CREATE_NO_WINDOW keeps it from flashing a console per route. Cannot be verified without the user's elevated TUN environment; the next log will read "Added N bypass routes" and "Default route via TUN ... added" instead of the failures. |
||
|---|---|---|
| .. | ||
| lib.rs | ||
| linux.rs | ||
| macos.rs | ||
| windows.rs | ||
| windows_route.rs | ||