diff mbox series

Fastclose packetdrill test cases

Message ID 20201117194712.23209-1-fw@strlen.de
State RFC, archived
Headers show
Series Fastclose packetdrill test cases | expand

Commit Message

Florian Westphal Nov. 17, 2020, 7:47 p.m. UTC 
I've been working on packetdrill test cases to cover the 'fastclose'
option.

I've included this as a patch -- no need to apply, I can do a pull
request via github.  I'm only including it as a reference.
A few questions below.

It covers three scenarios:
1. fastclose_with_ack.pkt: single subflow.
   Test ACK with fastclose & bogus key has no effect.
   Test ACK with fastclose & expected key closes the mptcp connection:
   Further data should result in a RST.

2. fastclose_with_rst.pkt: single subflow.
   Test RST with fastclose & bogus key closes the subflow
   but keeps mptcp socket around.
   This sends a JOIN request after the RST, its expected to
   succeed.
   Then, another RST is sent, this time with correct fastclose.
   RST is expected again.

3. fastclose_with_rst_multi.pkt: same as 2), but two subflows
   are created before the fastclose is sent on the new subflow.
   Its expected that the kernel sends a RST on the original
   subflow.

Is my understanding of the expected beahvior correct?
In particular:
 1. RST+fastclose always closes the subflow, even if the fastclose
    key doesn't match.
 2. RST+fastclose has no effect whatsoever if the RST fails window
    checks, even if the fastclose would have a correct key.

Is any important scenario missing that should be covered?

Thanks.
---
 .../mptcp/fastclose/fastclose_with_ack.pkt    | 36 +++++++++++++++
 .../mptcp/fastclose/fastclose_with_rst.pkt    | 44 +++++++++++++++++++
 .../fastclose/fastclose_with_rst_multi.pkt    | 43 ++++++++++++++++++
 3 files changed, 123 insertions(+)
 create mode 100644 gtests/net/mptcp/fastclose/fastclose_with_ack.pkt
 create mode 100644 gtests/net/mptcp/fastclose/fastclose_with_rst.pkt
 create mode 100644 gtests/net/mptcp/fastclose/fastclose_with_rst_multi.pkt

Comments

Mat Martineau Nov. 18, 2020, 1:28 a.m. UTC | #1 
On Tue, 17 Nov 2020, Florian Westphal wrote:

> I've been working on packetdrill test cases to cover the 'fastclose'
> option.
>
> I've included this as a patch -- no need to apply, I can do a pull
> request via github.  I'm only including it as a reference.
> A few questions below.
>
> It covers three scenarios:
> 1. fastclose_with_ack.pkt: single subflow.
>   Test ACK with fastclose & bogus key has no effect.
>   Test ACK with fastclose & expected key closes the mptcp connection:
>   Further data should result in a RST.
>
> 2. fastclose_with_rst.pkt: single subflow.
>   Test RST with fastclose & bogus key closes the subflow
>   but keeps mptcp socket around.
>   This sends a JOIN request after the RST, its expected to
>   succeed.
>   Then, another RST is sent, this time with correct fastclose.
>   RST is expected again.
>
> 3. fastclose_with_rst_multi.pkt: same as 2), but two subflows
>   are created before the fastclose is sent on the new subflow.
>   Its expected that the kernel sends a RST on the original
>   subflow.
>
> Is my understanding of the expected beahvior correct?
> In particular:
> 1. RST+fastclose always closes the subflow, even if the fastclose
>    key doesn't match.

Yeah, I would expect the TCP RST to be handled as a subflow reset even 
when the MP_FASTCLOSE is ignored due to key mismatch.

> 2. RST+fastclose has no effect whatsoever if the RST fails window
>    checks, even if the fastclose would have a correct key.

I agree on this one too.

>
> Is any important scenario missing that should be covered?

The three you listed above seem like the most important. Is the handling 
of fastclose-using-ack and fastclose-using-rst for multiple subflows 
similar enough that a "fastclose with ack, multiple subflows" test case 
doesn't add much value?

