This repository has been archived by the owner on Apr 18, 2024. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
mptcp: Avoid last mptcp_sock_def_error_report warning
There is a packet-sequence that can end up closing an MPTCP-socket at the metae-level while in infinite-mapping mode without closing the subflow. This happens in the following sequence: +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, {sa_family = AF_INET, sin_port = htons(13000), sin_addr = inet_addr("192.168.0.1")}, ...) = 0 +0 listen(3, 1) = 0 +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 5 +0 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(5, {sa_family = AF_INET, sin_port = htons(13001), sin_addr = inet_addr("192.168.0.1")}, ...) = 0 +0 listen(5,1) = 0 +0 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7,mp_capable key_a> sock(3) +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7,mp_capable key_b> sock(3) +0.1 < . 1:1(0) ack 1 win 257 <mp_capable key_a key_b> sock(3) +0 accept(3, ..., ...) = 4 +0 < P. 1:11(10) ack 1 win 257 <dss dack4 dsn4> sock(4) +0 > . 1:1(0) ack 11 <dss dack4=11> sock(4) +0 write(4, ..., 100) = 100 +0 > P. 1:101(100) ack 11 <dss dack4=11 dsn4> sock(4) +0 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7,mp_join_syn address_id=0 token=sha1_32(key_b)> sock(5) +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7, mp_join_syn_ack backup=0 address_id=0 sender_hmac=trunc_l64_hmac(key_b key_a) > sock(5) +0 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7,mp_join_syn address_id=0 token=sha1_32(key_b)> sock(5) +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7, mp_join_syn_ack backup=0 address_id=0 sender_hmac=trunc_l64_hmac(key_b key_a) > sock(5) +0 < . 1:1(0) ack 1 win 32792 <mp_join_ack sender_hmac=full_160_hmac(key_a key_b)> sock(5) +0 mp_join_accept(5) = 6 +0 > . 1:1(0) ack 1 <...> sock(6) // reliably mp_join_ack +0 < F. 1:1(0) ack 1 win 257 <dss dack4 dsn4 FIN> sock(6) +0 > . 1:1(0) ack 2 <dss dack4=12> sock(6) +0.1 shutdown(4, SHUT_WR) = 0 +0 > F. 1:1(0) ack 2 <dss dack4 dsn4 FIN> sock(6) /* This triggers a fallback as there is no DATA_ACK. */ +0 < . 11:11(0) ack 101 win 257 sock(4) /* Incoming RST on a connection that has fallen back and meta has been close */ +0.1 < R. 11:11(0) ack 102 win 257 sock(4) +1 close(4) = 0 Problem is that the outstanding data on sock(4) was DATA_ACK'ed on sock(6). Thus, sequence-numbers our no more in-sync. We need to handle this properly. We know that at the beginning of a subflow all data sent on it will be in-order, tracked by last_end_data_seq. Thus, if last_end_data_seq is less then meta->snd_una, it means that we are out-of-sync and need to drain the subflow before incoming ACKs will allow to move the meta->snd_una forward. Fixes: Zero-day bug Signed-off-by: Christoph Paasch <cpaasch@apple.com> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> (cherry picked from commit ce507d8) Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> (cherry picked from commit edf6791) Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
- Loading branch information