From nobody Thu Sep 18 10:24: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 4cSBbk6T3Qz6886g for ; Thu, 18 Sep 2025 10:25:22 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (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 4cSBbk37bsz4994 for ; Thu, 18 Sep 2025 10:25:22 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:a8f6:6ab6:7196:7223]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 9785B721E282E; Thu, 18 Sep 2025 12:24:58 +0200 (CEST) Content-Type: text/plain; charset=us-ascii 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: Thu, 18 Sep 2025 12:24:58 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de> References: 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 [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cSBbk37bsz4994 > On 18. Sep 2025, at 10:50, Tilnel wrote: >=20 > Hi, >=20 > I found two behaviors different with RFC recommendations in FreeBSD = 14.3 TCP > socket. >=20 > 1. Failure to RST on close with data pending > According to RFC2525 section 2.17, RST should be sent when close() on = socket > with pending data to read in receive buffer. > According to RFC1122: A host MAY implement a "half-duplex" TCP close = sequence, > ... cannot continue to read data ... If such a host issues a = CLOSE > call while received data is still pending in TCP, or if new = data is > received after CLOSE is called, its TCP SHOULD send a RST to = show that > data was lost. I agree that FreeBSD is inconsistent here. It reacts different if data = is received after the reading end is closed or before. I don't know why it is that way, but it is there for a long time... I plan to fix this. > It's not the case with FreeBSD TCP socket. Here is TCPDUMP output, > showing close() > on socket with pending data emit FIN instead of RST. > A > B: Flags [S], seq 2636678338, win 65535, length 0 > B > A: Flags [S.], seq 1969223298, ack 2636678339, win 65535, length = 0 > A > B: Flags [.], ack 1, win 1277, length 0 > A > B: Flags [P.], seq 1:6, ack 1, win 1277, length 5 > B > A: Flags [.], ack 6, win 1277, length 0 > B > A: Flags [F.], seq 1, ack 6, win 1277, length 0 > A > B: Flags [.], ack 2, win 1277, length 0 > All close()/shutdown(SHUT_RDWR)/shutdown(SHUT_RD) and both SO_LINGER = on or off > give the same trace. While on Linux the same execution gives this: > A > B: Flags [S], seq 2879877684, win 65495, length 0 > B > A: Flags [S.], seq 1538598692, ack 2879877685, win 65483, length = 0 > A > B: Flags [.], ack 1, win 512, length 0 > A > B: Flags [P.], seq 1:6, ack 1, win 512, length 5 > B > A: Flags [.], ack 6, win 512, length 0 > B > A: Flags [R.], seq 1, ack 6, win 512, length 0 >=20 > 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 > Does anyone know why these two violations exist? Did FreeBSD choose = not to > comply with the RFC for a specific reason, or is it simply an = implementation > error? I overall intention is to be RFC compliant... Best regards Michael >=20 > Thanks. >=20