Per RPRX's clarification, the original order was correct. Reverted the buffer processing order back to: input → rawInput. The issue is not an ordering problem as I misunderstood.
Awaiting clarification on the actual fix needed.
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
Per RPRX's feedback, the original code logic was correct, but the processing order matters. When switching to direct copy mode, rawInput (encrypted TLS records from the outer layer) should be processed and merged into the buffer before input (decrypted application data).
This ensures proper ordering of data when transitioning from Vision-padded mode to direct copy mode, preventing SSL errors especially with testpre connections.
Fixes#4878
Co-authored-by: RPRX <63339210+RPRX@users.noreply.github.com>
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>
* 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
- In 03131c72db new flags were added for uplink/downlink, but that was not suffcient
- Now that the traffic state contains all possible info
- Each inbound and outbound is responsible to set their own CanSpliceCopy flag. Note that this also open up more splice usage. E.g. socks in -> freedom out
- Fixes https://github.com/XTLS/Xray-core/issues/4033
* Add GetInboundUser in proto
* Add get user logic for all existing inbounds
* Add inbounduser command
* Add option to get all users
* Fix shadowsocks2022 config
* Fix init users in shadowsocks2022
* Fix copy
* Add inbound user count command
This api costs much less than get inbound user, could be useful in some case
* Update from latest main
* Refactor log
* Add new log methods
* Fix logger test
* Change all logging code
* Clean up pathObj
* Rebase to latest main
* Remove invoking method name after the dot
* Add session context outbounds as slice
slice is needed for dialer proxy where two outbounds work on top of each other
There are two sets of target addr for example
It also enable Xtls to correctly do splice copy by checking both outbounds are ready to do direct copy
* Fill outbound tag info
* Splice now checks capalibility from all outbounds
* Fix unit tests
It seems the root cause is if the flag set at the inbound pipe reader, it is a race condition and freedom outbound can possibly do splice at the same time with inbound xtls writer.
Now we set the flag at the earliest and always do splice at the next buffer cycle.
- Vision now use traffic states to capture two-way info about a connection
- XTLS is de-couple with Vision, it only read traffic states to switch to direct copy mode
- fix a edge case error when Vision unpadding read 5 command bytes
- Add outbound name
- Add outbound conn in ctx
- Refactor splice: it can be turn on from all inbounds and outbounds
- Refactor splice: Add splice copy to vless inbound
- Fix http error test
- Add freedom splice toggle via env var
- Populate outbound obj in context
- Use CanSpliceCopy to mark a connection
- Turn off splice by default
* Increase some tls test timeout
* Fix TestUserValidator
* Change all tests to VMessAEAD
Old VMess MD5 tests will be rejected and fail in 2022
* Chore: auto format code
copilot-swe-agent[bot]