mptcp: Do not send the remove-addr twice on the master-socket

When removing the IP from a master-sk and the socket is owned by the
user, we end up in full_mesh_release_sock. There, we iterate over the
sockets and check if the IP is still there. If not, we remove it.

The loc_id of tcp_sk(sk)->mptcp is the local address-id, set to 0 on the
master-sk. As this check mpcb->master_sk == sk returns true, we actually
already did call update_remove_address with 0 as loc_id.

So, we can avoid this double-call.

Fixes: c31d21d039d (Modularize the path-manager)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix fullmesh path-manager address removal

There were still some issues.

First, update_remove_addrs with addr_id 0 on a master-sk is wrong.
Because, it will also update announced_v4_addrs - which will then be set
incorrectly.

Then, this "if (!found)" should have been the opposite. If we found a
subflow, there is no need to call again update_remove_addrs.

So, we fix this by splitting update_remove_addrs in two.

First, announce_remove_addr, which based on the loc_id will announce the
remove-addr message.

Second, update_addr_bitfields, which does a simple & with loc4_bits to
update the bitfields.

Fixes:a6f8c5ab66cf (mptcp: Handle address-events differently)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Use inet_rcv_saddr and rcv_saddr for /proc/net/mptcp

This patch alters inet_saddr/saddr to inet_rcv_saddr/rcv_saddr to get
source address for /proc/net/mptcp.

That's the way it is done in get_tcp4_sock and get_tcp6_sock.

Fixes: 5ad9689e4b6f8 (Update /proc/net/mptcp_pm to be like /proc/net/tcp)
Signed-off-by: Kenjiro Nakayama <nakayamakenjiro@gmail.com>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix shift-sack-data for MPTCP

If we are shifting sack'd data, we are removing one skb from the
write-queue. This skb will be holding a DSS-option in tcp_skb_cb->dss.

By removing the skb, the dss-option is lost forever and (may) never
reach the receiver.

So, we cannot shift sack'd data.

Fixes: f17b29179f97e (TSO Support for MPTCP)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Allow receiving splitted data-fin without mapping on last skb

It may be, that we receive a mapping covering two segments. This mapping
may include a DATA_FIN and it may be that the last of these two segments
does not have a DSS-option. Then, mptcp_is_data_fin2() will always be
false and we do not set the fin-bit on the segment.

Fixes: 47080a0c11823 (Simplify tcp read code from application)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: fallback to zero-window-probes if subflow's window is 0

Actually, the check for subflow's window is done always, except when
sending window-probes. In TCP, these window-probes become
zero-window-probes if seq >= wnd_end. In MPTCP that check is only done for
the meta-window. But, it may be that the subflow chosen by
get_available_subflow actually has seen a zero-window. Then, we will
fragment to a zero-sized packet with data-length = 0,
which should never be done.

This patch changes the logic in get_available_subflow, to always check
for the window, except when coming from the probe-timer. In this case,
we just check for seq >= wnd_end. Additionally, if in the probe-timer no
available subflow was found (e.g., all have zero-window or no space in
cwnd), then we switch over to zero-window-probes.

To reproduce:

+0      socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0      setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0      bind(3, ..., ...) = 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,mp_capable a> sock(3)
+0      > S. 0:0(0) ack 1 win 28800 <mss 1460,mp_capable b> sock(3)
+0      < . 1:1(0) ack 1 win 29200 <mp_capable a b> sock(3)

+0      accept(3, ..., ...) = 4

+0  < S 0:0(0) win 32792 <mss 1460,mp_join_syn backup=0 address_id=0 token=sha1_32(b)> sock(5)
+0  > S. 0:0(0) ack 1 <mss 1460,mp_join_syn_ack backup=0 address_id=0 sender_hmac=trunc_l64_hmac(b a) > sock(5)
+0.1  < . 1:1(0) ack 1 win 32792 <mp_join_ack sender_hmac=full_160_hmac(a b)> sock(5)
+0 mp_join_accept(5) = 6
+0  > . 1:1(0) ack 1 <...> sock(6)

