Date: Fri, 19 Sep 2025 00:31:04 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: Tilnel <deng1991816@gmail.com> Cc: Michael Tuexen <michael.tuexen@lurchi.franken.de>, freebsd-net@freebsd.org Subject: Re: Two different places between TCP socket behavior and RFC documents Message-ID: <20250919003104.5857ecd7@nuclight.lan> In-Reply-To: <CADvKEf_8pRXXNJcivm-sW=1cWmiZ0%2BdU%2BJks9jY8oiB30gAcQA@mail.gmail.com> References: <CADvKEf-vkJ-eKpwe_-x-z0pUTyx2sZRE3v7%2BZRV7cP_pq7h__w@mail.gmail.com> <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de> <CADvKEf_8pRXXNJcivm-sW=1cWmiZ0%2BdU%2BJks9jY8oiB30gAcQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 19 Sep 2025 00:35:18 +0800 Tilnel <deng1991816@gmail.com> wrote: > On Thu, Sep 18, 2025 at 6:25=E2=80=AFPM Michael Tuexen > <michael.tuexen@lurchi.franken.de> wrote: > > > 2. Sending RST to segment with old sequence SYN-RECEIVED instead of > > > acknowledgement > > > According to RFC793 page 69: If an incoming segment is not acceptable= , an > > > acknowledgement should be sent in reply. (here `should` is not > > > capitalized). This should be applied to all states including and after > > > SYN-RECEIVED. But it's not the case with FreeBSD TCP socket. I found > > > this with manually constructed TCP segment: > > > A > B: Flags [S], seq 1, win 8192, length 0 > > > B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0 > > > A > B: Flags [.], ack 1, win 8192, length 0 > > > B > A: Flags [R], seq 4054810354, win 0, length 0 =20 > > I am not sure which scenario are you considering. Could you provide SEG= .SEQ > > for the this TCP segment? =20 > > > Expected behavior is to send an empty ack: > > > A > B: Flags [S], seq 1, win 8192, length 0 > > > B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0 > > > A > B: Flags [.], ack 1, win 8192, length 0 > > > B > A: Flags [.], ack 1, win 65495, length 0 > > > Which is the case with Linux. =20 >=20 > I'd be happy to explain the scenario in more detail. > Consider the following TCP handshake sequence: > 1. Socket A sends a SYN segment: <CTL=3DSYN><SEQ=3Dx> to Socket B, which = is in > the TCP_LISTEN state. > 2. Socket B transitions to TCP_SYN_RECV and responds with > <CTL=3DSYN,ACK><SEQ=3Dy><ACK=3Dx+1>. > 3. Instead of sending the expected <CTL=3DACK><SEQ=3Dx+1><ACK=3Dy+1> to c= omplete > the three-way handshake, Socket A incorrectly sends > <CTL=3DACK><SEQ=3Dx><ACK=3Dy+1>. According to the RFC, the appropriate re= sponse to > such a malformed ACK should be an empty ACK segment: > <CTL=3DACK><SEQ=3Dy+1><ACK=3Dx+1>. After that, Socket B should either wai= t for a > valid ACK or retransmit the SYN-ACK if necessary. However, in FreeBSD=E2= =80=99s > current implementation, a RST segment is sent instead: <CTL=3DRST><SEQ=3D= y+1>, > which aborts the connection prematurely. This behavior appears to deviate > from the RFC guidance and may lead to unnecessary connection resets in ed= ge > cases. Best regards > Tilnel Did you check it with about ~2 G out of window? That is, your examples above were about ~200 M different sequence numbers, so that RST could be ignored. --=20 WBR, @nuclight
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250919003104.5857ecd7>