Re: [PATCH] conf, pasta: Add --no-tap option

On Wed, Jan 14, 2026 at 7:34 AM Stefano Brivio wrote:

On Tue, 13 Jan 2026 19:20:47 +0800 Yumei Huang wrote:

...

On Sun, Jan 11, 2026 at 2:12 AM Stefano Brivio wrote:

...

On Mon, 29 Dec 2025 17:55:58 +0800 Yumei Huang wrote:

...

This patch introduces a mode where we only forward loopback connections and traffic between two namespaces (via the loopback interface, 'lo'), without a tap device.

With this, podman can support forwarding ::1 in custom networks when using rootlesskit for forwarding ports.

In --no-tap mode, --host-lo-to-ns-lo, --no-icmp and --no-ra is automatically enabled. Options requiring a tap device (--ns-ifname, --ns-mac-addr, --config-net, --outbound-if4/6) are rejected.

Link: https://bugs.passt.top/show_bug.cgi?id=149 Signed-off-by: Yumei Huang --- 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 interface\n" - " --no-splice Disable inbound socket splicing\n"); + " --no-splice Disable inbound socket splicing\n" + " --no-tap Don't create tap device\n");

passt_exit(status); } @@ -1451,6 +1452,7 @@ void conf(struct ctx *c, int argc, char **argv) {"no-ndp", no_argument, &c->no_ndp, 1 }, {"no-ra", no_argument, &c->no_ra, 1 }, {"no-splice", no_argument, &c->no_splice, 1 }, + {"no-tap", no_argument, &c->no_tap, 1 }, {"freebind", no_argument, &c->freebind, 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 != -1);

- if (c->mode != MODE_PASTA) + if (c->mode != MODE_PASTA) { c->no_splice = 1; + if (c->no_tap) + die("--no-tap is for pasta mode only"); + }

if (c->mode == 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 == MODE_PASTA && c->no_tap) { + if (c->no_splice) + die("--no-tap is incompatible with --no-splice");

I'm not sure if you need this for other reasons, but as long as it's called --no-tap, it's not really incompatible with --no-splice.

I will update it to --splice-only

...

Maybe users just want to get a disconnected namespace for whatever reason ('pasta' is shorter to type than 'unshare -rUn').

...

+ if (*c->ip4.ifname_out || *c->ip6.ifname_out) + die("--no-tap is incompatible with --outbound-if4/6"); + if (*c->pasta_ifn) + die("--no-tap is incompatible with --ns-ifname"); + if (*c->guest_mac) + die("--no-tap is incompatible with --ns-mac-addr"); + if (c->pasta_conf_ns) + die("--no-tap is incompatible with --config-net");

I guess all these checks are to save some checks later, which looks like a good reason to have them here.

If not, though, I don't think we *really* need to tell the user that --ns-ifname will be ignored with --no-tap.

One thing that might confuse users, though, is this:

$ ./pasta --no-tap --mtu 1500 -- ip l 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

or even this:

$ ./pasta --no-tap -a 192.0.2.1 -- ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host proto kernel_lo valid_lft forever preferred_lft forever

but I would rather *not* add conditions and checks for those even if there's a *slight* potential for confusion, otherwise this becomes really long. And it's really not worth it, I think.

Then I guess we only need the c->no_splice check, right?

...maybe? About *needing*, yes, I guess so, but if other checks save more checks later, I would keep them.

...

...

...

+ + c->host_lo_to_ns_lo = 1; + c->no_icmp = 1; + c->no_ra = 1; + c->no_dns = 1; + c->no_dns_search = 1; + } + if (!ifi4 && *c->ip4.ifname_out) ifi4 = if_nametoindex(c->ip4.ifname_out);

@@ -1980,9 +2004,9 @@ void conf(struct ctx *c, int argc, char **argv) log_conf_parsed = true; /* Stop printing everything */

nl_sock_init(c, false); - if (!v6_only) + if (!v6_only && !c->no_tap) c->ifi4 = conf_ip4(ifi4, &c->ip4); - if (!v4_only) + if (!v4_only && !c->no_tap) c->ifi6 = conf_ip6(ifi6, &c->ip6);

if (c->ifi4 && c->mtu < IPV4_MIN_MTU) { @@ -1998,30 +2022,32 @@ void conf(struct ctx *c, int argc, char **argv) (*c->ip6.ifname_out && !c->ifi6)) die("External interface not usable");

- if (!c->ifi4 && !c->ifi6 && !*c->pasta_ifn) { + if (!c->ifi4 && !c->ifi6 && !*c->pasta_ifn && !c->no_tap) {

You already checked that !*c->pasta_ifn above.

I guess the check above (aka. if (*c->pasta_ifn && c->no_tap)) doesn't affect this one? If c->pasta_ifn is assigned, we won't come to the check !c->no_tap here. Otherwise, we do need to check !c->no_tap.

Right, but you don't care about resetting c->pasta_ifn to the default value if !c->no_tap, because in that case you know that c->pasta_ifn wasn't set, so you can happily override it.

I'm not sure I fully understand it. If !c->no_tap, the condition is the same as before without this patch, which is to not reset it if it's specified in cmd line. We won't know if c->pasta_ifn is set until this check, do we?

I guess, at least, I haven't thoroughly checked what might happen later with it.

...

...

...

strncpy(c->pasta_ifn, pasta_default_ifn, sizeof(c->pasta_ifn) - 1); }

if (!c->ifi4 && !v6_only) { - info("IPv4: no external interface as template, use local mode"); - - conf_ip4_local(&c->ip4); + if (!c->no_tap) { + info("IPv4: no external interface as template, use local mode"); + conf_ip4_local(&c->ip4); + } c->ifi4 = -1; }

if (!c->ifi6 && !v4_only) { - info("IPv6: no external interface as template, use local mode"); - - conf_ip6_local(&c->ip6); + if (!c->no_tap) { + info("IPv6: no external interface as template, use local mode"); + conf_ip6_local(&c->ip6); + } c->ifi6 = -1; }

- if (c->ifi4 && !no_map_gw && + if (c->ifi4 > 0 && !no_map_gw && IN4_IS_ADDR_UNSPECIFIED(&c->ip4.map_host_loopback)) c->ip4.map_host_loopback = c->ip4.guest_gw;

- if (c->ifi6 && !no_map_gw && + if (c->ifi6 > 0 && !no_map_gw && IN6_IS_ADDR_UNSPECIFIED(&c->ip6.map_host_loopback)) c->ip6.map_host_loopback = c->ip6.guest_gw;

@@ -2116,10 +2142,10 @@ void conf(struct ctx *c, int argc, char **argv) conf_ports(c, name, optarg, &c->udp.fwd_out); } while (name != -1);

- if (!c->ifi4) + if (c->ifi4 <= 0) c->no_dhcp = 1;

- if (!c->ifi6) { + if (c->ifi6 <= 0) { c->no_ndp = 1; c->no_dhcpv6 = 1; } else if (IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr)) { diff --git a/fwd.c b/fwd.c index 44a0e10..2f4a89a 100644 --- a/fwd.c +++ b/fwd.c @@ -780,6 +780,9 @@ uint8_t fwd_nat_from_host(const struct ctx *c, uint8_t proto, return PIF_SPLICE; }

+ if (c->no_tap) + return PIF_NONE; + if (!nat_inbound(c, &ini->eaddr, &tgt->oaddr)) { if (inany_v4(&ini->eaddr)) { if (IN4_IS_ADDR_UNSPECIFIED(&c->ip4.our_tap_addr)) diff --git a/passt.1 b/passt.1 index db0d662..2d643f7 100644 --- a/passt.1 +++ b/passt.1 @@ -755,6 +755,11 @@ Default is to let the tap driver build a pseudorandom hardware address. Disable the bypass path for inbound, local traffic. See the section \fBHandling of local traffic in pasta\fR in the \fBNOTES\fR for more details.

+.TP +.BR \-\-no-tap +Do not create a tap device in the namespace. In this mode, only local loopback +traffic between namespaces is forwarded using splice.

"Using splice" isn't really clear, and it's not entirely correct in the case of UDP: there's no splice() system call there, even if we call some UDP flows "spliced" for analogy with TCP.

Maybe just omit it, say:

[...] In this mode, \fIpasta\fR only forwards loopback traffic between namespaces.

Do you think we still need "Do not create a tap device in the namespace" after updating it to --splice-only?

Yes, I think so, because otherwise it might look like we create the tap device anyway, but discard all traffic from/to it.

-- Stefano

-- Thanks, Yumei Huang