From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 9B7A45A0280 for ; Fri, 8 Sep 2023 03:50:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1694137797; bh=BZY4rRb8rEoQJiybFMljqxc1zuVAe7nM2XaaWhTT0PE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ELX3HZt0+MFPMGy5hzdlW8QM1thfS/BpeyRXhSdTKwPaCLOwbpVN+mPGl0S7A6eCG XjLkNFLNAJPw9ZVYx9gNhxxvmPE1PKqXD6NhVG10QggWI1/8yGfyBqYV9vEm6fD6Fc UrdqB7nSLRWnpdaBCn30nweBsP1ZW862oUeGmwho= Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4RhfF10zVLz4xGN; Fri, 8 Sep 2023 11:49:57 +1000 (AEST) From: David Gibson To: passt-dev@passt.top, Stefano Brivio Subject: [PATCH 8/8] tcp: Correct handling of FIN,ACK followed by SYN Date: Fri, 8 Sep 2023 11:49:53 +1000 Message-ID: <20230908014953.822952-9-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230908014953.822952-1-david@gibson.dropbear.id.au> References: <20230908014953.822952-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID-Hash: 42OR5RCTBEBJR7N6EVAJ7NQQ45Z2YD65 X-Message-ID-Hash: 42OR5RCTBEBJR7N6EVAJ7NQQ45Z2YD65 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: jlesev@gmail.com, 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: When the guest tries to establish a connection, it could give up on it by sending a FIN,ACK instead of a plain ACK to our SYN,ACK. It could then make a new attempt to establish a connection with the same addresses and ports with a new SYN. Although it's unlikely, it could send the 2nd SYN very shortly after the FIN,ACK resulting in both being received in the same batch of packets from the tap interface. Currently, we don't handle that correctly, when we receive a FIN,ACK on a not fully established connection we discard the remaining packets in the batch, and so will never process the 2nd SYN. Correct this by returning 1 from tcp_tap_handler() in this case, so we'll just consume the FIN,ACK and continue to process the rest of the batch. Signed-off-by: David Gibson --- tcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tcp.c b/tcp.c index c76df73..dd3142d 100644 --- a/tcp.c +++ b/tcp.c @@ -2598,7 +2598,7 @@ int tcp_tap_handler(struct ctx *c, int af, const void *saddr, const void *daddr, tcp_send_flag(c, conn, ACK); conn_event(c, conn, SOCK_FIN_SENT); - return p->count - idx; + return 1; } if (!th->ack) -- 2.41.0