Re: [PATCH export v3 2/4] mptcp: reject joins after fallback in mptcp_is_fully_established

On 8/14/26 11:09 AM, Matthieu Baerts wrote:
> 14 Aug 2026 10:43:41 Paolo Abeni <[email protected]>:
>> It's not clear to me what actually goes wrong and how. Do you have handy
>> a event sequence or stack trace demonstrating the critical scenario?
> 
> Indeed, better with packetdrill scripts:
> 
> https://github.com/chrisocean716-star/packetdrill/blob/bf9be7a7bee3687500444b284a9db2a0009a5252/gtests/net/mptcp/dss/dss_drop_after_data_fallback_server.pkt
> 
> => A fallback is done, a subflow can be initiated, then rejected.
> 
> 
> https://github.com/chrisocean716-star/packetdrill/blob/fed57fab92c407eb433acdb8c8ce72bd8e3e2f37/gtests/net/mptcp/mp_join/mp_join_server_after_fallback.pkt
> 
> => The MP_FAIL is partially ignored if received before being in fully
> established state.

Thanks!

I'm pretty sure there is a miss-intepretation of the 2nd case. The
problem is not with `msk->fully_established`. AFAICS
msk->fully_established is true when the MP_FAIL is receive.

The passive msk socket sets it at MPC ACK reception.

The problem is that, at MP_FAIL reception, the infinite mapping is not
sent immediately, but it's scheduled with the next xmit, and until such
point the msk does not perform the fallback.

I think a proper solution would be bounding MP_FAIL (reply) and infinite
mapping in the same ack.

As noted by Gang, it may require a new helper (build on top of the
tcp_send_ack).

/P