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

[Matthieu Baerts <matttbe@kernel.org>]

Hi Gang,

On 13/08/2026 11:32, gang.yan@linux.dev wrote:
> August 12, 2026 at 11:32 PM, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:
> 
> 
>>
>> Note: Chenguang is looking at a bug where, when an MP_FAIL is received
>> before being in fully_established, the kernel accept going to fully
>> established, and creating new subflows, then reject them once done.
>>
>> Same when receiving a 4th packet without MPTCP options.
>>
>> I think the MP_FAIL should do a fallback if possible, but it is probably
>> also required to check the fallback status or something similar when
>> receiving an MPJ.
> 
> Hi, Matt
> 
> Sorry, I'm not very familiar with the details of this patch.
> 
> No offense intended, I just have a question I'd like to ask based on my
> understanding and the RFC documentation: Should MP_FAIL trigger a fallback?
> 
> For the multiple‑subflow case, if one subflow encounters an MP_FAIL, it should
> be closed with a RST, and the data will be retransmitted over the other healthy
> subflows. This should not cause the entire MPTCP connection to fallback to regular
> TCP, right?
> RFC8684's contents:
> '''
> The receiver of this option MUST discard all data following the data sequence number
> specified. Failed data MUST NOT be DATA_ACKed and so will be retransmitted on other subflows.
> '''

Correct, in this case it shouldn't fallback.

> For the single‑subflow case, according to the RFC, MP_FAIL should subsequently
> lead to a fallback under the infinite mapping (INFINITEMAP) situation, shouldn't it?
> RFC 8684's contents:
> '''
> A special case is when there is a single subflow and it fails with a checksum error.
> If it is known that all unacknowledged data in flight is contiguous (which will usually
> be the case with a single subflow), an infinite mapping can be applied to the subflow
> without the need to close it first, essentially turning off all further MPTCP signaling.
> '''

Correct.

Please note that when I said "the MP_FAIL should [cause] a fallback if
possible", I'm referring to what is done in mptcp_try_fallback() → a
fallback is only possible in the single subflow situation, without
reordering at the MPTCP level.

In addition, in the case we are trying to fix here, the MP_FAIL is
received before switching to fully established: the RFC doesn't explain
this particular case, but it sounds like there is no need to send the
infinite mapping, and a fallback can be done directly *I think*. The
thing is this situation shouldn't happen: we are not supposed to receive
an MP_FAIL at that stage, no data has been exchanged at the MPTCP level,
so let's do the minimal -- i.e. just a fallback -- to avoid issues and
reduce the complexity, no?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.