forked from google/packetdrill
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add more tests #3
Labels
good first issue
Good for newcomers
Comments
dcaratti
added a commit
that referenced
this issue
Jan 9, 2020
related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Jan 9, 2020
related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Jan 9, 2020
test fallback to TCP in the following conditions: - server replies with wrong protocol version - server replies with mp_capable flag 'B' set - server replies with mp_capable flag 'H' unset related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Jan 9, 2020
test fallback to TCP in the following conditions: - client sends a v0 SYN (might trigger false postitive when testing v0 kernel) - client sends a SYN with mp_capable flag 'B' set - client sends a SYN with mp_capable flag 'H' unset - client flips version to v0 in the 3rd ACK - client flips mp_capable flag 'B' in the 3rd ACK - client flips mp_capable flag 'H' in the 3rd ACK related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Jan 30, 2020
this exploits a "feature" in current MPTCP code, i.e. client will ack packets at TCP level but DACK will be increased only after data are read. This increased DACK will not reach the MPTCP endpoint unless "something" (e.g. a write() or a close()) is done at MPTCP socket level. Related-to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Jan 30, 2020
This exploits a "feature" in current MPTCP code, i.e. client will ack packets at TCP level but DACK will be increased only after data are read. This increased DACK will not reach the MPTCP endpoint unless "something" (e.g. a write() or a close()) is done at MPTCP socket level. Related-to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
Related: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
Related: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
Related: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
- move all v0 tests in a separate folder related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
test fallback to TCP in the following conditions: - server replies with wrong protocol version - server replies with mp_capable flag 'B' set - server replies with mp_capable flag 'H' unset related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
test fallback to TCP in the following conditions: - client sends a v0 SYN (might trigger false postitive when testing v0 kernel) - client sends a SYN with mp_capable flag 'B' set - client sends a SYN with mp_capable flag 'H' unset - client flips version to v0 in the 3rd ACK - client flips mp_capable flag 'B' in the 3rd ACK - client flips mp_capable flag 'H' in the 3rd ACK related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
this exploits a "feature" in current MPTCP code, i.e. client will ack packets at TCP level but DACK will be increased only after data are read. This increased DACK will not reach the MPTCP endpoint unless "something" (e.g. a write() or a close()) is done at MPTCP socket level. Related-to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 12, 2020
This exploits a "feature" in current MPTCP code, i.e. client will ack packets at TCP level but DACK will be increased only after data are read. This increased DACK will not reach the MPTCP endpoint unless "something" (e.g. a write() or a close()) is done at MPTCP socket level. Related-to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 13, 2020
test fallback to TCP in the following conditions: - client sends a v0 SYN (might trigger false postitive when testing v0 kernel) - client sends a SYN with mp_capable flag 'B' set - client sends a SYN with mp_capable flag 'H' unset - client flips version to v0 in the 3rd ACK - client flips mp_capable flag 'B' in the 3rd ACK - client flips mp_capable flag 'H' in the 3rd ACK related to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 13, 2020
this exploits a "feature" in current MPTCP code, i.e. client will ack packets at TCP level but DACK will be increased only after data are read. This increased DACK will not reach the MPTCP endpoint unless "something" (e.g. a write() or a close()) is done at MPTCP socket level. Related-to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
dcaratti
added a commit
that referenced
this issue
Feb 13, 2020
This exploits a "feature" in current MPTCP code, i.e. client will ack packets at TCP level but DACK will be increased only after data are read. This increased DACK will not reach the MPTCP endpoint unless "something" (e.g. a write() or a close()) is done at MPTCP socket level. Related-to: issue #3 Signed-off-by: Davide Caratti <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: