Re: [PATCH net-next v2 06/15] mptcp: pm: drop TCP TS with ADD_ADDRv6 + port

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 10 Jun 2026 17:13:54 +0200 Matthieu Baerts wrote:
> Hello,
> 
> On 05/06/2026 19:21, Matthieu Baerts (NGI0) wrote:
> > With TCP-timestamps (padded) taking 12 bytes and ADD_ADDR IPv6 + port
> > taking 30 bytes, the 40-byte limit for the TCP options is reached. In
> > this case, it is then not possible to send the signal.
> > 
> > To be able to send this ADD_ADDR, the TCP timestamps option can now be
> > dropped. This is done, when needed by setting the *drop_ts parameter
> > from mptcp_established_options. This feature is controlled by a new
> > net.mptcp.add_addr_v6_port_drop_ts sysctl knob, enabled by default.
> > 
> > It is important to keep in mind that dropping the TCP timestamps option
> > for one packet of the connection could eventually disrupt some
> > middleboxes: even if it should be unlikely, they could drop the packet
> > or even block the connection. That's why this new feature can be
> > controlled by a sysctl knob.  
> FYI, Sashiko's new comments about this patch [1] are suggesting issues
> when MPTCP is used in parallel with TCP MD5. But MPTCP cannot be used
> with MD5 because there is not enough space in the TCP options. That's
> why there is an explicit rejection when initiating the connection.
> 
> So I think we can ignore these comments saying that more options could
> be dropped, and the size can be negative.
> 
> https://sashiko.dev/#/patchset/20260605-net-next-mptcp-add-addr6-port-ts-v2-0-758e7ca73f4d%40kernel.org?part=6

I'll probably pull today, but to explain the delay - Sashiko made me
read the code and while I think the reports are false positives - 
the option handling does not read like awesome code. So the series fell
down the priority list.