Socks: `AssociatePacketConn.WriteTo` returns `n` with header length
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 131
- Forks
- 109
- PR merge metrics
- No merged PRs in 30d
Description
My observation is that because the buffer passed to WriteTo includes the header, the returned n (number of bytes written) reflects the total length, including this header.
I have referred to other popular SOCKS implementations, and it seems they do not include the header length in the returned n for similar operations.
https://github.com/wzshiming/socks5/blob/c06aae6747c6d36ee8c5994675d7b223cdcf6540/udp.go#L53-L71
Their n are all payload's length.
This difference in behavior leads me to wonder if this is an intended feature of the SagerNet/sing implementation, or if there's another reason for this design choice.
Could you please clarify if this behavior is by design and, if so, the rationale behind it?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Inspect protocol/socks/packet.go at lines 59-73 to trace how AssociatePacketConn.WriteTo builds its buffer and calculates n. Compare that behavior with the linked SOCKS implementations, then determine whether n should represent the payload or the header-inclusive buffer and document the confirmed design or needed change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100