Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Sep 2025 12:47:58 +0200
From:      Michael Tuexen <michael.tuexen@lurchi.franken.de>
To:        Tilnel <deng1991816@gmail.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Two different places between TCP socket behavior and RFC documents
Message-ID:  <8A5C58E4-A939-4F3E-9FED-A24F675D5393@lurchi.franken.de>
In-Reply-To: <AF0E49E6-1CC1-41EF-94C0-23E1D08327A8@lurchi.franken.de>
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> <AF0E49E6-1CC1-41EF-94C0-23E1D08327A8@lurchi.franken.de>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 18. Sep 2025, at 20:22, Michael Tuexen =
<Michael.Tuexen@lurchi.franken.de> wrote:
>=20
>> On 18. Sep 2025, at 18:35, Tilnel <deng1991816@gmail.com> wrote:
>>=20
>> 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
>>> I am not sure which scenario are you considering. Could you provide =
SEG.SEQ
>>> for the this TCP segment?
>>>> 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
>> 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 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 wait 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 deviate from the RFC guidance and may lead =
to
>> unnecessary connection resets in edge cases.
> Hi Tilnel,
>=20
> OK, now I understand your scenario. Let me test it and come back to =
you.
> Give me a day or two.
I can confirm the behavior you observed. It is a bug, I will fix it.

Thanks for reporting,

Best regards
Michael
>=20
> Best regards
> Michael
>> Best regards
>> Tilnel
>=20
>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8A5C58E4-A939-4F3E-9FED-A24F675D5393>