Skip to content
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

Open
dcaratti opened this issue Nov 21, 2019 · 0 comments
Open

add more tests #3

dcaratti opened this issue Nov 21, 2019 · 0 comments
Assignees
Labels
good first issue Good for newcomers

Comments

@dcaratti
Copy link
Owner

No description provided.

@dcaratti dcaratti added the good first issue Good for newcomers label Nov 21, 2019
@dcaratti dcaratti self-assigned this Nov 21, 2019
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]>
dcaratti pushed a commit that referenced this issue May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

1 participant