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=grToKvG6; 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 0F6135A004E for ; Wed, 14 Jan 2026 00:34:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768347282; 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=enkhsjs282VOddLdznqCet15sJiUxV9kAoMhKFozJ2s=; b=grToKvG6HXjIAOVGfEKjKAXqW4w2snbSQskREFBk7QS9Qs388jw32q3tus7Rm+r7JkuSia DmxCbYrRlILU26KJ5snq+k/4R8DzbxtEkLi+PXxcyn5AOBfiIcAnVWv5yiTdyB/a2z/MIk 9Vhg7HAq2ADhyhrsskNHnGikW6Ye3BM= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-DrfGfrPnNG6J_5U8HLgHXA-1; Tue, 13 Jan 2026 18:34:40 -0500 X-MC-Unique: DrfGfrPnNG6J_5U8HLgHXA-1 X-Mimecast-MFC-AGG-ID: DrfGfrPnNG6J_5U8HLgHXA_1768347279 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-430fb8d41acso5332276f8f.1 for ; Tue, 13 Jan 2026 15:34:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768347279; x=1768952079; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SGmqXxolbeu+IdWdiiURsCQGHQIEYzBFaGXHNbaJFAM=; b=k/RvvVFO6XwhUYJtyPulm1aJwDeQVxcgWNHIzctO6Kc1XwaX1ZS3bBan5KC1BLzNuQ Tx64QlqJyjP+4jN6kQr2ntNgBrJJ4M5HUQUS0SV0m80/rzyO8fa28hX0fv/U+VT+123L aZ0c1Cxakyr7XdDE1Bjd8VfP13Rk4uFAQKwCu4wp/BBVRuXWRRvd31yecW/K6lBWBUI5 yfjjdQkWnfi53Ct0R25SU1d/uwUwM9tKWVbHuWgDsNzLXJY6xzimFZeU7sPJ53KQdQ6J pp6eF0uKfu+VZVkeQM9gdhsS5c91/l3z5lGE6nPN1D8/q0KOVtEKKY2pOa7bqtvawlqJ iJkw== X-Forwarded-Encrypted: i=1; AJvYcCX3+jAyl/faokEbkZBl9crhfJ/DF0ysVoFfhsWQOpyBLrd3dazLTzltOakxFlTwvJ0xZAMif0ld/0E=@passt.top X-Gm-Message-State: AOJu0YyRiXqFukJQiAuzsnaIWEWOLjRzod/nZ9c0OIZMPPt63W21e0JJ ifJ51kgiigqDmyeQSGFNtyLqMPwg2iudaZT42fbK4FBazUnh06HmxeK4+suDSb6Sbdnt7qA317p xriAxGSF2DQ6DOsAOlVjkKiH3h9UW8jJ1gi5eJx2qPJohDf9GeomK1Q== X-Gm-Gg: AY/fxX6kdRgm6ralGMbPqccOg/OI0ZDL1Ku5SCLCIR8HXGmrq/CBrOy/jWLn7Tr2OsL Ukkut6QQLKxtohBj/KlHLQ39jM7RhDc1FHhbWwBknJdUXdldcSEphPGzfkyLKd9pctsGFSU8EaP PN2Pjkr1pzB0NCqYqMLs42han7VwzzVywr/XTz1t3yjfmFZpvU7x3FRqEkpcHuJKGGDraifIgFd WjuW3HQ/lMPq+MTW/urVc338U+9tbIdGfNp98bNbAsvX8Navm8e9naT5vCCpGHRYgaGDHAdmgEO GFZOaFZ70VEwZryJdrjLBmCKTcwtiGm008lS3ZJ6VVh4hoLJKuawIqOE/KTHcut/3mqBjMl1yqu xce6tGKczZUXlALdhcIsksaDlIDy1vPFqtYma/w== X-Received: by 2002:a05:6000:2893:b0:42f:bc61:d1e5 with SMTP id ffacd0b85a97d-4342c4f9c8bmr742998f8f.15.1768347279260; Tue, 13 Jan 2026 15:34:39 -0800 (PST) X-Received: by 2002:a05:6000:2893:b0:42f:bc61:d1e5 with SMTP id ffacd0b85a97d-4342c4f9c8bmr742979f8f.15.1768347278680; Tue, 13 Jan 2026 15:34:38 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0daa84sm46663440f8f.2.2026.01.13.15.34.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 15:34:38 -0800 (PST) Date: Wed, 14 Jan 2026 00:34:36 +0100 From: Stefano Brivio To: Yumei Huang Subject: Re: [PATCH] conf, pasta: Add --no-tap option Message-ID: <20260114003436.56c64b44@elisabeth> In-Reply-To: References: <20251229095558.918055-1-yuhuang@redhat.com> <20260110191219.29498050@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -dPT739iHNPGTKgM1Ylgg0KgccAnibXz8xSaHfNDiVw_1768347279 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 7TJNHVBKBZVUIAEPIYWKEBLR32FFHBX5 X-Message-ID-Hash: 7TJNHVBKBZVUIAEPIYWKEBLR32FFHBX5 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: David Gibson , 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 Tue, 13 Jan 2026 17:57:11 +0800 Yumei Huang wrote: > On Sun, Jan 11, 2026 at 2:12=E2=80=AFAM Stefano Brivio wrote: > > > > On Mon, 5 Jan 2026 16:53:49 +0800 > > Yumei Huang wrote: > > =20 > > > On Mon, Jan 5, 2026 at 12:18=E2=80=AFPM David Gibson > > > wrote: =20 > > > > > > > > On Mon, Dec 29, 2025 at 05:55:58PM +0800, Yumei Huang wrote: =20 > > > > > This patch introduces a mode where we only forward loopback conne= ctions > > > > > and traffic between two namespaces (via the loopback interface, '= lo'), > > > > > without a tap device. > > > > > > > > > > With this, podman can support forwarding ::1 in custom networks w= hen using > > > > > rootlesskit for forwarding ports. > > > > > > > > > > In --no-tap mode, --host-lo-to-ns-lo, --no-icmp and --no-ra is au= tomatically > > > > > enabled. Options requiring a tap device (--ns-ifname, --ns-mac-ad= dr, > > > > > --config-net, --outbound-if4/6) are rejected. > > > > > > > > > > Link: https://bugs.passt.top/show_bug.cgi?id=3D149 > > > > > Signed-off-by: Yumei Huang =20 > > > > > > > > Nice work. There are some things that need polish, but overall thi= s > > > > looks pretty good to me. Like Stefano, I'm pleasantly surprised at > > > > how simple it turned out to be. > > > > =20 > > > > > --- > > > > > conf.c | 56 +++++++++++++++++++++++++++++++++++++++++----------= ----- > > > > > fwd.c | 3 +++ > > > > > passt.1 | 5 +++++ > > > > > passt.h | 2 ++ > > > > > pasta.c | 3 +++ > > > > > tap.c | 11 +++++++---- > > > > > 6 files changed, 61 insertions(+), 19 deletions(-) > > > > > > > > > > diff --git a/conf.c b/conf.c > > > > > index 84ae12b..353d0a5 100644 > > > > > --- a/conf.c > > > > > +++ b/conf.c > > > > > @@ -1049,7 +1049,8 @@ pasta_opts: > > > > > " --no-copy-addrs DEPRECATED:\n" > > > > > " Don't copy all addresses to= namespace\n" > > > > > " --ns-mac-addr ADDR Set MAC address on tap inte= rface\n" > > > > > - " --no-splice Disable inbound socket spli= cing\n"); > > > > > + " --no-splice Disable inbound socket spli= cing\n" > > > > > + " --no-tap Don't create tap device\n")= ; =20 > > > > > > > > I feel like this description can be improved, but I'm not exactly s= ure > > > > how, yet. =20 > > > > A few possible alternatives: > > > > - "Only enable loopback forwarding" =20 >=20 > Thanks, I will go with this and --splice-only. > > > > - "Loopback only from/to namespace" > > > > - call it --splice-only, and use one of the descriptions above > > > > - call it --loopback-only, and use one of the descriptions above > > =20 > > > > =20 > > > > > > > > > > passt_exit(status); > > > > > } > > > > > @@ -1451,6 +1452,7 @@ void conf(struct ctx *c, int argc, char **a= rgv) > > > > > {"no-ndp", no_argument, &c->no_ndp,= 1 }, > > > > > {"no-ra", no_argument, &c->no_ra, = 1 }, > > > > > {"no-splice", no_argument, &c->no_spli= ce, 1 }, > > > > > + {"no-tap", no_argument, &c->no_tap,= 1 }, > > > > > {"freebind", no_argument, &c->freebin= d, 1 }, > > > > > {"no-map-gw", no_argument, &no_map_gw,= 1 }, > > > > > {"ipv4-only", no_argument, NULL, = '4' }, > > > > > @@ -1947,8 +1949,11 @@ void conf(struct ctx *c, int argc, char **= argv) > > > > > } > > > > > } while (name !=3D -1); > > > > > > > > > > - if (c->mode !=3D MODE_PASTA) > > > > > + if (c->mode !=3D MODE_PASTA) { > > > > > c->no_splice =3D 1; > > > > > + if (c->no_tap) > > > > > + die("--no-tap is for pasta mode only"); > > > > > + } > > > > > > > > > > if (c->mode =3D=3D MODE_PASTA && !c->pasta_conf_ns) { > > > > > if (copy_routes_opt) > > > > > @@ -1957,6 +1962,25 @@ void conf(struct ctx *c, int argc, char **= argv) > > > > > die("--no-copy-addrs needs --config-net"); > > > > > } > > > > > > > > > > + if (c->mode =3D=3D MODE_PASTA && c->no_tap) { > > > > > + if (c->no_splice) > > > > > + die("--no-tap is incompatible with --no-spl= ice"); > > > > > + if (*c->ip4.ifname_out || *c->ip6.ifname_out) > > > > > + die("--no-tap is incompatible with --outbou= nd-if4/6"); > > > > > + if (*c->pasta_ifn) > > > > > + die("--no-tap is incompatible with --ns-ifn= ame"); > > > > > + if (*c->guest_mac) > > > > > + die("--no-tap is incompatible with --ns-mac= -addr"); =20 > > > > > > > > These all make sense. It might also make sense to exclude the -i > > > > option - setting a template interface also makes no sense in --no-t= ap > > > > mode. =20 > > > > > > Sure, I can add an if condition with if4 (as if4=3Dif6 in that case).= =20 > > > > =20 > > > > > + if (c->pasta_conf_ns) > > > > > + die("--no-tap is incompatible with --config= -net"); =20 > > > > > > > > I don't think this is right. We still can and should bring up 'lo'= in > > > > the --no-tap case. =20 > > > > > > I see your point, but seems c->pasta_conf_ns is only used for tap as > > > https://passt.top/passt/tree/pasta.c#n328, 'lo' is configured before > > > that line. =20 > > > > Right, and the reason is that there are basic bits of functionality > > (probing pipe sizes if I recall correctly, or anyway probing for some > > kind of capability) that need the loopback interface to be up. > > > > On the other hand, checks we're adding here are kind of fragile because > > we'll add other options in the future and probably forget to check > > which ones are incompatible, so I would try a slightly different > > approach: only check the options that are *obviously* conflicting with > > --no-tap. > > > > That is, the main thing "--config-net" does is to "Configure networking > > in the namespace", which we still do with "--no-tap". =20 >=20 > I added that because I thought --config-net is for tap only (as lo is > configured always), and there is no tap for this mode. I can remove > it, it still works without it. If it's harmless, I would just pick what's simpler for the implementation. For users it should be exactly the same: - slight advantage of allowing it: no need to edit the command line if one specified both by mistake - slight disadvantage of disallowing it: users might try to do something with it that won't really happen (but I guess it's unlikely) > > Now, I see that making sure c->pasta_conf_ns is false saves you checks > > elsewhere in the implementation, which is, I think, a good reason to > > have this check here. > > > > But in general we don't need to exclude all the possible options that > > make no sense with --no-tap. We don't really confuse users if we allow > > them (or, at least, some of them). =20 >=20 > I see. From a tester's perspective, we used to uncover a few bugs by > combining certain options in different ways. In this case, we don't know in which category those bugs might be: - *added* by allowing conflicting options (bad) - *discovered* by allowing conflicting options (good) - *not discovered* by not allowing conflicting options (bad, but not as bad) ...maybe others? > I feel it's more > user-friendly to explicitly state what is unsupported and what will be > ignored, although this is not a strong preference. I can update with > only excluding obvious ones. I think it's relevant if there are subtle combinations that are not actually working but they might look like it. Other than that, it *might* be more user-friendly to leave users as much choice as possible, because: 1. you don't need to re-type things if you obviously added an option that didn't make sense (especially relevant if you use the reverse-search function in a shell) 2. some options are set in integrations (Podman, rootlesskit/moby), for example --config-net. Let's say you want to try things out with Podman and --splice-only: --config-net doesn't make sense in that case, but Podman sets it regardless. So if you let pasta start with both, you can try things out without rebuilding and reinstalling, otherwise you have to rebuild and reinstall, but there's no added value, it's just us being picky. --=20 Stefano