From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JOO+I0lP; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 27F025A0262 for ; Fri, 19 Jun 2026 19:05:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781888738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GSW493U4I8+UREt3PyaPZEakYVuyaTlmcZ2CjNF2Seg=; b=JOO+I0lPqxcu4EZ8bqqujIp/6fXCwFuKu9K/L4T8slYyryWA++JDtlZprfJLL93LjEb6Fg Rr7qKkdyjG/J+wT/9VKGu0K7Yj2StO9iy96/1GFzr4j8/hirpWJjTEpbbJwn1D+EuusTe9 lrF2i1dEuybWeALqSe9FqGm6NRk23p8= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-84-aSnYgeSCOKmnweJ_iUSW4w-1; Fri, 19 Jun 2026 13:05:36 -0400 X-MC-Unique: aSnYgeSCOKmnweJ_iUSW4w-1 X-Mimecast-MFC-AGG-ID: aSnYgeSCOKmnweJ_iUSW4w_1781888735 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-46671e99713so10333f8f.2 for ; Fri, 19 Jun 2026 10:05:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781888735; x=1782493535; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GSW493U4I8+UREt3PyaPZEakYVuyaTlmcZ2CjNF2Seg=; b=V7SWWE0mHmwvIR4B7ZAp3HHQQOAN2pqGgu0nWmEgm/uFBX6y3L7cyqIghaRf44K5hX HWG/1gz+Bu9/2+K3AmM5Xs3iGpGsrDakUCAP7GkQLlU63ijxBFKTkCwZTMqOmj6XyQuI va68t5t83gwYuZ2T1eNXPoQp2zIgyvBKAqHdfLcI8P28neKWBFZw/p1UE0hnIaBUg0SF A67dKDq2Zbbq2lZlS14QN5mihWpmLtyG1p7RpyI5M69uh9WRuwKC7cZFdBLkEGkKAETV TeerP/tErBbzJJrtXJqgPl369O0+Emaf+asm9XzT5/q9M41IZVPPQA2tBvI+R7eXe2qH hHvA== X-Gm-Message-State: AOJu0YyrR5Emk8hmCpCGa/48gDNUBG5YhfIILlXmVG/CGHtcKS087BsU 3gE3s96LTMCYD6mYNM5PI+aas/sYClY8NoNISE/sY1Ip66Y7rAnn6hArWH6Tj+ibTHZ6rFOLrz/ 3lrx9DEtbZ1mF+ov7iQxsN7s9wkma49Wyyb0PxC1Ll8qcs2OvFFIRCOMh++CYcw== X-Gm-Gg: AfdE7cn3lI3xISAIWP9HwwF8jOdcKWjZ7WFiUgNww6KIh73AdwMvVgfo7kQ0iYLfzf8 ipLTtxrUP67zIRnSDTZamlrmuIJSwYZOfizEHju/oYxvZtS/7DcGJeMFJtmnsOEDUpIy6k9dfB1 kdT4Kyux/24MCKOSU8IuRb+D5HF2Qap5LxFOfa7ttMWGLSIJ2Ym8ulqm84bv6dilhyHs8ukfU3y /8sIIH4cbs9Bh0Prhq9w3qfZpQ4WMj3mOxl8YkMgu2tt+GwfqlU4/ehMJBUP2pTLUvMGh5xu/su qdCNFgzJAQ0R20NVn5skO9n707Szsuo3CiZwPIudbYxFLE7wo8Qmq4Vs7CHF/B7fx79G5ldsR5M v40bgJ1scAj4peqJEVlBMFQ== X-Received: by 2002:a05:600c:1d1b:b0:492:41a1:f20d with SMTP id 5b1f17b1804b1-49241a1f2bbmr49619245e9.5.1781888735055; Fri, 19 Jun 2026 10:05:35 -0700 (PDT) X-Received: by 2002:a05:600c:1d1b:b0:492:41a1:f20d with SMTP id 5b1f17b1804b1-49241a1f2bbmr49618575e9.5.1781888734426; Fri, 19 Jun 2026 10:05:34 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4923fce9590sm84148895e9.4.2026.06.19.10.05.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2026 10:05:33 -0700 (PDT) From: Stefano Brivio To: David du Colombier <0intro@gmail.com> Subject: Re: [PATCH v2] tap: Trim Ethernet padding from short IPv4 frames instead of dropping them Message-ID: <20260619190532.77004548@elisabeth> In-Reply-To: <20260616163705.1285803-1-0intro@gmail.com> References: <20260612214338.12345-1-0intro@gmail.com> <20260616163705.1285803-1-0intro@gmail.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Fri, 19 Jun 2026 19:05:33 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: le91mPDYbNKs0qKV_uu9TIdEVXqTprmjo9CjsZjMVhY_1781888735 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: IQJ4WRFFEYCLP6BIRXZSGTMZH62YZ4Y5 X-Message-ID-Hash: IQJ4WRFFEYCLP6BIRXZSGTMZH62YZ4Y5 X-MailFrom: sbrivio@redhat.com 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: passt-dev@passt.top, Laurent Vivier 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: On Tue, 16 Jun 2026 18:37:05 +0200 David du Colombier <0intro@gmail.com> wrote: > tap4_handler() requires the L2 payload after the IP header to match > the IP datagram length exactly. Guests whose drivers pad transmitted > frames to the 60 byte Ethernet minimum, as real hardware requires and > as drivers modelled on hardware do (Plan 9's virtio-net, for one), > send pure ACK and FIN segments as 60 byte frames: 14 byte Ethernet > header, 40 byte IPv4 datagram, 6 padding octets. Those frames fail > the exact length check and are dropped without trace. > > passt then never sees such a guest's acknowledgements: it > retransmits from the lowest unacknowledged sequence with exponential > backoff while the guest, which received and acknowledged everything, > waits. Every fresh connection stalls for minutes (a 1 MiB HTTP fetch > over --map-host-loopback measured 248 s before this change, 0.27 s > after; bulk transfer over established connections, whose ACKs ride > data segments above the padding threshold, is unaffected). FIN > segments are padded too, so teardown hangs as well. Note that > tap_send_single() pads passt's own outbound frames to ETH_ZLEN, so > the receive path was already stricter than the send path. > > Trim the trailing padding to the IP datagram length instead, using a > new iov_tail_trim() helper, and keep dropping frames genuinely > shorter than the datagram they claim to carry. IPv6 is unaffected: > its minimal TCP frame is 74 bytes, above the padding threshold. > > Signed-off-by: David du Colombier <0intro@gmail.com> > --- > v2: > - store the iov_tail_size() result in a local variable instead of > computing it twice > - pass ARRAY_SIZE(trim_iov) instead of UIO_MAXIOV Applied, thanks for fixing this, and welcome to the git log! -- Stefano