fix data-fin in 'dss' and 'add_addr' tests

[dcaratti]

on recent kernels (5.9-rc1+), a call to close() causes the transmission of a
regular ack having the DATA FIN bit set. This bit is acknowledged by the
peer and then subflows are closed with TCP FIN: adjust tests in the
'dss' and 'add_addr' folders accordingly.

Closes: multipath-tcp/mptcp_net-next#69
Signed-off-by: Davide Caratti dcaratti@redhat.com

[matttbe]

it looks good to me!
I guess we can merge this, just a few questions and ideas!

Maybe we should add a new data_fin directory with some dedicated tests: verifying we still accept DATA_FIN in FIN+ACK like before, check what happens if everything is closed without the DATA_FIN, etc. :)
Maybe @mjmartineau has some ideas or already has .pkt files, we never know :-)

Mat: may you review this if you don't mind? :)

[matttbe]

why do we need to receive this ACK twice?

[mjmartineau]

I agree with what @dcaratti and @matttbe mentioned in the overall conversation - this should have dack8=102.

[matttbe]

(I didn't check) do we still have tests validating we can receive a DATA_FIN in the FIN+ACK like before?

[matttbe]

could we here receive a DATA+FIN in this FIN+ACK? (just to make sure it is still accepted or maybe we should add a dedicated test for that?)

[mjmartineau]

I'd be surprised to see a TCP FIN here without dack8=1002 and a DATA_FIN. As discussed in the top-level pull request conversation, it's fine if the full handshake is tested in another folder

[matttbe]

should we add another packet with the > F. to always check we have the FIN, not just the DATA+FIN?
(or maybe we have other tests validating that already? or should we validate that in specific DATA_FIN tests?)

[matttbe]

same here for the FIN+ACK?

[dcaratti]

On Mon, 2020-08-24 at 10:15 -0700, Matthieu Baerts wrote: @matttbe commented on this pull request. it looks good to me! I guess we can merge this, just a few questions and ideas! Maybe we should add a new data_fin directory with some dedicated tests: verifying we still accept DATA_FIN in FIN+ACK like before, check what happens if everything is closed without the DATA_FIN, etc. :) Maybe @mjmartineau has some ideas or already has .pkt files, we never know :-) Mat: may you review this if you don't mind? :) In gtests/net/mptcp/dss/dss_ssn_specified_client.pkt: > +0.4 close(3) = 0 -// SSN should be 0 for DATA-FIN packets carrying no data at all -+0.0 > F. 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop> ++0.0 > . 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop> ++0.0 < . 1001:1001(0) ack 101 win 450 <dss dack8=101 nocs> why do we need to receive this ACK twice?

this was meant to be a packet acking the data-fin. should it be dack8 = 102 (as it is dsn8=101 + dll = 1)

In gtests/net/mptcp/dss/dss_ssn_specified_client.pkt: > +0.4 close(3) = 0 -// SSN should be 0 for DATA-FIN packets carrying no data at all -+0.0 > F. 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop> ++0.0 > . 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop> (I didn't check) do we still have tests validating we can receive a DATA_FIN in the FIN+ACK like before?

you mean, a test where packetdrill closes MPTCP protocol before the kernel under test does the close() ? I think we don't have it (and yes, we should add it)

In gtests/net/mptcp/dss/mpc_with_data_server.pkt: > @@ -24,4 +24,6 @@ // read 100 bytes from the MPC+data +0.01 read(4, ..., 100) = 100 +0 close(4) = 0 ++0 > . 1001:1001(0) ack 101 <dss dack8=101 dsn8=1001 ssn=0 dll=1 nocs fin, nop, nop> ++0 < F. 101:101(0) ack 1001 win 225 <dss dack8=1001 nocs> could we here receive a DATA+FIN in this FIN+ACK? (just to make sure it is still accepted or maybe we should add a dedicated test for that?)

same as above

In gtests/net/mptcp/add_addr/add_addr_client.pkt: > @@ -21,4 +21,4 @@ +0.0 < . 1:1(0) ack 101 win 256 <nop,nop,TS val 705 ecr 305,add_address addr[saddr] hmac=auto,dss dack8=101 dll=0 nocs> +0.4 close(3) = 0 -+0.0 > F. 101:101(0) ack 1 <nop, nop,TS val 494 ecr 700,dss dack4=1 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop> ++0.0 > . 101:101(0) ack 1 <nop, nop,TS val 494 ecr 700,dss dack4=1 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop> should we add another packet with the > F. to always check we have the FIN, not just the DATA+FIN? (or maybe we have other tests validating that already? or should we validate that in specific DATA_FIN tests?)

/me trying a generic answer below

In gtests/net/mptcp/add_addr/add_addr_server.pkt: > @@ -22,4 +22,4 @@ +0.3 read(4, ..., 1000) = 1000 +0 close(4) = 0 -+0 > F. 1:1(0) ack 1001 <dss dack8=1001 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop> ++0 > . 1:1(0) ack 1001 <dss dack8=1001 dsn8=1 ssn=0 dll=1 nocs fin, nop, nop> same here for the FIN+ACK?

