From nobody Wed Jan 15 07:52:22 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1682911218; cv=none; d=zohomail.com; s=zohoarc; b=ZJejFJhZVfa51z4VUl9VpsHM6yvnz0tu9tAfs7wA5t7/VYebBcUKnEItF+jKo39F7ZhGNN13zi0+FCcV9CWUYDQEOP/gByVE4LCjkQG9JtvC5VbpE9NM2rdGTE2Wwm7X55oDJ0qe6mcoC3RKC48ueUFUbWNHEBTSDbr6Gfrx7bo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1682911218; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=U1AmdvcFTSFeiIFIGNKYhqLKRJeCuuC86rDugP/i7Ks=; b=eYmPHExf9zRlcqjjjVhtvw/jGLMjiXSDjVzqkhmyopViedEVueaG7DOQkf6gycp27XCfT9MMLV1Sct9eOqTGnCCKAlQ1Kmfi0+n4CzsjdJWkRwKGUjvb3PolC/Yy2BDf34pq1HfdBhvwT+qg+QWq45RUpbjqJ4Wd64BZPqSDdHo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1682911218279287.2625235826324; Sun, 30 Apr 2023 20:20:18 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-203-pjkugBEUORej0iiGRl-nCg-1; Sun, 30 Apr 2023 23:20:12 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0163B2999B39; Mon, 1 May 2023 03:20:09 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 37CBA40C94AE; Mon, 1 May 2023 03:20:08 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 6B09D1946A75; Mon, 1 May 2023 03:20:06 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id CB40E194658D for ; Mon, 1 May 2023 03:20:05 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id EA16340F177; Mon, 1 May 2023 03:19:45 +0000 (UTC) Received: from vhost3.router.laine.org (unknown [10.22.8.105]) by smtp.corp.redhat.com (Postfix) with ESMTP id D19AD475072 for ; Mon, 1 May 2023 03:19:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682911217; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=U1AmdvcFTSFeiIFIGNKYhqLKRJeCuuC86rDugP/i7Ks=; b=Mq425p+E+YTLzNDJs6rXaajrCxNCE0bLvkZSyxoE0lIJIAuTzb+DFoT1wZl3Mx3xfYsGNu Z9DKnXaDb2YKglEclOSouPvPVFO269cp3rUhtyiIgMRLZvygGkY73bC7uGrqFfnPBS6Eqh 04fPtUv3UpQXGbHRv0QhjlZipwhG3yo= X-MC-Unique: pjkugBEUORej0iiGRl-nCg-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Laine Stump To: libvir-list@redhat.com Subject: [libvirt PATCH 12/28] network: do not add DHCP checksum mangle rule unless using iptables Date: Sun, 30 Apr 2023 23:19:27 -0400 Message-Id: <20230501031943.288145-13-laine@redhat.com> In-Reply-To: <20230501031943.288145-1-laine@redhat.com> References: <20230501031943.288145-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1682911219682100003 Content-Type: text/plain; charset="utf-8"; x-default="true" Long long ago (commit fd5b15ff in July 2010), we determined that the combination of virtio-net + vhost packet handling (i.e. handling packets in the kernel rather than userspace) + very old guest OSes (e.g. RHEL5, but not even RHEL6) would result in the checksum of dhcp packets being unset, which would cause the packet to be dropped, and the guest would never acquire an IP address. The fix for this was for iptables to create a new rule that would fixup packet checksums for certain packets, and for libvirt to add one of these rules to the iptables "mangle" table. This was considered a horrid hack even at the time, and when nftables was created, the functionality wasn't replicated there. So when we add rules using nftables, there is no way to add such a rule, and your options are thus: 1) stop using outdated, out of support guest OSes 2) Don't use vhost=3Don for the guest virtio interface, ie. add to the definition. 3) continue having libvirt use iptables for its rules (I'm not certain, but I think even this may fail depending on which iptables compatability packages are being used). All of this is to explain why we simply ignore calls to add a "checksum fixup" rule when the firewall backend isn't iptables. I could have plumbed this function all the way through virNetfilter* -> virNftables* and then done an empty return from there, but figured since it is a hack I'd rather keep it as localized as possible, and just cut it off right at the top of the call chain in the network driver. P.S. This specific behavior is really the only concrete reason for keeping around an iptables backend, rather than just replacing it with nftables. Signed-off-by: Laine Stump --- src/network/bridge_driver_linux.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/network/bridge_driver_linux.c b/src/network/bridge_driver_= linux.c index ff2f87054d..3efb669789 100644 --- a/src/network/bridge_driver_linux.c +++ b/src/network/bridge_driver_linux.c @@ -721,6 +721,15 @@ networkAddChecksumFirewallRules(virFirewall *fw, size_t i; virNetworkIPDef *ipv4def; =20 + /* these rules are only supported by the iptables + * backend. nftables doesn't have equivalent functionality, + * because it was always seen as an ugly hack. Fortunately this + * hack was only ever needed for *very* old guest OSes (RHEL5 era) + * using virtio network device with vhost enabled. + */ + if (virFirewallGetBackend(fw) !=3D VIR_FIREWALL_BACKEND_IPTABLES) + return; + /* First look for first IPv4 address that has dhcp or tftpboot defined= . */ /* We support dhcp config on 1 IPv4 interface only. */ for (i =3D 0; @@ -747,6 +756,10 @@ networkRemoveChecksumFirewallRules(virFirewall *fw, size_t i; virNetworkIPDef *ipv4def; =20 + /* iptables backend only */ + if (virFirewallGetBackend(fw) !=3D VIR_FIREWALL_BACKEND_IPTABLES) + return; + /* First look for first IPv4 address that has dhcp or tftpboot defined= . */ /* We support dhcp config on 1 IPv4 interface only. */ for (i =3D 0; --=20 2.39.2