Open nvelozsavino opened 1 year ago
Honestly I have not been working on the TCP implementation for quite long time now (basically since version 1.x) so it may contain bugs and features like SACK/SACKPERM options are not supported. I am going to focus on improving the TCP implementation once the PyTCP version 3.0 is released (sometime in 2025).
Sorry it took long time to reply... life and work... :) If you wanted to help out improve TCP I'd more than happy to get such help.
When I'm using the tun/tap interface on windows, I can connect a TCP socket through that interface, and watch the packets in Wireshark.
s=sequence number a=acknowledge number
My Client sent a SYN (s=X, a=0) (With the SACK_PERM and timeouts options) The server replies with the SYN,ACK (s=Y,a=X+1) and my client ACK that messages (s=X+1,a=Y+1)
PyTCP does this as well without a problem, except it doesn't use the SACK_PERM or timeout options
The problem comes after that:
the server sends an empty TCP package with s=Y, a=X+1 (TCP Keep-Alive) and my client responds with s=X+1,a=Y+1 (TCP Keep-Alive ACK)
Wireshark detects this messages as TCP Keep-Alive and TCP Keep-Alive ACK
this sequence keeps happens every 3 seconds until something is send, and the sequence and ack gets incremented on the response
On PyTCP the TCP Keep-Alive is ignored because it "doesn't fit into receive window" and there's no ACK to this keep alive
Eventually, the server sends a packet with the RESET bit set and the connection is dropped.
is this behaviour different because the SYN didn't have the SACK_PERM option or is something that's missing in the PyTCP stack?