mptcp: fullmesh fix typo in comment

Signed-off-by: Niels Laukens <niels.laukens@innovatie.vrt.be>
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Handle a full accept-queue correctly

In MPTCP, if the accept-queue is full, a call to tcp_syn_flood_action is
done. We need to do the same.

If it is a MP_JOIN, we will be redirected to mptcp_do_join_short. Later
there will be the check for the accept-queue.

Fixes: 5a5ff876a64ed (mptcp: add mptcp specific conn_request function)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Correctly handle MPTCP if it is set/unset by the app

We allow to enable/disable MPTCP through the application by setting the
sysctl mptcp_enabled to 2. Thus, in is_mptcp_enabled, we have to check
for this flag as well.

Fixes: 4f42b1051e962 (mptcp: use mptcp specific inet request ops)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Do not retransmit third ack if we are no more pre-established

It may be that the timer fires, and just then we receive the fourth ack.
In this case, mptcp_ack_handler will wait on the meta-lock until the
fourth ack has been processed and set pre_established to 0.

As we get the lock in mptcp_ack_handler, we will then assume that we
still need to retransmit the third ack. We should not. So, we add a
check for pre_established in the mptcp_ack_handler.

Fixes: 0629ea35ab8ed (4-way handshake during subflow establishment)
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
mptcp: Kill request-socket if meta is closing

It may be that the meta is in close-state while pending request-sockets
are still waiting (e.g., through shutdown()). If then the third ACK
comes in, we reply with a RST, without killing the request-socket
(because of the if then goto reset_and_discard).

If we end up in mptcp_v4_do_rcv and for one reason or another we reply
with a RST, we should make sure that the request-socket is closed
properly too. Otherwise, he will be hanging around there forever.

Additionally, the client might reuse the 5-tuple for another connection,
and make it actually match on this request-sock. Then, the stack gets
confused because it receives a SYN+MP_CAPABLE on a request-socket who
expects a JOIN.

So, we fix this simply by looking up the request-socket and closing it.

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