From nobody Mon Sep 22 09:34:40 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 4cVdHg6vJ3z68s52 for ; Mon, 22 Sep 2025 09:34:55 +0000 (UTC) (envelope-from deng1991816@gmail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 4cVdHg1lHKz429L for ; Mon, 22 Sep 2025 09:34:55 +0000 (UTC) (envelope-from deng1991816@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=dSLoeH3g; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of deng1991816@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=deng1991816@gmail.com Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-45f2b062b86so26869395e9.1 for ; Mon, 22 Sep 2025 02:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758533693; x=1759138493; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=21GU6eLRD4nJJ6aH+glQoKquwa4STSjOi+lC6ru7ELw=; b=dSLoeH3gFFZN1zfFsI/hhTv9DciS2lPbjdyIg5Rj4P6A4I0QN9Q2iwWnNrtYOK1LKc RPBqqzqOavhQOqcl1E7rDsQa/4+n+4FNQIItzcL3PNN8R/16+wRO4VzeVRwmIccRI/Od XZ2Hr5OCIENs6TBXlnGvCrsSuVXqbCA9dkXWNq8/8ce4lz5zlsBcP+cTRs3nTchWFDc1 t5OkBPQdAQBIOeSHqOBZa4xrlek8mCtFuhES7eRhljHrLlzFG8X2lHzqt2EMed7zI9Qx V2UwDrSmGsodsVu1SitSgtlcoQB4vZUAR0w+fh5TUAExuWMCH2NycT7a6Rkkd6Apeu1g ukjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758533693; x=1759138493; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=21GU6eLRD4nJJ6aH+glQoKquwa4STSjOi+lC6ru7ELw=; b=LB31mvdVSyrul5Ee/cmDG/SMPaT8cc6xOhdJOOKdMJIM+jkvmXMDYuwWfmMSMABSg6 1QWFkRWLU/b+N1/coHawBtwJnS8kKv9XavH/KPiMUvXhquBoVEpYilb5xFU+fp/z9YOQ SuJKioR0ajKUaM8+3euG2lfXcUe1qv3TFoalFNfrpBnn45rIBVAJ/LdepHC1n7WPWfLO MdiDvu2fWKQ9o5JmqLduBdN0SKhuLuTBb/wK5CuB+1x5gE+4dfbCMMxIcd/pq1ch2m4c 3wUS50awGcRYuldjIKZqq57kK6l50GSaEmhT0vpQ09x6ji5ibiVbVtov+gbH9TkqyD+7 FGZA== X-Gm-Message-State: AOJu0Yx9hGGo001C4IIoEhweiRYQ92qgXou9DHvaIQ/ozwexDlFURLMk bgY90w7PHpouCZildIR3u3rvzA7vFiEmGhSp/dLXWljmxWBShtg6RiFlDr0YCQkzYKnnqE/Kc9n 9RThpw1d94/n/fOGZ/Ixs1iyF9OUKCm7GyxkwHPYJ5A== X-Gm-Gg: ASbGncul1Pw36n12emRqJ+Yzs4twx6YpP+JadDx5CpySohrq1c+7raaeoDZE1mynf4i suim5S8j47R/601HSUo9m2/yDZ5+SMkERP6Ix7RQI9m5BnL+p8HJv/3yxLuUjqvhY+3cV1lu8nl voMajPApHZIHTMHxc7heF12MhtCpNsHqRvh0WMZiKZ2a/bdBorJ9PO/gFMt6X51QzMPl3hM/Y4U w8WobAKf7PzCUbAgA== X-Google-Smtp-Source: AGHT+IGJpKwZw2vGyDfLMDeIZR/iLrO63KoYNcW6GTzZZCXc56TqEGLxwrvkrB6TT3wUx8s/MJU42XF5gvszRCeCpgI= X-Received: by 2002:a05:600c:3593:b0:45d:dc85:c009 with SMTP id 5b1f17b1804b1-467eed8f53amr147988225e9.10.1758533692584; Mon, 22 Sep 2025 02:34:52 -0700 (PDT) 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 References: <20250919002647.367809e7@nuclight.lan> In-Reply-To: <20250919002647.367809e7@nuclight.lan> From: Tilnel Date: Mon, 22 Sep 2025 17:34:40 +0800 X-Gm-Features: AS18NWC5HzkccDeSqkqZid9p8li9z-7XjOf-sju7U0Inmk589uPLIWMnYD7b9_8 Message-ID: Subject: Re: Two different places between TCP socket behavior and RFC documents To: Vadim Goncharov Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c:from] X-Rspamd-Queue-Id: 4cVdHg1lHKz429L On Fri, Sep 19, 2025 at 5:27=E2=80=AFAM Vadim Goncharov wrote: > > 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 s= ocket > > 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 d= ata 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 s= tack? > I.e. does the connection still hold indefinitely for A after B's close() = ? No. The connection will not be maintained indefinitely, because FreeBSD see= ms to have adopted another approach, similar to the trace on RFC 2525 Page 52: although it sends a FIN-ACK, it opens the receive window again. This allows= the other side to continue sending data and eventually receive an RST, or send = a FIN-ACK to close the connection normally. However, this approach is still considered "Better, but still not fully cor= rect" in RFC 2525. I guess this may be because it causes unnecessary traffic and resource waste, and the act of opening the window to invite the other party= to send data is fundamentally contrary to the purpose of this "half-duplex" cl= ose implementation. > > > 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 > > 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 implement= ation > > 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 syst= ems > check the liveness of host (not being spoofed SYN) by sending out-of-wind= ow > packet and expecting RST while main connection is unaffected. > In the scenario above, A has no reason to send an out-of-window ACK to test= if B's SYN is spoofed, as the initial SYN is sent by A itself, not B. Furthermore, if this were a legitimate detection mechanism, a large number = of systems compliant with RFC recommendations would be falsely flagged as atta= ckers just for replying with an ACK. I haven't found a system with such a defense strategy. Thanks for taking the time to answer my questions. Tilnel > -- > WBR, @nuclight