Skip site navigation (1)Skip section navigation (2)
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>