From nobody Thu Sep 18 21:26:47 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 4cSTHF4C3cz683qG for ; Thu, 18 Sep 2025 21:27:05 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cSTHF1hhXz3bqg for ; Thu, 18 Sep 2025 21:27:05 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-55f7b6e4145so1749231e87.1 for ; Thu, 18 Sep 2025 14:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758230822; x=1758835622; darn=freebsd.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=0+7pgnX+h4Z0R+E2fHnOY2CRnqMma1To6kZpkJh1hyQ=; b=k8L3ZCd+XDI5/w3oDYz0GSFxOjCEqJTNQtGp9KeIPH9OJULfcgIGFz4Jl9swSsupad tMKsJN1C7uGQzqkbtLwyQVwoV6JE5B7Cj9t0FYYev1YIuyAOyCZYEg6KfmPvQ0rq4UXq ptzAO/MU+ZjfX7upEP8NtEUsHqSfTnui3qi1VNok2fHxXh83aRwLmsxc5NQgNMEFESW2 JPDoSXoQaxp+yN8rdHE38fgNXnux6Xjs3vwdKKh5Yz27AWLjcibnqNfHKhMqUKPMFk+a lMnEV2+v1GrhFTPy2EYcMLsW8OsVzJLaihW2tB+NODHVMZp7wuMX3GVxTTNf9p6CdzEH 8iMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758230822; x=1758835622; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0+7pgnX+h4Z0R+E2fHnOY2CRnqMma1To6kZpkJh1hyQ=; b=F9Ho08sXWgytdaExJf5k76Vv7sBU3NNssuto4/liNBAwUUxqF0zaF3BJYOGzCO7fvJ nk4V0To7yYu+GuECwSEpum7YXMo6RUl89/sYfON+OZcnLZmUkhyJzpO9bTQlk3wDvFPr pUsbx7vIepkzkPvYIOY1SjA3ISxS4fnjQeslZRKkbp+OK3Dfqldjgo1gRoYhFaurRLXx Z5kpb5JENYiDH8jnTYc/5VlMHxkXnn/Ha5o8CSqLw24gwsHOpQKbt8LW/tz6QkhNDEHf efs1Hqg0Zz816SA9z9mxvSDvMdgdasHjjhiGoirEI6GZSUcjmB9NpbMDvhPC5S+Q3TYv nVMQ== X-Gm-Message-State: AOJu0YywE++C72ghk+ahgrm7Oifw2FtVJqSuLpch7WTUjltJdgCpRo8D Aibvar5T+XQPyLg6TMWbCDnJA7tZFga2AQsjGIsJ63K53HsiOODqWFh3 X-Gm-Gg: ASbGncslCInbp7Kg/Brb+Am8Pf+/4wmO+7epedSyxVep2ni79aD47naTLRb6MynnQxH WTeg8OR/y8s80Oayb1vmgP84qNEFGlP9hVYIYmHwMukCoinogJca0Fvn9kQ6aH7yjAiqdg1Z+K0 VRo+vysPupfTJd0Ej78I0LarlKzVLtC4y4nW1HHao+QmqWv26z2PpmQWnh543Zml9bOZ9NHxukQ JLqh/jV+StJ0TrG0mrUe/Iign8B5ruAxYU6ZsSRX2ZTxo22YkrtEb28SuRxzRnnuJoT6gvF7DuP 1qTsuk4TX/6MjG4UHOUfH20VjAbmi6ok4lZtXVOadrFWku51Io08GTFkw6NKW5zvT6Zaz7ur91F eSCQaNIep68LXs9DMFr/s+Pzkx5brGP5G7LUFwCRP4GcJ+xCf+qzCvbev+wFWZo2f96HCNiGZCj MNQfe9+mn7 X-Google-Smtp-Source: AGHT+IEaZpzg1CDSnNbvE+kUOYySp5kTfEX2n91Tn4MmrrGCYhNbo7jKSFG9b6VCy6RSf2KoDnPdsQ== X-Received: by 2002:a05:6512:3a84:b0:560:932a:c3c7 with SMTP id 2adb3069b0e04-579e1b6a80dmr304292e87.13.1758230821507; Thu, 18 Sep 2025 14:27:01 -0700 (PDT) Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-578a5f4479fsm957191e87.12.2025.09.18.14.27.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Sep 2025 14:27:01 -0700 (PDT) Date: Fri, 19 Sep 2025 00:26:47 +0300 From: Vadim Goncharov To: Tilnel Cc: freebsd-net@freebsd.org Subject: Re: Two different places between TCP socket behavior and RFC documents Message-ID: <20250919002647.367809e7@nuclight.lan> In-Reply-To: References: X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.4) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 4cSTHF1hhXz3bqg On Thu, 18 Sep 2025 16:50:46 +0800 Tilnel wrote: > Hi, > > I found two behaviors different with RFC recommendations in FreeBSD 14.3 TCP > socket. > > 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. > 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 Is the situation from RFC 2525 section 2/17 still applicable to our TCP stack? I.e. does the connection still hold indefinitely for A after B's close() ? > 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 > 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. > > 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? RFC 9293 still does not capitalize "should" here, therefore it is not a normative requirement. In fact, I vaguely recall that some anti-DDoS systems check the liveness of host (not being spoofed SYN) by sending out-of-window packet and expecting RST while main connection is unaffected. -- WBR, @nuclight