mptcp: check fallback if opt dropped after first data

With the current kernel, the server incorrectly resets a connection if its first packet has data (< init window) and MPTCP options, but then the next ones no longer have MPTCP options. [1] The server should not reset this connection in this case, but do a fallback. It should reset the connection only if it has received a DATA_ACK, or data for more than the initial window (implying DATA_ACK have been received by the other peer) [2]. This new packetdrill test checks the expected behaviour. Link: multipath-tcp/mptcp_net-next#518 [1] Link: https://datatracker.ietf.org/doc/html/rfc8684#name-fallback [2] Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
multipath-tcp · Oct 3, 2024 · 36674f0 · 36674f0
1 parent 443d259
commit 36674f0
Showing 1 changed file with 30 additions and 0 deletions.
diff --git a/gtests/net/mptcp/dss/dss_drop_after_data_fallback.pkt b/gtests/net/mptcp/dss/dss_drop_after_data_fallback.pkt
@@ -0,0 +1,30 @@
+--tolerance_usecs=100000
+`../common/defaults.sh`
+
+0.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
+
+// 3WHS is OK
++0.0    <  S   0:0(0)                    win 65535  <mss 1460, sackOK, nop, nop, nop, wscale 6, mpcapable v1 flags[flag_h] nokey>
++0.0    >  S.  0:0(0)           ack 1               <mss 1460, nop, nop, sackOK, nop, wscale 8, mpcapable v1 flags[flag_h] key[skey]>
++0.1    <   .  1:1(0)           ack 1    win 2048                                              <mpcapable v1 flags[flag_h] key[ckey=2, skey]>
++0    accept(3, ..., ...) = 4
+
+// Data from the client with valid MPTCP options (no DATA_ACK: normal)
++0.1    <  P.  1:501(500)       ack 1    win 2048                                              <mpcapable v1 flags[flag_h] key[skey, ckey] mpcdatalen 500, nop, nop>
+// From here, the MPTCP options will be dropped by a middlebox
++0.0    >   .  1:1(0)           ack 501                                                        <dss dack8=501 dll=0 nocs>
++0.1   read(4, ..., 500) = 500
++0     write(4, ..., 100) = 100
+
+// The server replies with data, still thinking MPTCP is being used
++0.0    >  P.  1:101(100)       ack 501                                                        <dss dack8=501 dsn8=1 ssn=1 dll=100 nocs, nop, nop>
+// But the client already did a fallback to TCP, because the two previous packets have been received without MPTCP options
++0.1    <   .  501:501(0)       ack 101  win 2048
+
++0.0    <  P.  501:601(100)     ack 101  win 2048
+// The server should fallback to TCP, not reset: it didn't get a DATA_ACK, nor data for more than the initial window
++0.0    >   .  101:101(0)       ack 601