pasta impossible to copy multiple host interfaces

[jerome59]

Issue Description

I'm trying to start a rootless container with pasta and I'd like to mount multiple network interfaces into my container.
Today I'm only able to mount a single interface like that :

usr/bin/podman run --name test_pasta --network pasta:-i,ens33 -d --publish 8080:8080 ghcr.io/oracle/oraclelinux9-nginx:1.20

I tried to set multiple interfaces in the following ways :

1. multiple interfaces in the pasta parameters :

/usr/bin/podman run --name test_pasta --network pasta:-i,ens33,-i,ens37 -d --publish 8080:8080 ghcr.io/oracle/oraclelinux9-nginx:1.20

In my container, only the last interface (ens37) is mounted. ens33 is ignored and does not exist.

2. Trying to join a second pasta network :

/usr/bin/podman run --name test_pasta --network pasta:-i,ens33 --network pasta:-i,ens37 -d --publish 8080:8080 ghcr.io/oracle/oraclelinux9-nginx:1.20

-> I get the error :

Error: cannot set multiple networks without bridge network mode, selected mode pasta: invalid argument

How can I mount multiple interfaces with pasta into my containers ?

Steps to reproduce the issue

Steps to reproduce the issue

1. Have a host with multiple available interfaces (ip a command should list multiple interfaces)
2. Try to start a rootless container with a pasta network and refers multiple interface. Either with --network pasta:-i,ens33,-i,ens37 or --network pasta:-i,ens33 --network pasta:-i,ens37
3. Check that the container does not have the 2 interfaces with podman exec -it test_pasta ip a

Describe the results you received

1. In case of passing multiple interfaces into the pasta arguments usr/bin/podman run --name test_pasta --network pasta:-i,ens33,-i,ens37 -d --publish 8080:8080 ghcr.io/oracle/oraclelinux9-nginx:1.20 , then podman exec -it test_pasta ip a returns :

1: lo: <LOOPBACK,UP,LOWER_UP> 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 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 3e:98:42:bf:d2:e4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.19.132/24 brd 192.168.19.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::3c98:42ff:febf:d2e4/64 scope link tentative 
       valid_lft forever preferred_lft forever

2. In case of passing 2 pasta network /usr/bin/podman run --name test_pasta --network pasta:-i,ens33 --network pasta:-i,ens37 -d --publish 8080:8080 ghcr.io/oracle/oraclelinux9-nginx:1.20 then I get the error

Error: cannot set multiple networks without bridge network mode, selected mode pasta: invalid argument

Describe the results you expected

I was expecting to have both interfaces available into my container.
The command podman exec -it test_pasta ip a should have returned something like:

1: lo: <LOOPBACK,UP,LOWER_UP> 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 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 3e:98:42:bf:d2:e4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.19.132/24 brd 192.168.19.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::3c98:42ff:febf:d2e4/64 scope link tentative 
       valid_lft forever preferred_lft forever
3: ens37: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:ae:15:66 brd ff:ff:ff:ff:ff:ff
    altname enp2s5
    altname enx000c29ae1566
    inet 192.168.19.133/24 brd 192.168.19.255 scope global ens37
       valid_lft forever preferred_lft forever

podman info output

host:
  arch: amd64
  buildahVersion: 1.38.1
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon_2.1.12-3_amd64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.12, commit: unknown'
  cpuUtilization:
    idlePercent: 98.58
    systemPercent: 0.41
    userPercent: 1.01
  cpus: 2
  databaseBackend: sqlite
  distribution:
    codename: trixie
    distribution: debian
    version: unknown
  eventLogger: journald
  freeLocks: 2046
  hostname: debian
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.1.0-31-amd64
  linkmode: dynamic
  logDriver: journald
  memFree: 7938998272
  memTotal: 12505976832
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns_1.12.2-2_amd64
      path: /usr/lib/podman/aardvark-dns
      version: aardvark-dns 1.12.2
    package: netavark_1.12.1-9_amd64
    path: /usr/lib/podman/netavark
    version: netavark 1.12.1
  ociRuntime:
    name: crun
    package: crun_1.18.2-1_amd64
    path: /usr/bin/crun
    version: |-
      crun version 1.18.2
      commit: 00ab38af875ddd0d1a8226addda52e1de18339b5
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt_0.0~git20250121.4f2c8e7-1_amd64
    version: |
      pasta 0.0~git20250121.4f2c8e7-1
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns_1.2.1-1+b1_amd64
    version: |-
      slirp4netns version 1.2.1
      commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 1022357504
  swapTotal: 1022357504
  uptime: 5h 17m 51.00s (Approximately 0.21 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries: {}
store:
  configFile: /home/jerome/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 1
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/jerome/.local/share/containers/storage
  graphRootAllocated: 51510796288
  graphRootUsed: 18072363008
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 27
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/jerome/.local/share/containers/storage/volumes
version:
  APIVersion: 5.3.2
  Built: 1737979078
  BuiltTime: Mon Jan 27 12:57:58 2025
  GitCommit: ""
  GoVersion: go1.23.5
  Os: linux
  OsArch: linux/amd64
  Version: 5.3.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

No response

Additional information

No response

[Luap99]

pasta is a network mode not a regular network (compare podman network ls)

And you can only have one network mode per container so one pasta process, so something like --network pasta --network pasta is never supposed to work for podman.

--network pasta:-i,ens33,-i,ens37

Now that passes the same argument twice for an option that excepts exactly one argument and per normal command line parsing behavior it means it will use only the latest value.
cc @sbrivio-rh

Overall this is not a bug and the behavior works is exactly as designed, can you explain your use case more. We could consider this a feature request.

[sbrivio-rh]

Interesting, it's the first time I see this kind of request, so, yes, I'm also curious about the use case. Maybe:

In my container, only the last interface (ens37) is mounted

...this comes from the expectation that interfaces are "mounted". I never thought of it like that. ;) And it's not really the case, but it's also a somewhat intuitive way to see things, I guess.