/* Client send 1000 bytes */
+0      write(4, ..., 1000) = 1000
+0      > P. 1:1001(1000) ack 1 <dss dack4 dsn4> sock(4)
/* We also set the window to 0 for this subflow */
+0      < . 1:1(0) ack 1001 win 0 <dss dack4> sock(4)

/* Give the mptcp-level 500 bytes of window, to trigger the probe-timer */
+0      < . 1:1(0) ack 1 win 500 <dss dack4> sock(6)

/* Now, close this subflow */
+0      < R 1:1(0) ack 1 win 500 sock(6)

/* Client send 1000 bytes */
+0.5    write(4, ..., 1000) = 1000
+0.6    > . 1000:1000(0) ack 1 <dss dack4> sock(4)
+0      < . 1:1(0) ack 1001 win 500 <dss dack4> sock(4)
+0.6    > P. 1001:1501(500) ack 1 <dss dack4 dsn4> sock(4)
+0      < . 1:1(0) ack 1501 win 500 <dss dack4> sock(4)
+0      > P. 1501:2001(500) ack 1 <dss dack4 dsn4> sock(4)
+0      < . 1:1(0) ack 2001 win 500 <dss dack4> sock(4)

Fixes: a3a0841ffd (mptcp: Fix Bug #45: Split segment when probing for window opening)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: handle fastopen_req at the meta-level

fastopen uses the field fastopen_req in struct tcp_sock to store information
of the data sent inside the SYN. When we create the master_sk, this data (pointer)
is copied to the master_sk. fastopen_req is supposed to be freed in tcp_sendmsg
(after waiting that the connection is established) -- which will happen for the
meta_sk. If the connection abort before the establishment the memory will be freed
in tcp_v4_destroy_sock -- which will happen for the master_sk. This causes a double
free error.

This patch does not ensure that TFO and MPTCP will work together. MPTCP will
actually fallback to regular TCP. The patches implementing the support of TFO in
the MPTCP stack will be sent later.

Fixes: cf60af03ca4e7 (net-tcp: Fast Open client - sendmsg(MSG_FASTOPEN))
Signed-off-by: Gregory Detal <gregory.detal@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Enter quickack when receiving MPTCP out-of-order data

[Upstream commit 34d2ab99c0c7bc5db62cf928a887e5b8e5d220a3]

It may happen that a subflow is not sending quickacks, because of the
conditions in __tcp_ack_snd_check. In this function, a quickack will be
sent, if more than one MSS has been received between the last window
announcment AND the current rcv-next and additionally, the window
changes. In TCP this results in quick-acks when receiving in-order data
AND the window increases, which is good enough as it still allows the
sender to progress. Additionally, tcp_cleanup_rbuf will send acks if the
right edge of the window advances as well. Finally, quickacks are sent
for out-of-order data to allow quick recovery from a loss.

But, with MPTCP if we receive out-of-order data at the MPTCP-level, we do
not send a quickack. This, because it is not necessary for
loss-recovery. However, it might be that we are getting closer to the
right edge of the window. In this case, we should send acks so that the
sender can act accordingly (the NSDI algorithm). But, subflows may not
have their conditions in __tcp_ack_snd_check result in true, because
the window itself is not increasing.

What then will happen is that delayed acks are sent and the sender is
actually blocked during 40ms (the time for the quickack being sent).

We should send quickacks when we are getting close to the right edge of
the window. So, this patch changes it, so that if we receive
out-of-order data at the MPTCP-level, we go into quickack-mode. The
quickack mode will then send (at most) 16 quickacks.

Fixes: Zero-day bug
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	include/net/tcp.h

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Copy path_mask when fragmenting

[Upstream commit c12cabb8a96f1a7da00f7a7e9beb666b62b024d1]

We need to copy the path-mask, because the segment may be a reinjection.
In this case, we need to keep the path-masks consistent.

Fixes: Zero-day bug
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Disable nagle on subflows

[Upstream commit 7e583c002b99fc605bc57c4974f85b1b415920c5]

Nagle is entirely handled at the MPTCP-layer. We should not wait for
more data at the subflows.

Fixes: Zero-day bug
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Correctly check for the state in mptcp_sk_can_recv

[Upstream commit b808cf3af856232910fe58e642f315759d9def01]

As we compare it with the flags, we have to use TCPF_*.
Otherwise, the check is just simply wrong... Surprising how long this
bug has been in there.

Fixes: 316f688300c09 (Fix: Don't account non-established subflows in send/rcv-buffer)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Do not continue processing when meta has been closed

[Upstream commit c30b683da0db73e60d4695b45be665adc51c568b]

The reception of the data-fin changes the state of the meta-socket.
After this reception, we should stop processing data.

After mptcp_queue_skb and the reception of a data-fin, it will return
-1. Then, in mptcp_data_ready, we goto restart. So, just move restart a
bit higher and fix the check.

The problem is still present, if the meta has gone into time-wait.
Fixing this is much more complex. Handling the meta correctly in
time-wait cannot be done with mptcp_data_ready. We probably should
create a real time-wait socket for the meta and do the processing in
tcp_tw_state_process. But that's far from a trivial fix...

Issue #39: https://github.com/multipath-tcp/mptcp/issues/39

Fixes: Zero-day bug
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Always send the third ack of the 3-way handshake

[Upstream commit 160a38db598ca7be1e42c45ba0d826d79029dfd9]

There is no space to combine an MP_CAPABLE (or MP_JOIN) with data, as
there is not enough option space.

So, we send it out directly.

Fixes: Zero-day bug
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/ipv4/tcp_input.c

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Always set the PSH-flag when probing for the window

[Upstream commit c88b8b66d78e608d1aaa67ab16781d245d2bfc32]

tcp_write_wakeup always sets the PSH-flag. We have to do the same.

Fixes: a23c25090d7f9 (Handle probe-timer at the meta-level)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/mptcp/mptcp_output.c

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix TCP_DEFER_ACCEPT

[Upstream commit 035eea36b1bf96acae038438f58af225bb88f5ef]

The socket-option DEFER_ACCEPT allows to defer the accept of a new
connection until data has been received (or a timer expired).

For MPTCP the story is twofold:

1. On the initial subflow we still want to support defer-accept.
2. On subsequent subflows we do not want to support it, because we have
   to reply with the third ack with a fourth ack (after verifying the
   hmac)

First, to allow defer-accept on the initial subflow, we remove the
additional check in tcp_check_req. The comment there says that we do not
support defer-accept because we want to support receiving options in the
third ack. But, this behavior is already broken, as one can see that
'mopt' is not used at all in mptcp_check_req_master. If we want to
support receiving options in the third ack, we should do as the comment
suggests - storing them in the requests socket.

Second, to prevent defer-accept on additional subflows, we simply clear
the flag in the meta-sk. We also must prevent setting defer-accept on an
established meta-sk. This, by adding a check in do_tcp_setsockopt.

Fixes: Zero-day bug
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Fix IP_RECVERR

[Upstream commit 6d4820e0e4f270483c81605924f4e6920107fdb2]

The socket-option IP_RECVERR forces sockets to report soft errors to the
application. With MPTCP, this reporting ends up in
mptcp_sock_def_error_report, closing the socket. That's not really what
we want. soft-errors are not really a concern for the subflows. We can
simply continue.

So, we should unset IP_RECVERR on subflows, so that they do not report
the error.

Longterm, we should probably define when soft errors need to be reported
back to the application in case MPTCP is being used.

Issue #46: https://github.com/multipath-tcp/mptcp/issues/46

Fixes: Zero-day bug
Reported-by: Laurent Deru <laurent.deru@cetic.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>

Conflicts:
	net/mptcp/mptcp_ctrl.c

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Explicitly set reserved-fields of MP_JOIN to 0

[Upstream commit f44490e5d35d6c4f901ac09c973e9be7f14d3f10]

In the third ack of the MP_JOIN, the address-id is actually a reserved
field (cfr. RFC 6824, p. 21). So, we should set the reserved field
explicitly to 0 as requested by the RFC.

Actually, prior (by chance) this was still correct, because opts is
memset'ed to 0 and addr_id is not changed for the third ack in
mptcp_established_options.

Fixes: Zero-day bug
Reported-by: Fabien Duchene <fabien.duchene@uclouvain.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
New maintenance release

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
New Saucy release

Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>