Re: [PATCH mptcp-net v2] mptcp: options: handle MPC data + csum reqd + no csum

Hi Mat,

On 14/08/2026 03:48, Mat Martineau wrote:
> On Wed, 5 Aug 2026, Matthieu Baerts (NGI0) wrote:
> 
>> Before this modification, a remote peer could send an MP_CAPABLE with
>> data, with the checksum flag set, but without adding the actual 2 bytes
>> of checksum. As a result, uninitialised bytes could be used for the
>> 'csum' field.
>>
>> That was not a critical issue, because this 'csum' field is only used to
>> compare with the expected one, if previously negotiated in the 3WHS.
>> Worst case, the checksum is likely wrong, a fallback is done without a
>> reject if the negotiation was done earlier. That's OK.
>>
>> Yet, better to take the expected path with this case: only look at the
>> checksum flag for MP_CAPABLEs not carrying a data-len.
>>
>> Such packet can be seen as a 3rd or 4th ACK. The RFC8684 mentions [1]
>> that the 3rd packet should have the checksum flag set. When an MPC + ACK
>> contains data, the checksum flag is redundant with the checksum field.
>> It is not clear what should be done for the 4th ACK, nor if the flag has
>> to be set if the checksum field is set.
>>
>> Therefore, it seems fine to only look at the presence of the checksum
>> field, not to break the interaction with stacks that were not setting
>> both.

(...)

> Yes, this looks like a good tradeoff between not breaking interaction
> with other stacks while avoiding an invalid checksum.

Thank you for the review!

New patches for t/upstream-net and t/upstream:
- aa590201e5a8: mptcp: options: handle MPC data + csum reqd + no csum
- Results: 79d7297194ac..52bf6f574345 (export-net)
- Results: 199ed983c1f7..55a0274d38e1 (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/f77d0f8990780a8dc74e236f213b46a0d9b72391/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/84c282b44c231fa96cdec0e7f0fd99be9af9d82f/checks

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