mptcp: Enter quickack when receiving MPTCP out-of-order data

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>
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
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
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
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 3.12 maintenance release

Signed-off-by: David Heidelberger <david.heidelberger@ixit.cz>