[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240704174208.2182-1-kuniyu@amazon.com>
Date: Thu, 4 Jul 2024 10:42:08 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <edumazet@...gle.com>
CC: <0x7f454c46@...il.com>, <brakmo@...com>, <davem@...emloft.net>,
<dsahern@...nel.org>, <kuba@...nel.org>, <kuni1840@...il.com>,
<kuniyu@...zon.com>, <netdev@...r.kernel.org>, <pabeni@...hat.com>
Subject: Re: [PATCH v1 net] tcp: Don't drop SYN+ACK for simultaneous connect().
From: Eric Dumazet <edumazet@...gle.com>
Date: Thu, 4 Jul 2024 14:23:11 +0200
> On Thu, Jul 4, 2024 at 1:16 PM Paolo Abeni <pabeni@...hat.com> wrote:
> >
> > On Wed, 2024-07-03 at 20:57 -0700, Kuniyuki Iwashima wrote:
> > > RFC 9293 states that in the case of simultaneous connect(), the connection
> > > gets established when SYN+ACK is received. [0]
> > >
> > > TCP Peer A TCP Peer B
> > >
> > > 1. CLOSED CLOSED
> > > 2. SYN-SENT --> <SEQ=100><CTL=SYN> ...
> > > 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT
> > > 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED
> > > 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
> > > 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED
> > > 7. ... <SEQ=100><ACK=301><CTL=SYN,ACK> --> ESTABLISHED
> > >
> > > However, since commit 0c24604b68fc ("tcp: implement RFC 5961 4.2"), such a
> > > SYN+ACK is dropped in tcp_validate_incoming() and responded with Challenge
> > > ACK.
> > >
> > > For example, the write() syscall in the following packetdrill script fails
> > > with -EAGAIN, and wrong SNMP stats get incremented.
> > >
> > > 0 socket(..., SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_TCP) = 3
> > > +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
> > >
> > > +0 > S 0:0(0) <mss 1460,sackOK,TS val 1000 ecr 0,nop,wscale 8>
> > > +0 < S 0:0(0) win 1000 <mss 1000>
> > > +0 > S. 0:0(0) ack 1 <mss 1460,sackOK,TS val 3308134035 ecr 0,nop,wscale 8>
> > > +0 < S. 0:0(0) ack 1 win 1000
> > >
> > > +0 write(3, ..., 100) = 100
> > > +0 > P. 1:101(100) ack 1
> > >
> > > --
> > >
> > > # packetdrill cross-synack.pkt
> > > cross-synack.pkt:13: runtime error in write call: Expected result 100 but got -1 with errno 11 (Resource temporarily unavailable)
> > > # nstat
> > > ...
> > > TcpExtTCPChallengeACK 1 0.0
> > > TcpExtTCPSYNChallenge 1 0.0
> > >
> > > That said, this is no big deal because the Challenge ACK finally let the
> > > connection state transition to TCP_ESTABLISHED in both directions. If the
> > > peer is not using Linux, there might be a small latency before ACK though.
> > >
> > > The problem is that bpf_skops_established() is triggered by the Challenge
> > > ACK instead of SYN+ACK. This causes the bpf prog to miss the chance to
> > > check if the peer supports a TCP option that is expected to be exchanged
> > > in SYN and SYN+ACK.
> > >
> > > Let's accept a bare SYN+ACK for non-TFO TCP_SYN_RECV sockets to avoid such
> > > a situation.
> >
> > Apparently this behavior change is causing TCP AO self-tests failures:
> >
> > https://netdev.bots.linux.dev/contest.html?pw-n=0&branch=net-next-2024-07-04--09-00
> > e.g.
> > https://netdev-3.bots.linux.dev/vmksft-tcp-ao-dbg/results/668061/22-self-connect-ipv4/stdout
> >
>
> These tests seem to have broken assumptions on a kernel behavior which
> are orthogonal to TCP AO.
Seems so...
>
> > Could you please have a look?
Sure :)
Thanks!
Powered by blists - more mailing lists