The issue was in the timing/conditions for switching to direct copy mode. When Vision receives CommandPaddingDirect from the server, it would immediately switch to direct mode even if the current buffer contains incomplete TLS records. This caused SSL protocol errors, especially with testpre where connections may have fragmented data.
The fix: Before actually performing the switch to direct copy mode, check if the current buffer contains complete TLS records using IsCompleteRecord(). If records are incomplete, return the buffer and delay the switch until the next read cycle when complete records are available.
This ensures Vision only switches to direct mode at safe TLS record boundaries, preventing data corruption.
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
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
copilot-swe-agent[bot]