From nobody Thu Sep 18 08:50:46 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 4cS8Vw6CyCz681lJ for ; Thu, 18 Sep 2025 08:51:04 +0000 (UTC) (envelope-from deng1991816@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 4cS8Vw1lc2z3h2c for ; Thu, 18 Sep 2025 08:51:04 +0000 (UTC) (envelope-from deng1991816@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=R8L48njx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of deng1991816@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=deng1991816@gmail.com Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3ee12807d97so317810f8f.0 for ; Thu, 18 Sep 2025 01:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758185461; x=1758790261; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Yh7pq7nTH6OgOW/8MVrldM8jqDK8TU/klqBJ0JaP21I=; b=R8L48njxN4cWmAWowDT+fwC/4hzf9m2QwZcc+rSYVRYCVyctWPJ0X+d+sma2SPsBCf ilaFSdWYv0ktReIdeuhmNh0I844dLsrmmqSQlztKtXsjq8V3SCsYzYhA9uzmrNx/LbqP AelkXaghh3rLtuE9BpVFu0bMU35KmUb4pSli79uG28h6AkdzYJH9BgGZpZsYXUpDqHv/ JdWdTgFpmmRVQcsEx4XJ5h/YUGw2SDr5qlzcJmrOw5DaRC5Mk73eP37ZzEpWMQflfFfp DlAQr+CZPPTq2wWdlplHNzJJFX93wn6cjDWpJrYd19JVh1qDxmdNipc2bt6RTOouNzWY Jkug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758185461; x=1758790261; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Yh7pq7nTH6OgOW/8MVrldM8jqDK8TU/klqBJ0JaP21I=; b=kI3LgGZdpJt1vBRgqZZWuwrx3UXUm2vdqQ1avHPDTfHRAdQECyMDosBirkVtDr0cMq 5r62L6ujQPClftfEr87WNbUnOgOWX+ykoGzoAF5Tn4OjCtsfYMjVzaB2VdYucXs+R8U6 8ntgYznBbnYqi+QALOsr5u8+1awBzcwYv3/8280TfbMMEIFVw68+pN32jXHV0XMiANIi Rteu9WzR1dWOqE14zlr1N13RUCawyEFDMTzaWzFPKDrBUkNr+pLUiNPE8gHuqDy9pd9v Iysu6OGF44JDU18+xQB3UBK38kXdH0ic+JQfKpqmhkFLg8Sep3WTwFLMOKYhf/5UpR7F MdrA== X-Gm-Message-State: AOJu0YxNqWeqKeVHzrPwOfZHbfWrv2aTdHRO2bxmTxfY4LZHsCTHRquF QA1vbIpybMg1fpWeRsmaC3hnbfdVmQ+u2yQ14vNScEooRq7VVLBmkQu8IxgcMRnDUrKdvXYgaee TrdpNSNZ3VLSeBlAkyonQ9/2eep7nF0iXspTobMYM0w== X-Gm-Gg: ASbGnctLXGfgIxO+F1Vf9JvI0sNBzfR4wDIiuhwKMTZA0E2eIU6AzVJsb+SYBwDSi5Q oJoeDMgb9mbYI7kxEuhIizja73/CYJEgadrjZO7TmqmuUXGUrBgQJ/qevNxbSvn0TBSORMFEdXK hMzTP2LtWIsj9aoqaJrNUpgP4+6Y0z5pLZDV5cAA1LTLxmf/PdsB4ThDaNXG0884oUOU6MSb/Zl iN56ksUxukK6fhne0UPYucnwQ== X-Google-Smtp-Source: AGHT+IFwU1XiJoR2OWRbLkG28EWAEmdCzynRMpt5JQ+wWlgwEksCPAZjrqgzXzNBQN6662he0B1YxZKh6gRqcT105JA= X-Received: by 2002:a05:6000:22c5:b0:3ec:4e41:fd86 with SMTP id ffacd0b85a97d-3ecdfa2ae0emr3700096f8f.50.1758185461247; Thu, 18 Sep 2025 01:51:01 -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 From: Tilnel Date: Thu, 18 Sep 2025 16:50:46 +0800 X-Gm-Features: AS18NWA5Lde509Ti2CqcykwX1VKJNV-RTwGAyMqenftgEFUNaumHiJdzWoy-SCY Message-ID: Subject: Two different places between TCP socket behavior and RFC documents To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+] X-Rspamd-Queue-Id: 4cS8Vw1lc2z3h2c 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 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? Thanks.