/me trying a generic answer below: for tests that end with a call to close(), in the kernel under test, the minimum check is to ensure that the next packet is outbound, does not have the TCP FIN bit set, but has DSS and DATA FIN set. This would probably reduce the diffstat of this patch at the minimum. Then, in a separate folder, we can add a case for: 1) validating FIN+ACK -> ACK for each direction after the DATA FIN 2) trying reading data on a socket after the DATA_FIN has been ACKED by peer 3) other test cases? many, according to the Appendix D of the RFC :)

…

-- davide

[matttbe]

>  +0.4 close(3) = 0
-// SSN should be 0 for DATA-FIN packets carrying no data at all
-+0.0   > F. 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop>
++0.0   > . 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop>
++0.0   < . 1001:1001(0) ack 101 win 450 <dss dack8=101 nocs>

why do we need to receive this ACK twice?

this was meant to be a packet acking the data-fin. should it be
dack8 = 102 (as it is dsn8=101 + dll = 1)

OK, that would make more sense (line 24: dack8=101, line 26: dack8=102). I guess you are going to change that, right?

(I didn't check) do we still have tests validating we can receive a DATA_FIN in the FIN+ACK like before?

you mean, a test where packetdrill closes MPTCP protocol before the
kernel under test does the close() ? I think we don't have it (and yes,
we should add it)

Sorry no I mean: do we still have other tests validating we accept DATA_FINs in a dedicated ACK (new behaviour) and in a FIN+ACK (old behaviour, before Mat's modifications).

So:

+0.0 < F. x:x(0) ack y <(...) nocs fin (...)> // FIN+ACK + DATA_FIN

and:

+0.0 < . x:x(0) ack y <(...) nocs fin (...)> // Dedicated DATA_FIN
+0.0 < F. x:x(0) ack y <(...)> // FIN+ACK

for tests that end with a call to close(), in the kernel under test, the
minimum check is to ensure that the next packet is outbound, does not
have the TCP FIN bit set, but has DSS and DATA FIN set. This would
probably reduce the diffstat of this patch at the minimum.

Then, in a separate folder, we can add a case for:

Sounds good to me, we can create a new folder later. If needed, we can create a new GH issue not to forget about that.

[mjmartineau]

I agree with what @dcaratti and @matttbe mentioned in the overall conversation - this should have dack8=102.

[mjmartineau]

If this is sent in response to line 27's dack8=102, then it shouldn't need a data mapping (dsn/ssn/dll or the DATA_FIN flag). However if it was sent before processing the dack8=102 packet then line 28 could look like this. Is this based on observed packet captures or expected behavior?

[mjmartineau]

Like the ack in dss_ssn_specified_client.pkt line 27, dack8 should move forward if DATA_FIN was processed. I need to capture some packets with the latest export branch and see what current behavior is, there were some cases with extra acks.

[mjmartineau]

I'd be surprised to see a TCP FIN here without dack8=1002 and a DATA_FIN. As discussed in the top-level pull request conversation, it's fine if the full handshake is tested in another folder

[dcaratti]

>  +0.4 close(3) = 0
-// SSN should be 0 for DATA-FIN packets carrying no data at all
-+0.0   > F. 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop>
++0.0   > . 101:101(0) ack 1001 <nop, nop,TS val 100 ecr 700,dss dack8=1001 dsn8=101 ssn=0 dll=1 nocs fin, nop, nop>
++0.0   < . 1001:1001(0) ack 101 win 450 <dss dack8=101 nocs>

why do we need to receive this ACK twice?

this was meant to be a packet acking the data-fin. should it be
dack8 = 102 (as it is dsn8=101 + dll = 1)

OK, that would make more sense (line 24: dack8=101, line 26: dack8=102). I guess you are going to change that, right?

yes, will re-submit the PR (hopefully, today)

(I didn't check) do we still have tests validating we can receive a DATA_FIN in the FIN+ACK like before?

you mean, a test where packetdrill closes MPTCP protocol before the
kernel under test does the close() ? I think we don't have it (and yes,
we should add it)

Sorry no I mean: do we still have other tests validating we accept DATA_FINs in a dedicated ACK (new behaviour) and in a FIN+ACK (old behaviour, before Mat's modifications).

So:

+0.0 < F. x:x(0) ack y <(...) nocs fin (...)> // FIN+ACK + DATA_FIN

and:

+0.0 < . x:x(0) ack y <(...) nocs fin (...)> // Dedicated DATA_FIN
+0.0 < F. x:x(0) ack y <(...)> // FIN+ACK

I think we don't have them. I did a quick check on the existing code: either tests end with a close(), or they don't test cases where the connection is teared down by an inbound packet. Does it make sense to change one of the above test cases to remove the call to close() and replace it with a DATA FIN?

for tests that end with a call to close(), in the kernel under test, the
minimum check is to ensure that the next packet is outbound, does not
have the TCP FIN bit set, but has DSS and DATA FIN set. This would
probably reduce the diffstat of this patch at the minimum.
Then, in a separate folder, we can add a case for:

Sounds good to me, we can create a new folder later. If needed, we can create a new GH issue not to forget about that.

makes sense!

[matttbe]

Again sorry for the delay! The modifications you did since last time looks good to me!