| Message ID | d4f2f87c56fa1662bbc39baaee74b26bc646e141.1583337038.git.pabeni@redhat.com |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net,v2] mptcp: always include dack if possible. | expand |
On Wed, 4 Mar 2020, Paolo Abeni wrote: > Currently passive MPTCP socket can skip including the DACK > option - if the peer sends data before accept() completes. > > The above happens because the msk 'can_ack' flag is set > only after the accept() call. > > Such missing DACK option may cause - as per RFC spec - > unwanted fallback to TCP. > > This change addresses the issue using the key material > available in the current subflow, if any, to create a suitable > dack option when msk ack seq is not yet available. > > v1 -> v2: > - adavance the generated ack after the initial MPC packet > > Fixes: d22f4988ffec ("mptcp: process MP_CAPABLE data option") > Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com> -- Mat Martineau Intel
From: Paolo Abeni <pabeni@redhat.com> Date: Wed, 4 Mar 2020 16:51:07 +0100 > Currently passive MPTCP socket can skip including the DACK > option - if the peer sends data before accept() completes. > > The above happens because the msk 'can_ack' flag is set > only after the accept() call. > > Such missing DACK option may cause - as per RFC spec - > unwanted fallback to TCP. > > This change addresses the issue using the key material > available in the current subflow, if any, to create a suitable > dack option when msk ack seq is not yet available. > > v1 -> v2: > - adavance the generated ack after the initial MPC packet > > Fixes: d22f4988ffec ("mptcp: process MP_CAPABLE data option") > Signed-off-by: Paolo Abeni <pabeni@redhat.com> Applied, thank you.
diff --git a/net/mptcp/options.c b/net/mptcp/options.c index 45acd877bef3..fd2c3150e591 100644 --- a/net/mptcp/options.c +++ b/net/mptcp/options.c @@ -334,6 +334,8 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb, struct mptcp_sock *msk; unsigned int ack_size; bool ret = false; + bool can_ack; + u64 ack_seq; u8 tcp_fin; if (skb) { @@ -360,9 +362,22 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb, ret = true; } + /* passive sockets msk will set the 'can_ack' after accept(), even + * if the first subflow may have the already the remote key handy + */ + can_ack = true; opts->ext_copy.use_ack = 0; msk = mptcp_sk(subflow->conn); - if (!msk || !READ_ONCE(msk->can_ack)) { + if (likely(msk && READ_ONCE(msk->can_ack))) { + ack_seq = msk->ack_seq; + } else if (subflow->can_ack) { + mptcp_crypto_key_sha(subflow->remote_key, NULL, &ack_seq); + ack_seq++; + } else { + can_ack = false; + } + + if (unlikely(!can_ack)) { *size = ALIGN(dss_size, 4); return ret; } @@ -375,7 +390,7 @@ static bool mptcp_established_options_dss(struct sock *sk, struct sk_buff *skb, dss_size += ack_size; - opts->ext_copy.data_ack = msk->ack_seq; + opts->ext_copy.data_ack = ack_seq; opts->ext_copy.ack64 = 1; opts->ext_copy.use_ack = 1;
Currently passive MPTCP socket can skip including the DACK option - if the peer sends data before accept() completes. The above happens because the msk 'can_ack' flag is set only after the accept() call. Such missing DACK option may cause - as per RFC spec - unwanted fallback to TCP. This change addresses the issue using the key material available in the current subflow, if any, to create a suitable dack option when msk ack seq is not yet available. v1 -> v2: - adavance the generated ack after the initial MPC packet Fixes: d22f4988ffec ("mptcp: process MP_CAPABLE data option") Signed-off-by: Paolo Abeni <pabeni@redhat.com> --- net/mptcp/options.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)