From nobody Thu Sep 18 16:35:18 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 4cSLpx1DTnz67fwm for ; Thu, 18 Sep 2025 16:35:37 +0000 (UTC) (envelope-from deng1991816@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 4cSLpw52CZz47n8 for ; Thu, 18 Sep 2025 16:35:36 +0000 (UTC) (envelope-from deng1991816@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3ee12807d97so790638f8f.0 for ; Thu, 18 Sep 2025 09:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758213330; x=1758818130; 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=6oro2PZ8iVYc1EJF8/OwiGQHjSvf/vMWkacq/pOzMbY=; b=fznXao2Ie/pwQHutQp8LiAnHP97SbSIelt+XDAvLVaDbhJbWLUdz6awjvH+FtxO/M0 pgQOz7c7zn3QzqQJHqKtMMhiDPu2+kB/QLbhtz0zUuaUo6FyvudNx+5fCU+pIHx8iCkM 1EXGiJyFNk0wq8jSXa7eHwp2ldKGZ+yDh2jbNIBsVCmKe2YAruiHTF24DCaArWs6udMp SkZGt0UZTNgdl3pRG7ITKvJ08MECZFlFc/MqNpXElBhnzGNN2hz7Y3yCqEC/9ABRm+Nd OO4cfdvEnzuVytMgbbsO+7tTRRlMgQYppuRiF2OjP5mOFSfwg8i2L2ykJTjWgHi+wHCc zvxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758213330; x=1758818130; 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=6oro2PZ8iVYc1EJF8/OwiGQHjSvf/vMWkacq/pOzMbY=; b=rkxOGLabXuOEaQL8Yd8BQXZutlEe1+Ke4aQd17sYBupYi74nsDf/ercoch92A+JTrL qv16QQ2aTRS0mec7YWic/GA6o03+ORCfKb4wMq1cZnMK1EftAnutbCngS6Brmw8bJUh7 jIEPM8D5pXUDViIrzXbGTznNJQm47XKGUKuGG7X1AFmM8G5qGpSwmpFIx6J4l/TlZ83l 2syTGTkofkoLDKU0AAQhot2fJ+kGGTGsIFrZgeneKeQX0y4LQLTs8zH0lFT2CSNu8iEP HfHYAaeofDv0HMVW1OIBgyKVmYiLzsX0sLw9L9XRR2WXydSwQw2QMiwnfDKwgt9jGYrn ZRQg== X-Gm-Message-State: AOJu0Yzvi6mSzelL6KBVbN6xFyEHkuUioeM4486ICo60gCFMiGHT7T7E LPWTycZBuC4Ae5oXK83rB1gJr8jIG8Ot0v0z/0RDzIEXLk57mR/ZeorZW0NTFLmgulFmTQ1rmE4 NvI7uXrqLXzjJd4ym5eNom5KCecyLfw4= X-Gm-Gg: ASbGncvuYEJpLP84f40lO4ypc0pwdl5MnZ1VuU+ytenNssssZSWKSSb2SElQTELea9O NeJ581r/Gbg1j1l6Kuw5GUit13eCYX9eHk8nf5GJo0zL0SXGsnQQHKhKf0O2zbdcMm/EBppegXr ud9MC8wic96NoxYfHpL6R+Sk5x9IztXVwrKOX/JMhehoqtAOXqJNxS/8RjhbG/kV+eHvsTfp3l9 35xLRwGVO1IeCJ4N/CA2mpTfQ== X-Google-Smtp-Source: AGHT+IFHxajxGP8Km23Fl7GCZ1gYej9UUlfcV4+2XJAHhq4Uz1erfzjfjxpf6lQuMd6CwQ4w12RfkFtlt9TR9g8Bvc0= X-Received: by 2002:a05:6000:40c8:b0:3ea:f4a1:f063 with SMTP id ffacd0b85a97d-3ecdfa41fccmr5813024f8f.55.1758213329957; Thu, 18 Sep 2025 09:35:29 -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: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de> In-Reply-To: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de> From: Tilnel Date: Fri, 19 Sep 2025 00:35:18 +0800 X-Gm-Features: AS18NWBDqR5bJT3Sv0rRa0U3mKa87bpQL2cE-2Z0qaoUDpYvRDtfyf8AdS_t9bE Message-ID: Subject: Re: Two different places between TCP socket behavior and RFC documents To: Michael Tuexen 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]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cSLpw52CZz47n8 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 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 constr= ucted 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.S= EQ > 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. 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 com= plete the three-way handshake, Socket A incorrectly sends . According to the RFC, the appropriate response to such a malformed ACK shou= ld 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. Best regards Tilnel