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

[gang.yan@linux.dev]

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.
'''


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.
'''

Thanks
Gang


> 
> > 
> > I would prefer avoiding additional conditionals, if not well reasoned.
> > 
> Agreed, the commit messages in this series are not explaining (enough)
> the reason and the context.
> 
> BTW, Chenguang, please use 'mptcp-net' for fixes (and mptcp-next for
> features). Also fixes should have a Fixes tag.
> 
> Cheers,
> Matt
> -- 
> Sponsored by the NGI0 Core fund.
>