Anyway, we're pretty far from supporting that. We have another feature request that's very slightly related, https://bugs.passt.top/show_bug.cgi?id=47, but it's obviously different in that, here, we're talking about multiple interfaces in the container, not just one with multiple addresses / routes (which might be copied from several interfaces).

There might be a workaround, by the way. I guess you could run one additional instance of pasta manually and make it join the network namespace of your Podman container. I don't have instructions ready, but it's essentially something like this:

    $ unshare -rUn # first terminal
    # echo $$
    4137013

    $ pasta -f --config-net -I pasta0 4137013 # second terminal
    [...]

    $ pasta -f --config-net -I pasta1 4137013 # third terminal
    [...]

and...:

# ip link show # first terminal again
1: lo: <LOOPBACK,UP,LOWER_UP> 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
3: pasta0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 2a:eb:48:73:9a:d0 brd ff:ff:ff:ff:ff:ff
4: pasta1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether ee:71:d5:e4:de:5e brd ff:ff:ff:ff:ff:ff

...applied / transposed to Podman containers.

[jerome59]

The use cases concerns industrial edge devices. We need to run software which need to have a fine control on which Ethernet interfaces they send data. Moreover the IP of the interface which is into the container should be the same as the one on the host.

A simple example could be that a software need to interact with 3 Ethernet interfaces :

• data of type A should be sent on eth0
• if eth0 is down (cable problem, unplug...) data of type A should be sent on eth1
• all other type of data should be sent on eth2

That means that when we try to have that software into a podman container, we need to be able to see those interfaces into the containers. That's why I was asking how we can get access to multiple interfaces in a rootless container. Pasta provides us a way to see 1 interface of the host, but we need multiple.

[sbrivio-rh]

That means that when we try to have that software into a podman container, we need to be able to see those interfaces into the containers. That's why I was asking how we can get access to multiple interfaces in a rootless container. Pasta provides us a way to see 1 interface of the host, but we need multiple.

Interesting, thanks for the details. We have some vaguely related development planned for pasta itself in the long term, and I'll keep this scenario in mind.

Meanwhile, I wonder if might eventually make sense for Podman to handle -net parameters as "adding a network" rather than "setting the network mode". It's probably not as simple as handling this configuration-wise as it has a few architectural implications, but perhaps they are solvable.

[Luap99]

Meanwhile, I wonder if might eventually make sense for Podman to handle -net parameters as "adding a network" rather than "setting the network mode". It's probably not as simple as handling this configuration-wise as it has a few architectural implications, but perhaps they are solvable.

The network "mode" concept is quite old but it still make sense. While it would be rather easy to just have two pasta processes running on the same netns or even when bridge network and one pasta that all quickly falls apart when one would try to mix things like container: ns:, host modes which simply would not be compatible.

Now one might say we can just allow the network modes that would work but once you consider our port forwarding logic you quickly realize that is somewhat impossible to solve. podman run -p 8080:80 --network pasta --network pasta would then result in two processes trying to bind the same host ports which clearly won't work. And mixing that with bridge where we use rootlessport process would make things unmanageable.

So the only way would to have working ports is to only have one network mode which can handle ports correctly. Otherwise you end up with a scenario where the ports must be specified per network which is simply not how the CLI or API is designed. Yes it would be possible with pasta as the ports can be given as raw cli options for it but not for the other modes.

And then there is the obvious problem that our container config structure and network code is not setup for something like that and it would need major rewrites to allow such things. To me this is really not worth the effort on the podman side at least.
cc @mheon

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[swankun]

Just wanted to add another voice here that we have a similar use case as the OP (multiple industrial cameras), also unable achieve the desired network configurations.

[sbrivio-rh]

@swankun that sounds great, looking forward to contributions!