Re: [PATCH v4] mptcp: push queued data on passive TFO subflows becoming established

[Matthieu Baerts <matttbe@kernel.org>]

Hi T S,

+cc Petar.

On 12/10/2026 12:00, T S RAMESHKUMAR wrote:
> Hi Matt, Petar,
> 
> Thank you both!
> 
> I have prepared [PATCH mptcp-net v2] based on the export branch.
> In v2:
> - Reverted bitfield modifications: check_fully_established() is only
> called once upon receiving the MPC 3rd-ACK, so is_mptfo is read-only at
> that stage and safe from concurrency races.
> - Added "Suggested-by: Petar Sakic <petar.sakic@ink.fish>" and
> "Reported-by: Petar Sakic <petar.sakic@ink.fish>".
> - Kept the Fixes tag pointing to fb7084501a61 ("mptcp: add support for
> TCP_FASTOPEN sockopt") to ensure backports cover 6.8 and all stable trees.

Thank you. I will try to review this after the automated tests.

> Regarding Packetdrill:
> I have prepared the packetdrill test case (server-TCP_FASTOPEN-early-
> write.pkt) which simulates the server writing data in SYN_RECV before
> the 3rd ACK arrives and verifies that the 100 bytes are pushed
> immediately with DSS mapping once the 3rd ACK is received. All 51
> fastopen tests pass.
> 
> I can submit the packetdrill test via a PR on https://github.com/
> multipath-tcp/packetdrill <https://github.com/multipath-tcp/
> packetdrill>, or send it directly to the list if preferred. Here is the
> test script for reference:

Please open a new PR.

> --- server-TCP_FASTOPEN-early-write.pkt ---
> // SPDX-License-Identifier: GPL-2.0
> // Test MPTCP passive Fast Open early write before 3rd ACK arrives
> --tolerance_usecs=100000
> `../common/defaults.sh`
> 
>  0.0    socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3
> +0.0    setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> +0.0    setsockopt(3, SOL_TCP, TCP_FASTOPEN, [2], 4) = 0
> 
> +0.0    bind(3, ..., ...) = 0
> +0.0    listen(3, 1) = 0
> 
> // Client connects with TFO Cookie and 500 bytes of SYN data
> +0.1      <  S   0:500(500)                win 65535  <mss 1460, sackOK,
> TS val 100 ecr 0,   nop, wscale 8, FO TFO_COOKIE, nop, nop, mpcapable v1
> flags[flag_h] nokey>
> +0.0      >  S.  0:0(0)          ack 501              <mss 1460, sackOK,
> TS val 100 ecr 100, nop, wscale 8,                          mpcapable v1
> flags[flag_h] key[skey]>
> 
> // Server accepts while still in SYN_RECV and reads the SYN data
> +0.0    accept(3, ..., ...) = 4
> +0.0    read(4, ..., 500) = 500
> 
> // Server writes early reply data before receiving client's 3rd ACK
> +0.0    write(4, ..., 100) = 100
> 
> // Client's 3rd ACK arrives with no data, establishing the MPTCP connection
> +0.2      <   .  501:501(0)      ack 1     win 450    <                
>                                                              mpcapable
> v1 flags[flag_h] key[ckey, skey]>

Here, you are dropping TCP Timestamps (TS) negotiated before. Probably
better to keep it (or you don't inject it in he first SYN, clearer).

> // Server must immediately push the queued 100 bytes with DSS mapping
> +0.0      >  P.  1:101(100)      ack 501              <nop, nop, TS val
> 100 ecr 100, dss dack8=0 dsn8=1 ssn=1 dll=100 nocs>

"dack8=0"? That's strange...

Also, TCP options are not padded correctly to ensure TCP header is a
multiple of 4 bytes: 2 excess bytes → you are missing two "nop" at the end.

How did you test it?

 $ cd <Packetdrill DIR>/gtests/net
 $ run_all.py -lv mptcp/fastopen/server-TCP_FASTOPEN-early-write.pkt

Don't forget to add the "Assisted-by: LLM" tag if used, and mention what
you did, how you tested things. You can use this docker image to ease
the testing part:

  https://github.com/multipath-tcp/mptcp-upstream-virtme-docker

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