From nobody Wed Sep 24 10:47:58 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cWtqK3HN4z68spT for ; Wed, 24 Sep 2025 10:48:13 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Certum Domain Validation CA SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cWtqH744vz3D7Y for ; Wed, 24 Sep 2025 10:48:11 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of michael.tuexen@lurchi.franken.de designates 193.175.24.27 as permitted sender) smtp.mailfrom=michael.tuexen@lurchi.franken.de Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:d1c3:612:557c:bdc0]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id D3CD8721E281C; Wed, 24 Sep 2025 12:47:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.100.1.1.5\)) Subject: Re: Two different places between TCP socket behavior and RFC documents From: Michael Tuexen In-Reply-To: Date: Wed, 24 Sep 2025 12:47:58 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A5C58E4-A939-4F3E-9FED-A24F675D5393@lurchi.franken.de> References: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de> To: Tilnel X-Mailer: Apple Mail (2.3864.100.1.1.5) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.51 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; NEURAL_HAM_MEDIUM(-0.65)[-0.654]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:193.175.24.0/24]; RCVD_IN_DNSWL_LOW(-0.10)[193.175.24.27:from]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[franken.de]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cWtqH744vz3D7Y > On 18. Sep 2025, at 20:22, Michael Tuexen = wrote: >=20 >> On 18. Sep 2025, at 18:35, Tilnel wrote: >>=20 >> On Thu, Sep 18, 2025 at 6:25=E2=80=AFPM Michael Tuexen >> 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: to Socket B, = which is in the >> TCP_LISTEN state. >> 2. Socket B transitions to TCP_SYN_RECV and responds with >> . >> 3. Instead of sending the expected = to complete the >> three-way handshake, Socket A incorrectly sends = . >> According to the RFC, the appropriate response to such a malformed = ACK should be >> an empty ACK segment: . 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: >> , 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