Date: Tue, 23 Sep 2025 10:25:07 +0800 From: Tilnel <deng1991816@gmail.com> To: Vadim Goncharov <vadimnuclight@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: <CADvKEf9q-qzpCN0mP5JuNZA1qZLbMe0kf66JMNgPNiTD73sQxA@mail.gmail.com> In-Reply-To: <20250919003104.5857ecd7@nuclight.lan> 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> <20250919003104.5857ecd7@nuclight.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 19, 2025 at 5:31=E2=80=AFAM Vadim Goncharov <vadimnuclight@gmai= l.com> wrote: > > On Fri, 19 Sep 2025 00:35:18 +0800 > Tilnel <deng1991816@gmail.com> wrote: > > > 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, whic= h 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= complete > > the three-way handshake, Socket A incorrectly sends > > <CTL=3DACK><SEQ=3Dx><ACK=3Dy+1>. According to the RFC, the appropriate = response 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 w= ait 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= =3Dy+1>, > > which aborts the connection prematurely. This behavior appears to devia= te > > from the RFC guidance and may lead to unnecessary connection resets in = edge > > cases. Best regards > > Tilnel > > Did you check it with about ~2 G out of window? That is, your examples ab= ove > were about ~200 M different sequence numbers, so that RST could be ignore= d. > Hi. I just checked it with ACK segment carrying different SEQ, including ~2G ou= t of the window. 1. expect seq=3D2, actual seq=3D0x80000001 2. expect seq=3D2, actual seq=3D0x80000002 3. expect seq=3D2, actual seq=3D0x80000003 4. expect seq=3D2, actual seq=3D0x90000000 5. expect seq=3D2000001 (0x1e8481), actual seq=3D1 6. expect seq=3D1, actual seq=3D2000001 (0x1e8481) All of them, under FreeBSD, give a RST reply. Here is the tcpdump of the fi= rst case. A > B: Flags [S], seq 1, win 8192, length 0 0x0000: 4500 0028 0000 4000 4006 0000 7f00 0001 0x0010: 7f00 0001 22b9 22b8 0000 0001 0000 0000 0x0020: 5002 2000 4c6e 0000 B > A: Flags [S.], seq 1643153760, ack 2, win 65535, options [mss 16344], length 0 0x0000: 4500 002c 0000 4000 4006 0000 7f00 0001 0x0010: 7f00 0001 22b8 22b9 61f0 8960 0000 0002 0x0020: 6012 ffff fe20 0000 0204 3fd8 A > B: Flags [.], seq 2147483648, ack 1, win 8192, length 0 0x0000: 4500 0028 0000 4000 4006 0000 7f00 0001 0x0010: 7f00 0001 22b9 22b8 8000 0001 61f0 8961 0x0020: 5010 2000 e10d 0000 B > A: Flags [R], seq 1643153761, win 0, length 0 0x0000: 4500 0028 0000 4000 4006 0000 7f00 0001 0x0010: 7f00 0001 22b8 22b9 61f0 8961 0000 0000 0x0020: 5004 0000 fe1c 0000 Best regards Tilnel > -- > WBR, @nuclight
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADvKEf9q-qzpCN0mP5JuNZA1qZLbMe0kf66JMNgPNiTD73sQxA>