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=P/e3Z18r; 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 7EC635A0619 for ; Mon, 20 Oct 2025 12:00:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1760954442; 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=J/GfIQMUmUGhoBvq2Z31kYV/ZmkO7xuswMF5nmZRkss=; b=P/e3Z18rfWci3/D1T975HNS4uL1etyUQcoqxow8ixwVH3lPmjAA+aALhSiaRQKNOzfttrw k1Z1sw6zec/DGjN4F6FpQmBvcviwmzCf21QBDF/znPUdqcnXX6+XTx5LXwBAnztNQbc8Ys F9Vg1/Lah76UsbMsa1uJ0HfjJ+icTB0= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-60-LlGaGotCNsiLjpurSGcrxQ-1; Mon, 20 Oct 2025 06:00:40 -0400 X-MC-Unique: LlGaGotCNsiLjpurSGcrxQ-1 X-Mimecast-MFC-AGG-ID: LlGaGotCNsiLjpurSGcrxQ_1760954440 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-87c171369aaso183407306d6.0 for ; Mon, 20 Oct 2025 03:00:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760954440; x=1761559240; 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=J/GfIQMUmUGhoBvq2Z31kYV/ZmkO7xuswMF5nmZRkss=; b=AFxXCdE8DCeeddCQeSbb7vwrRIzzxeeJZSopq1KyVyazVM4EM0Hh7ebzswR1eXCZ7k JxeSEXjIUueNQB87NpGxOA0e4PyXi8tUItT5YG7PM65fxnAcBXycUJ9WfXOdrW/utdrK b6z6Z/5K5MT9g+79PdpVekBBZlEEtHqrT3BfM+/cvL2yfiPNYOP0H0X7GyfYi79dEK/R 09FsOPWGsoekX4qlw280S+e7s6BDhM/7fYrKnVEdlhNyY9mfBS05jQRaJqctDkBlPSkA VE+aRJtZPJT5547nKoYlXQHUmyVxNQBeWgbVx3EgofPAfOn3U89wmAzAl5MA0HCjjKUd a5fw== X-Forwarded-Encrypted: i=1; AJvYcCUNB7ZTQc6MR2WJqSvn/3ZoIxD8oItNYKgTww5iHjvyiTHBhV1BoZeNVgmDmIxNZcpFwvO5JEwxwEc=@passt.top X-Gm-Message-State: AOJu0YycC0BOoNMk3J8ljrTsLULwiy5vbq2iFEgDezVHX3UPe4dYJfkE hntcYM8mBmc6vznScfFsebCur6bHpGFREp6uuX3bJsZzBguxPUZ4HbRk1Xt4KKKo3DyUf8vpKOe AltbzMqgo+6RzZWizI2Vjupz2BIt23a+6chxmGQ/QmlhNtZ5z3UrFBA== X-Gm-Gg: ASbGnctqt34Ny02BjuZz9EPNocZLoIxSc0Y9Il5sdFiCEWAA12sC4bnKGO48QSDZ9JN DKO9c1RQTL3qOXwZjr/T++pH8hH0Gn8IDEgkQPaugE8bjypPf9eN1aIBYFaF9WNaxib9fwavxQe XtrVIdjBlTTOd0efKfO+QxJLHLNGHViWfJeTCUUPmvgGfBDM6b8fQpCMdtJhuDj8y2IH0s8j9eQ AwOcYlHQvuB2jJXejEdHHqrwlAq8ZdWKTybbXVe6uwljSa0ZGLd1QWFjSNzTKJ1g5vEikEpLVhc Mt7ISaU9k3EKVtr3dUyKOfzDGsvME+RkXS3zI+Y4DKhAOPrb8xZIBOLVkwHZcgFiEebQ0YWYO+M SKFi86EkH+ZmR5Gc6bDV7xg2wk1Swy93RQwxo2wNwo3rP X-Received: by 2002:a05:6214:d85:b0:77e:aba2:c8b1 with SMTP id 6a1803df08f44-87c0cb58d00mr211710386d6.22.1760954439504; Mon, 20 Oct 2025 03:00:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGjej9ZVEMMJyhCtJ4a1343i+j0t0qKJlg9u1McrkIGFZcGG93IiXuIKKUFDHF2QaPdD+eO5w== X-Received: by 2002:a05:6214:d85:b0:77e:aba2:c8b1 with SMTP id 6a1803df08f44-87c0cb58d00mr211709876d6.22.1760954438908; Mon, 20 Oct 2025 03:00:38 -0700 (PDT) Received: from ?IPV6:2001:4958:2193:9901:6217:960c:2ef1:f0f3? ([2001:4958:2193:9901:6217:960c:2ef1:f0f3]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-87d028ad241sm48210106d6.46.2025.10.20.03.00.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Oct 2025 03:00:38 -0700 (PDT) Message-ID: Date: Mon, 20 Oct 2025 06:00:37 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v14 03/10] fwd: Add cache table for ARP/NDP contents To: David Gibson References: <20251015025521.1449156-1-jmaloy@redhat.com> <20251015025521.1449156-4-jmaloy@redhat.com> From: Jon Maloy In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _w_oxrnyE7TjHLxlSDjoAoB5-AJrxko6NqGisbsL6DQ_1760954440 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: R5MBGT5H3COEPBWBBZJXP3FAXGHU7F4J X-Message-ID-Hash: R5MBGT5H3COEPBWBBZJXP3FAXGHU7F4J 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: sbrivio@redhat.com, dgibson@redhat.com, passt-dev@passt.top 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-10-19 20:06, David Gibson wrote: > On Fri, Oct 17, 2025 at 02:49:33PM -0400, Jon Maloy wrote: [...] >> I also noticed it is possible to set guest_gw to some random address while >> at the same time setting no_map_gw. It seems to be harmless, since no_map_gw >> takes precedence, but it is an inconsistency we should fence >> against. > > No, the existing behaviour is correct. It gets confusing, because the > guest_gw is used for magic NATs, that's often what we're referring to > when we discuss the guest_gw address. > > But the guest_gw is *also* exactly what it says on the tin: the > gateway address the guest uses. Without that, the guest won't have > connectivity at all, so we need it. --no-map-gw means we don't have > the magic NATs, but there's still a gateway, and -g still does and > should control its address. So, your are telling me this is expected behaviour? jmaloy@mimir:~/passt/tests/udp_test$ /home/jmaloy/passt/passt/pasta --config-net --no-splice -d -a 192.168.2.2 -g 192.168.2.3 --no-map-gw Template interface: wlp1s0 (IPv4), wlp1s0 (IPv6) Namespace interface: wlp1s0 MAC: host: 9a:55:9a:55:9a:55 DHCP: assign: 192.168.2.2 mask: 255.255.255.0 router: 192.168.2.3 DNS: 10.11.5.19 10.2.32.1 DNS search list: redhat.com rmtcaqc.csb NDP/DHCPv6: assign: 2001:4958:2193:9901:6217:960c:2ef1:f0f3 router: fe80::c23c:4ff:fe04:4638 our link-local: fe80::c23c:4ff:fe04:4638 DNS search list: redhat.com rmtcaqc.csb Sending initial ARP request for guest MAC address Sending initial NDP NS request for guest MAC address SO_PEEK_OFF supported TCP_INFO tcpi_snd_wnd field supported TCP_INFO tcpi_bytes_acked field supported TCP_INFO tcpi_min_rtt field supported root@mimir:~/passt/tests/udp_test# ip r default via 192.168.2.3 dev wlp1s0 192.168.2.0/24 dev wlp1s0 proto kernel scope link src 192.168.2.2 root@mimir:~/passt/tests/udp_test# ping 192.168.2.3 PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data. ^C^ --- 192.168.2.3 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4080ms root@mimir:~/passt/tests/udp_test# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=7.68 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=20.9 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=19.1 ms ^C --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 7.676/15.889/20.876/5.851 ms root@mimir:~/passt/tests/udp_test# ///jon > >>> In any case I think you can drop the inany_equals() test - the >>> permanent bit will stop the second update from clobbering the first, >>> even if we are misconfigured. >>> >>>> + uint8_t mac[ETH_ALEN]; >>>> + int rc; >>>> + >>>> + rc = nl_link_get_mac(nl_sock, c->ifi4, mac); >>>> + if (rc < 0) { >>>> + debug("Couldn't get ip4 MAC addr: %s", strerror_(-rc)); >>>> + memcpy(mac, c->our_tap_mac, ETH_ALEN); >>>> + } >>> >>> Using the host's MAC for --map-guest-addr only makes sense if the >>> guest address is the same as the host address. If -a is used to make >>> the guest address different, then it may shadow some other random >>> node, not the host. We don't need special handling for that case - >>> the nat_inbound() you already have will do what we need. >>> >>> IIUC, the host itself doesn't appear in the neighbour table, so we do >>> need special handling if we want to use the host MAC when >>> --map-guest-addr *does* refer to the host. To handle that, I think >>> what we want is pseudo-codishly: >>> >>> fwd_neigh_table_update(c, nat_inbound(host_addr), host_mac, true); >>> >>> The wrinkle is that while we do get the host address at some point, >>> I'm not sure we keep it around (it's typically irrelevant after init). >>> >>> Strictly speaking 'permanent' isn't really correct here, but it's not >>> worth the hassle of setting up a whole other netlink monitor to watch >>> for changes in the host's MAC address. >>> >>> In fact.. I'm not sure it's worth handling this case at all. I think >>> it would be ok to just drop this clause. That means we'll use >>> our_tap_mac by default for things NATted to the (non loopback) host, >>> which is probably fine. >>> >> Fine with me, but I do think we need a blocker entry just in case somebody >> else comes up with the same address. > > We don't need a blocker. If someone else (let's call them X) comes up > with that address, that implies it's not the host's address. If > that's so then --map-guest-gw will NAT to X, and that's intended. In > which case it also makes sense to use X's MAC address. We don't need > to do anything special to make that happen - X will appear in the host > neigh table, and the nat_inbound() call will put it into the slot of > the --map-guest-gw address. > >> I'll post a complementary commit once the series has been applied. >> >> ///jon >> >> >