Inquiry on Sequence Number Check for SYN Packets in fake-tcp/src/lib.rs

[luhengsw]

I am currently utilizing your fake-tcp library and came across a behavior in the code that I would like to understand better. Specifically, the code in fake-tcp/src/lib.rs has a conditional check for a TCP SYN packet's sequence number being zero:

// SYN seen on listening socket
if tcp_packet.get_sequence() == 0 {
    // ...code to handle SYN packet...
} else {
   // ..send RST to source...
}

During my use of shadowsocks -> phantun -> wireguard, I've noticed that when the TCP sequence number is not zero, the connection cannot be established and a RST signal is received.

Could you please clarify if setting the sequence number to zero is based on a particular protocol consideration, or is it intended to filter out certain incorrect TCP packets? This behavior seems to deviate from the standard TCP three-way handshake, where the initial sequence number does not necessarily need to be zero.

Understanding the rationale behind this decision would greatly help in configuring my setup correctly and possibly adjusting the handling of the SYN packet if needed.

Thank you for your time and assistance.

[dndx]

You can not actually run fake-tcp with a real TCP stack, it simply won't work. fake-tcp must be talking with another fake-tcp for it to work. The implementation makes certain simplifications to help minimize the implementation burden, hence the "fake" part in the name.

[wangyu-]

The "fake" part in faketcp is not only about reduce implementation burden.

It's more because of real tcp have poor performance tunneling udp (head-of-line blocking, non-disableable retransmition, non-disableable congestion control).

Also because real tcp have poor performance when tunneling another layer of tcp (see tcp-over-tcp problem)

[dndx]

@wangyu- Yes. That's what I meant, fake-tcp (and udp2raw for that matters) are not RFC compliant TCP implementations, so the answer to @luhengsw 's question, there are no specific reasons, I just didn't need to implement a real initial sequence number generator.

However, one interesting side effect of this decision seems to be that random port scanners on the internet have harder time talking with Phantun because most of them don't use 0 as initial sequence number and it will appears as if the port is not open. It might also accidentally helped reducing these noise from random scanners too which seems to be a (small) advantage 😂