From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none 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=cVTmGYVo; 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 D0EE85A0274 for ; Sun, 16 Feb 2025 15:27:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1739716019; 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=lZabYXbnx4WuG3shKNIktKawgx7PC88Szc9boJEFqjc=; b=cVTmGYVoARl5wBCXdQVxTruvY22U6Kt43sj9ZSuqHfsR64J1Ypb7m4DNAax+FN3nAF+FOS G97uFwhm7acvGATvJRRxKwqvXEtlZ8zbJug9umxS8Pk61s5N+JP+lI0qDuwoBXI0QcUd7q StYcW0HOb83uVGcECPYEHmRgT6gakKo= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-576-C8bl8T0ANQGs6Qy6c0Jg5g-1; Sun, 16 Feb 2025 09:26:56 -0500 X-MC-Unique: C8bl8T0ANQGs6Qy6c0Jg5g-1 X-Mimecast-MFC-AGG-ID: C8bl8T0ANQGs6Qy6c0Jg5g_1739716016 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6e666975a6fso65850786d6.3 for ; Sun, 16 Feb 2025 06:26:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739716016; x=1740320816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lZabYXbnx4WuG3shKNIktKawgx7PC88Szc9boJEFqjc=; b=wkoo8gumJjJSqFg4n82IOegQ1+hVdPQvQWsKLrasmx6ilWpcY9dYGhESEkr7ZXOOpn N5uLLG85/lW2NaG1c3DFSIRkwb7IfecrHjlkliS7q2UtFUB6N3+kPeXbkly66QQeM6ZY id0m8Ux4ZPh5VOEZBEBvdEAO8tHHx1Mb4kCeRYwYHJhAgXcPOrFq59U27aMjjAQoEtK0 ucFr1q7nc+qBzZDBCHwqXjXGZYagZ9HTz+nqNrHDS3HqecCdBISOSMxbFt8zH0Wdi48W uC0hTzI+JkvB3TIbwpait5Lj4MjMvUrsb8FRdTPVwaPIltjmK7jO+48VaPQimnyQVi4H rbGQ== X-Gm-Message-State: AOJu0YxnlEK7PP6aeWFLMj7Hub9+Xutn3Rm0+DyrrUJn7PkrU7HnVeRk Dhsthh1S85efHtJfMNyaca7PbqCjEb5LbirnLT0I4x2CMl0HQve3YS1x5u4uKXmimFfmUmKPMj3 +ba3GVK8uM4cTImAAFKXHfCaIvGe5GlbASapxpXeI8T6jNk8T4Q== X-Gm-Gg: ASbGncuX3htPnfuPodAxMzVXWCO16+Fg0Pfxo81TqM/eE026xC2zpHj+XLk1Z84zwzJ wSlU39ZmIPP19tL3UnhIw2m+FJw1HVlQQvrXlVVG+65dD3GLlIE244OfhS2U3T1E9c6hZVUP48J AalaQgNL9JF8oBu02hGzRcwIbc0ukO+aU5Gqn0vvLvu4QOd/+IuPu+8H7tnJe9A6KeUJJ18ZtqF bp3fgAlGfjmujKNV5ZsB/kkE8GToMvnsF1tU3U1L4S+DtlcJxPmE7BjD947x1sRjTS5jNchcu8C rm4= X-Received: by 2002:ad4:5766:0:b0:6e6:698f:cb00 with SMTP id 6a1803df08f44-6e66cd2833amr91314406d6.42.1739716016483; Sun, 16 Feb 2025 06:26:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IE6lxZ/IYTvsf7Bl8OSO267guC7vABU5N5XfvYyJZa2/Ri1M5vlU3Au44dP07qFvFbTuYb/hA== X-Received: by 2002:ad4:5766:0:b0:6e6:698f:cb00 with SMTP id 6a1803df08f44-6e66cd2833amr91314186d6.42.1739716016187; Sun, 16 Feb 2025 06:26:56 -0800 (PST) Received: from [10.0.0.215] ([24.225.235.209]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e65d785cb4sm42233896d6.43.2025.02.16.06.26.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Feb 2025 06:26:55 -0800 (PST) Message-ID: <0e286f0b-4427-4679-a4a0-b5e8910c3563@redhat.com> Date: Sun, 16 Feb 2025 09:26:54 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tap: always set the no_frag flag in IPv4 headers. To: Stefano Brivio References: <20250212235023.391449-1-jmaloy@redhat.com> <20250214120058.178c4fba@elisabeth> <20250214235716.2c7019df@elisabeth> From: Jon Maloy In-Reply-To: <20250214235716.2c7019df@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: M64fImyYTWhbqw5nOH0C9Of4h5aCXeA5V636rBOMSW8_1739716016 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: 5QFDBM7UIXPVD37HXFZNRVZVO2323HDQ X-Message-ID-Hash: 5QFDBM7UIXPVD37HXFZNRVZVO2323HDQ X-MailFrom: jmaloy@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, lvivier@redhat.com, dgibson@redhat.com 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 2025-02-14 17:57, Stefano Brivio wrote: > On Fri, 14 Feb 2025 17:46:21 -0500 > Jon Maloy wrote: > >> On 2025-02-14 06:00, Stefano Brivio wrote: >>> On Wed, 12 Feb 2025 18:50:23 -0500 >>> Jon Maloy wrote: >>> >>>> When studying the Linux source code and Wireshark dumps it seems like >>>> the no_frag flag in the IPv4 header is always set. Following discussions >>>> in the Internet on this subject indicates that modern routers never >>>> fragment packets, and that it isn't even supported in many cases. >>>> >>>> Adding to this that incoming messages forwarded on the tap interface >>>> never even pass through a router it seems safe to always set this flag. >>>> >>>> This makes the IPv4 headers of forwarded messages identical to those >>>> sent by the external sockets, something we must consider desirable. >>>> >>>> Signed-off-by: Jon Maloy >>>> --- >>>> tap.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/tap.c b/tap.c >>>> index d0673e5..44b0fc0 100644 >>>> --- a/tap.c >>>> +++ b/tap.c >>>> @@ -153,7 +153,7 @@ static void *tap_push_ip4h(struct iphdr *ip4h, struct in_addr src, >>>> ip4h->tos = 0; >>>> ip4h->tot_len = htons(l3len); >>>> ip4h->id = 0; >>>> - ip4h->frag_off = 0; >>>> + ip4h->frag_off = htons(IP_DF); >>> >>> $ tshark -r test/test_logs/pasta.pcap -V -Y frame.number==9 | grep "Header Checksum" >>> Header Checksum: 0x07d4 incorrect, should be 0xc7d3(may be caused by "IP checksum offload"?) >>> >>> See L2_BUF_IP4_PSUM(). >> >> Not sure what to do about this. I don't even see we calculate the >> checksum in our code > > We precalculate that part, see L2_BUF_IP4_PSUM() (and also > L2_BUF_IP4_INIT()). > >> so does it matter? Brain fart. I was thinking about the UDP header checksum, which is optional we don't caluclate in current code. Of course it matters. > > Well, I think it matters that we send out valid IPv4 packets. Try this > change and see for yourself. > Ok. Now I see what you mean. I will try this. ///jon