--
Mat Martineau
Intel
Florian Westphal Nov. 18, 2020, 9:06 a.m. UTC | #2 
Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:
> > Is my understanding of the expected beahvior correct?
> > In particular:
> > 1. RST+fastclose always closes the subflow, even if the fastclose
> >    key doesn't match.
> 
> Yeah, I would expect the TCP RST to be handled as a subflow reset even when
> the MP_FASTCLOSE is ignored due to key mismatch.
> 
> > 2. RST+fastclose has no effect whatsoever if the RST fails window
> >    checks, even if the fastclose would have a correct key.
> 
> I agree on this one too.
> 
> > 
> > Is any important scenario missing that should be covered?
> 
> The three you listed above seem like the most important. Is the handling of
> fastclose-using-ack and fastclose-using-rst for multiple subflows similar
> enough that a "fastclose with ack, multiple subflows" test case doesn't add
> much value?

Right, I could add that.  Expected difference is that we see two reset
packets (one for each subflow) instead of one compared to the 'rst' one.

I'll add a test.
diff mbox series

Patch

diff --git a/gtests/net/mptcp/fastclose/fastclose_with_ack.pkt b/gtests/net/mptcp/fastclose/fastclose_with_ack.pkt
new file mode 100644
index 000000000000..d6432fc79800
--- /dev/null
+++ b/gtests/net/mptcp/fastclose/fastclose_with_ack.pkt
@@ -0,0 +1,36 @@ 
+// connection initiated by packetdrill
+--tolerance_usecs=100000
+`../common/defaults.sh`
+
++0    `../common/server.sh`
+
++0    socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3
++0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+
++0    bind(3, ..., ...) = 0
++0    listen(3, 1) = 0
++0.0    < addr[caddr0] > addr[saddr0] S 0:0(0) win 65535 <mss 1460,nop,wscale 7,mpcapable v1 flags[flag_h] nokey>
++0.0 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 8,mpcapable v1 flags[flag_h] key[skey]>
++0.0 < . 1:1(0) ack 1 win 256 <mpcapable v1 flags[flag_h] key[ckey=2,skey]>
++0    accept(3, ..., ...) = 4
+
++0.0  < P. 1:1001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=1 ssn=1 dll=1000 nocs>
++0.0  >  . 1:1(0) ack 1001 win 264 <dss dack8=1001 nocs>
+
+// send ack fastclose with a key that should not match.
++0    < . 1001:1001(0) win 450 <mp_fastclose ckey=42 >
+
+// more data, expect ack
++1.0  < P. 1001:2001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=1001 ssn=1001 dll=1000 nocs>
++0.0  > . 1:1(0) ack 2001 win 272 <add_address addr[saddr1] hmac=auto,dss dack8=2001 nocs>
+
+// send another ack fastclose, this time with matching key
++0.1      < . 2001:2001(0) win 450 <mp_fastclose>
+// expect peer to reset all subflows now:
++0.01 > R. 1:1(0) ack 2001 win 272
+
+// more data, expect a reset and win0 (no socket anymore)
++1.0  < P. 2001:3001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=2001 ssn=2001 dll=1000 nocs>
++0.01 > R 1:1(0) ack 0 win 0
+
++0    close(4) = 0
diff --git a/gtests/net/mptcp/fastclose/fastclose_with_rst.pkt b/gtests/net/mptcp/fastclose/fastclose_with_rst.pkt
new file mode 100644
index 000000000000..d0cf45da0b40
--- /dev/null
+++ b/gtests/net/mptcp/fastclose/fastclose_with_rst.pkt
@@ -0,0 +1,44 @@ 
+// connection initiated by packetdrill
+--tolerance_usecs=100000
+`../common/defaults.sh`
+
++0    `../common/server.sh`
+
++0    socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3
++0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+
++0    bind(3, ..., ...) = 0
++0    listen(3, 1) = 0
++0.0    < addr[caddr0] > addr[saddr0] S 0:0(0) win 65535 <mss 1460,nop,wscale 7,mpcapable v1 flags[flag_h] nokey>
++0.0 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 8,mpcapable v1 flags[flag_h] key[skey]>
++0.0 < . 1:1(0) ack 1 win 256 <mpcapable v1 flags[flag_h] key[ckey=2,skey]>
++0    accept(3, ..., ...) = 4
+
++0.0  < P. 1:1001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=1 ssn=1 dll=1000 nocs>
++0.0  >  . 1:1(0) ack 1001 win 264 <dss dack8=1001 nocs>
+
+// send rst fastclose with a key that should not match.
++0     < R. 1001:1001(0) win 450 <mp_fastclose ckey=42 >
+
+// more data, but expect rst: the subflow is gone.
++1.0   < P. 1001:2001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=1001 ssn=1001 dll=1000 nocs>
++0.02  > R 1:1(0) ack 0 win 0
+
+// mp_join: supposed to work -- fastclose should have had no effect.
++0.1  < addr[caddr0] > addr[saddr0] S 0:0(0) win 65535 <mss 1460,nop,wscale 7,mp_join_syn address_id=0 token=sha256_32(skey)>
++0.0 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 8,mp_join_syn_ack address_id=0 sender_hmac=auto>
++0.0 < . 1:1(0) ack 1 win 256 <mp_join_ack sender_hmac=auto>
++0.0 > . 1:1(0) ack 1 win 256 <add_address addr[saddr1] hmac=auto,dss dack8=1001 nocs>
+
+// more data, resend.  should work now.
++0.0  < P. 1:1001(1000) ack 1 win 450 <nop,nop,dss dack8=1 dsn8=1001 ssn=1 dll=1000 nocs>
++0.0  >  . 1:1(0) ack 1001 win 264 <dss dack8=2001 nocs>
+
+// send another rst fastclose, this time with matching key
++0.1  < R. 1001:1001(0) win 450 <mp_fastclose>
+
+// more data, expect a reset and win0 (no socket anymore)
++1.0  < P. 2001:3001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=2001 ssn=1001 dll=1000 nocs>
++0.01 > R 1:1(0) ack 0 win 0
+
++0    close(4) = 0
diff --git a/gtests/net/mptcp/fastclose/fastclose_with_rst_multi.pkt b/gtests/net/mptcp/fastclose/fastclose_with_rst_multi.pkt
new file mode 100644
index 000000000000..da49ed2bfa68
--- /dev/null
+++ b/gtests/net/mptcp/fastclose/fastclose_with_rst_multi.pkt
@@ -0,0 +1,43 @@ 
+// connection initiated by packetdrill
+--tolerance_usecs=100000
+`../common/defaults.sh`
+
++0    `../common/server.sh`
+
++0    socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3
++0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+
++0    bind(3, ..., ...) = 0
++0    listen(3, 1) = 0
++0.0    < addr[caddr0] > addr[saddr0] S 0:0(0) win 65535 <mss 1460,nop,wscale 7,mpcapable v1 flags[flag_h] nokey>
++0.0 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 8,mpcapable v1 flags[flag_h] key[skey]>
++0.0 < . 1:1(0) ack 1 win 256 <mpcapable v1 flags[flag_h] key[ckey=2,skey]>
++0    accept(3, ..., ...) = 4
+
++0.0  < P. 1:1001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=1 ssn=1 dll=1000 nocs>
++0.0  >  . 1:1(0) ack 1001 win 264 <dss dack8=1001 nocs>
+
++0.2 < P. 1:3(2) ack 1 win 450 <mpcapable v1 flags[flag_h] key[skey,ckey] mpcdatalen 2,nop,nop>
++0.0 > . 1:1(0) ack 1001 <add_address addr[saddr1] hmac=auto,dss dack8=1001 dll=0 nocs>
+
+// add another subflow.
++0.5 < addr[caddr1] > addr[saddr1] S 0:0(0) win 65535 <mss 1460,nop,wscale 7,mp_join_syn address_id=2 token=sha256_32(skey)>
++0.0 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 8,mp_join_syn_ack address_id=0 sender_hmac=auto>
++0.0 < . 1:1(0) ack 1 win 256 <mp_join_ack sender_hmac=auto>
++0.0 > . 1:1(0) ack 1 win 256 <dss dack8=1001 nocs>
+
+// send more data.
++0.2  < P. 1001:2001(1000) ack 1 win 450 <nop, nop, dss dack8=1 dsn8=1001 ssn=1001 dll=1000 nocs>
++0    >  . 1:1(0) ack 1 win 256 <dss dack8=1001 dll=0 nocs>
+
+// send rst fastclose.  Out of window, so it should have no effect.
++0.1  < R. 1001:1001(0) win 450 <mp_fastclose>
++0  >  . 1:1(0) ack 1 win 256 <dss dack8=1001 dll=0 nocs>
+
+// again. fastclose on the 2nd subflow.
++0.1  < R. 1:1(0) win 450 <mp_fastclose>
+
+// expect peer to reset the original flow now:
++0.0  > addr[saddr0] > addr[caddr0] R. 1:1(0) ack 1001 win 264
+
++0    close(4) = 0