From nobody Thu Sep 18 21:31:04 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 4cSTMy0JGQz6844S for ; Thu, 18 Sep 2025 21:31:10 +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 4cSTMx5Xltz3dBV for ; Thu, 18 Sep 2025 21:31:09 +0000 (UTC) (envelope-from vadimnuclight@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-579363a4602so1107151e87.0 for ; Thu, 18 Sep 2025 14:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758231068; x=1758835868; 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=yJ8oqlTBasQjdziq0BGsVhUgk6d97Df+yP1DyE/viac=; b=UrkSTAdNvpwW6PVXqIuM3NaBXsza+CSwWg1S/QOkRFBsFSuIPkvh4D/+YKDccgpqGD Z3jxIqmRMo09TUfdUofHWEGClQ+3PrJUKFpks5I+UjnH02Rzt0vb38A0cbLxG+9ecf/S /sA/EHRk/Fdd0h38b3EY/zzCYYGry4Zq4c4IzxUR3+cp8sNspHNlX0MSfoFoqu+XeW38 nA+QcvgXPhItU5lbZhDdaX3EqjbauDXu1A5TKXmP5tT8TW6XCQiyw4STJZselv5ukFuG +Hf7gghkXHfzKah2yKONiNfq1awtYTAwrDFi5qeFIF9pEdFcBA7bn8H1XPnQ7V+0lxwv 1FrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758231068; x=1758835868; 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=yJ8oqlTBasQjdziq0BGsVhUgk6d97Df+yP1DyE/viac=; b=AUZlxMbiNCEJTjit9s1wiJYXyQSEyqtUcOuya/P5tB2Mg7UgUJGzK2Ux7DsuOT28Zp WYQam1rWSLAyBRxZesM68272wkVDuvrt6AujAUoeWeamscPn1EXFSolQ8tcunB6wsSHO EyF+EMM7Vk/EC9A23AKsEg3GFhlfIFQZcH04QN2tf97CBp/j6oPOkmaA8XEyCyvpmQwN hK6RQ9ojRMTvjy/CpwTr6fiePEKnKR269Nh0YlPygwA2UMTrqlAHyIOaSVWjbhRieUSH te2bF9ShmlxUA9WHr076lHGDVkv8fOH0xUSYOETl4QEXM6jGU6gPtMeL8pFFY+hEDbks H7Ug== X-Forwarded-Encrypted: i=1; AJvYcCWqPXHm9M/Y6G1aVKKGg9jLJ1BLvw8a+OL0ecnUQJ6uG5vbLtgxKKtf0ksmcue6O1JymMjBbI9FaXM1sQ==@freebsd.org X-Gm-Message-State: AOJu0YwVTfntTRI3V16lt+Z/oTPc46tisay1HMZPIjq7y8jfZ2hz2TSZ mYKVhKTiBeujsA8utDwrmc0dLH49x9L7BHqw5QtnZoemZwgFIvXZMQuE X-Gm-Gg: ASbGncsdX1WOdCs0WOeNHl8K2fvIYaGrFmBXioB9hIOcs3MKxP/6rN0TFZ1U6wm9x04 PDOQd1gtiPj1cQI8U4GUDnnUGPZCs/j8wbICmcyXYxFtoS9Vm+eitkJygzQGztdsXVGxYOZH8hm butOJjIbRyiqdrNk2wan7Au9YxMb3oyxkFf7bpIVD+Mj6O7oqInzhbYChYqjlWFTFRRkbiCzwka x0CgNTGgx44rqwSa93fp9nhqPC2X/OlFtLjpZ+gGQnLOr0yG8m7M4kBjQd9FPTLLVtdVRXnjR27 0LRJG74vWexy5/H7ZMsnJA0JtRP7xgJqbDcBVsLJLU8aqkAXzWDtJgMmE1XjT/CGOAyG0FHjSQC eNnAatLXxFNyBfPUBSDVUWXtGco8jQqXWDOLhZi4UfRcQGG3Ar9nQL+92mu71PsqqUt6zb3uj13 2Ox9TvE0PO X-Google-Smtp-Source: AGHT+IF6CVoes4uHw4HK2+Nr/WleMiRJ1+9PbexGLDb9QSRqktgNJrWMbhz+U3O8lMvfVaIK2nGgGA== X-Received: by 2002:a05:6512:1094:b0:55f:3525:3e52 with SMTP id 2adb3069b0e04-579dfec1eddmr380525e87.14.1758231068099; Thu, 18 Sep 2025 14:31:08 -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-578a90a207bsm952913e87.65.2025.09.18.14.31.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Sep 2025 14:31:07 -0700 (PDT) Date: Fri, 19 Sep 2025 00:31:04 +0300 From: Vadim Goncharov To: Tilnel Cc: Michael Tuexen , freebsd-net@freebsd.org Subject: Re: Two different places between TCP socket behavior and RFC documents Message-ID: <20250919003104.5857ecd7@nuclight.lan> In-Reply-To: References: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de> 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=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: 4cSTMx5Xltz3dBV On Fri, 19 Sep 2025 00:35:18 +0800 Tilnel wrote: > 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 > > > 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 =20 > > I am not sure which scenario are you considering. Could you provide SEG= .SEQ > > for the this TCP segment? =20 > > > 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 >=20 > 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 c= omplete > the three-way handshake, Socket A incorrectly sends > . According to the RFC, the appropriate re= sponse to > such a malformed ACK should be an empty ACK segment: > . After that, Socket B should either wai= t 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 ed= ge > cases. Best regards > Tilnel Did you check it with about ~2 G out of window? That is, your examples above were about ~200 M different sequence numbers, so that RST could be ignored. --=20 WBR, @nuclight