Skip to content
This repository has been archived by the owner on May 20, 2020. It is now read-only.

tcp.handshake.synSentState() may have logical problems #13

Open
fanpei91 opened this issue Nov 1, 2018 · 2 comments
Open

tcp.handshake.synSentState() may have logical problems #13

fanpei91 opened this issue Nov 1, 2018 · 2 comments

Comments

@fanpei91
Copy link

fanpei91 commented Nov 1, 2018

I think the func code L178-L239 has logical problems, look at the Basic 3-Way Handshake for Connection Synchronization:

Basic 3-Way Handshake for Connection Synchronization

TCP B can split <CTL=SYN,ACK> into <CTL=ACK> and <CTL=SYN>, then send them successively, so L194 will block the TCP B's <CTL=ACK>.

If you want TCP A only accept <CTL=SYN,ACK> from TCP B, L224-L236 is unnecessary.

@hbhasker
Copy link
Contributor

hbhasker commented Nov 1, 2018

I think you are right. We are probably not handling a simulataneous open case correctly. I thought we had a test for this but maybe not.

Care to send a patch w/ test for simultaneous open(
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-4.htm)

@tamird
Copy link
Contributor

tamird commented Feb 7, 2020

@hbhasker should this be migrated to the gvisor repo?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants