Re: Two different places between TCP socket behavior and RFC documents

Tilnel <[email protected]>
Newsgroups gmane.os.freebsd.devel.net
Message-ID <CADvKEf9q-qzpCN0mP5JuNZA1qZLbMe0kf66JMNgPNiTD73sQxA@mail.gmail.com>
On Fri, Sep 19, 2025 at 5:31 AM Vadim Goncharov <[email protected]> wrote:
>
> On Fri, 19 Sep 2025 00:35:18 +0800
> Tilnel <[email protected]> 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=SYN><SEQ=x> to Socket B, which is in
> > the TCP_LISTEN state.
> > 2. Socket B transitions to TCP_SYN_RECV and responds with
> >    <CTL=SYN,ACK><SEQ=y><ACK=x+1>.
> > 3. Instead of sending the expected <CTL=ACK><SEQ=x+1><ACK=y+1> to complete
> > the three-way handshake, Socket A incorrectly sends
> > <CTL=ACK><SEQ=x><ACK=y+1>. According to the RFC, the appropriate response to
> > such a malformed ACK should be an empty ACK segment:
> > <CTL=ACK><SEQ=y+1><ACK=x+1>. After that, Socket B should either wait for a
> > valid ACK or retransmit the SYN-ACK if necessary. However, in FreeBSD’s
> > current implementation, a RST segment is sent instead: <CTL=RST><SEQ=y+1>,
> > which aborts the connection prematurely. This behavior appears to deviate
> > 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 above
> were about ~200 M different sequence numbers, so that RST could be ignored.
>

Hi.
I just checked it with ACK segment carrying different SEQ, including ~2G out of
the window.
1. expect seq=2, actual seq=0x80000001
2. expect seq=2, actual seq=0x80000002
3. expect seq=2, actual seq=0x80000003
4. expect seq=2, actual seq=0x90000000
5. expect seq=2000001 (0x1e8481), actual seq=1
6. expect seq=1, actual seq=2000001 (0x1e8481)
All of them, under FreeBSD, give a RST reply. Here is the tcpdump of the first
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.