When switching to direct copy mode, add defensive nil checks before reading from input and rawInput pointers. This prevents potential issues if these pointers are not set for certain connection types.
While the TLS library handles these buffers internally, adding nil safety ensures robust operation across different connection configurations.
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
When testpre is enabled, connections are pre-established and may sit idle for up to 2 minutes. During this time, TLS 1.3 post-handshake messages (NewSessionTicket, etc.) can accumulate in the TLS connection's internal buffers (input and rawInput).
These stale messages are not part of the proxied application data and should not be forwarded by Vision. The fix clears these buffers immediately after extracting them for Vision use, before any data transfer begins.
This prevents the SSL protocol errors that occur when Vision later reads and forwards these stale TLS control messages as if they were application data.
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
The issue occurs when switching to direct copy mode - Vision was incorrectly reading from rawInput buffer which contains ENCRYPTED outer TLS/Reality records and merging them with decrypted application data. This caused SSL protocol errors, especially with testpre where pre-established connections may have TLS session tickets or other post-handshake messages in rawInput.
The fix: Only read from input buffer (decrypted application data), skip rawInput (encrypted TLS records).
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
* Proxy: Implement tun raw network interface inbound support for Linux
* Proxy: Tun. Include "android" as build condition for build of tun_default implementation
* Proxy: Tun. Add .Close() cleanup calls to Handler.Init() where needed
* Proxy: Add Tun for Android
* Proxy: Tun. Implement Windows support
---------
Co-authored-by: yuhan6665 <1588741+yuhan6665@users.noreply.github.com>
* Wireguard: Decouple server endpoint DNS from address option
Previously, Wireguard server endpoint's domain resolution was incorrectly constrained by the local `address` option. For example, `ForceIPv6v4` might fail to resolve AAAA records for the server domain if no IPv6 was explicitly configured in the `address` option.
This commit decouples the server endpoint's domain resolution from the local `address` configuration. It ensures the Wireguard server address is resolved independently, allowing its `domainStrategy` to function correctly without being limited by the client's local network or `address` settings.
* Delete code instead of commenting it out
* Xtls: code refactor
- Move more logic to VisionReader/Writer
- Remove XtlsWrite()
- XtlsRead now only handle splice at the outbound
- This helps VLESS inbound to have simple buf.copy() so that we can remove pipe next
* Add bufferFlushNext; Use DispatchLink() in VLESS inbound
* Use TimeoutWrapperReader; clean up timer/buffer