Date: Fri, 19 Sep 2025 00:35:18 +0800 From: Tilnel <deng1991816@gmail.com> To: Michael Tuexen <michael.tuexen@lurchi.franken.de> Cc: freebsd-net@freebsd.org Subject: Re: Two different places between TCP socket behavior and RFC documents Message-ID: <CADvKEf_8pRXXNJcivm-sW=1cWmiZ0%2BdU%2BJks9jY8oiB30gAcQA@mail.gmail.com> In-Reply-To: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de> References: <CADvKEf-vkJ-eKpwe_-x-z0pUTyx2sZRE3v7%2BZRV7cP_pq7h__w@mail.gmail.com> <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 capitali= zed). > > 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 constr= ucted 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.S= EQ > 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. 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 com= plete 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 shou= ld 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. Best regards Tilnel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADvKEf_8pRXXNJcivm-sW=1cWmiZ0%2BdU%2BJks9jY8oiB30gAcQA>