From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 8A34A5A026D for ; Mon, 27 Mar 2023 05:56:42 +0200 (CEST) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4PlJsJ6pGRz4xDk; Mon, 27 Mar 2023 14:56:36 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1679889396; bh=WT/Ui35xv7SUcYH3oUsVnks2k5Gwa/5GhuFcJJbx5h8=; h=From:To:Cc:Subject:Date:From; b=WBj5KnSB2+6A0vvKD9XZVuniinTan5wog33ImOr1265Fg1B8P/LCCSgEI/eHK+BBI EtA66uKebiwSTEmVnyWLfP85uJP+RFyPPq04SZB+wUyiIAnCFoRBlbjxmqi+MxpBBD /HGpNV9IkqGHQaGAG7wkZ+PTT3Rv90gOG0gkGd2Y= From: David Gibson To: Stefano Brivio , passt-dev@passt.top Subject: [PATCH 0/2] tcp: Correct handling of first ACK (or SYN-ACK) packet Date: Mon, 27 Mar 2023 14:56:32 +1100 Message-Id: <20230327035634.1432064-1-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.39.2 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: P2VYRIXPYJG4OPZSOC46CBEO5CKEI65T X-Message-ID-Hash: P2VYRIXPYJG4OPZSOC46CBEO5CKEI65T X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: David Gibson X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: We have a subtle problem in the handling of the very first ack-flagged packet (either the SYN-ACK or ACK from the three way handshake). Stefano has posted a couple of versions of a patch addressing this, however I think this is a better approach. From the TCP logical point of view, that first ACK does advance the sequence number, and if we treat it as doing so, then the logic we already had in tcp_update_seqack_from_tap() is correct. David Gibson (2): tcp: Clarify allowed state for tcp_data_from_tap() tcp: Don't special case the handling of the ack of a syn tcp.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) -- 2.39.2