Unclear usage podman and slirp4netns

[gerritbinnenmars]

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind feature

Description

Steps to reproduce the issue:

1. terminal 1: maintain@localhost:~/podman$ podman run -it --rm --net=slirp4netns --name=serv localhost/iperf3 -s

---

Server listening on 5201

2.terminal 2: ps -ef
maintain 15164 5154 0 22:07 pts/0 00:00:00 podman run -it --rm --net=slirp4netns --name=serv localhost/iperf3 -s
maintain 15175 15164 4 22:07 pts/0 00:00:00 podman run -it --rm --net=slirp4netns --name=serv localhost/iperf3 -s
maintain 15209 1729 0 22:07 ? 00:00:00 /usr/libexec/podman/conmon -c b0ad2a9c698949413c1ae81c775e27347542a473cf294bf97500bc9
maintain 15219 15209 0 22:07 pts/0 00:00:00 iperf3 -s
maintain 15230 15175 0 22:07 pts/0 00:00:00 /usr/bin/slirp4netns -c -e 3 -r 4 15219 tap0

3. terminal 2:
   maintain@localhost:~/podman$ podman run -it --rm --net=slirp4netns --name=clnt localhost/iperf3 -c localhost
   iperf3: error - unable to connect to server: Connection refused

Describe the results you received:
The same result occurs when -c 127.0.0.1 is used
The same result occurs when both containers are placed in a pod
It works when --net=host is used

Describe the results you expected:
It is unclear how it should work. When starting the client with --entrypoint=/bin/ip and argument a, the tap interface is visible. Do both containers get a tap interface with ip address 10.0.2.100?

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:
maintain@localhost:~/podman$ podman version
Version: 0.8.3
Go Version: go1.9.7
OS/Arch: linux/amd64

Output of podman info:
maintain@localhost:~/podman$ podman info
host:
Conmon:
package: podman-0.8.3-1.git9d09a4d.fc27.x86_64
path: /usr/libexec/podman/conmon
version: 'conmon version 1.12.0-dev, commit: de446bb013621a297d524e5eeddf10635f43d2f0'
MemFree: 2509205504
MemTotal: 8296845312
OCIRuntime:
package: runc-1.0.0-36.gitad0f525.fc27.x86_64
path: /usr/bin/runc
version: |-
runc version 1.0.0-rc5+dev
spec: 1.0.0
SwapFree: 8300523520
SwapTotal: 8300523520
arch: amd64
cpus: 8
hostname: localhost.localdomain
kernel: 4.13.9-300.fc27.x86_64
os: linux
uptime: 15h 0m 9.97s (Approximately 0.62 days)
insecure registries:
registries: []
registries:
registries:

• docker.io
• registry.fedoraproject.org
• registry.access.redhat.com
  store:
  ContainerStore:
  number: 1
  GraphDriverName: vfs
  GraphOptions: []
  GraphRoot: /home/maintain/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
  number: 4
  RunRoot: /run/user/1000/run

Additional environment details (AWS, VirtualBox, physical, etc.):
Bare metal with fedora 27

[mheon]

@giuseppe PTAL

[AkihiroSuda]

I haven't looked into the podman code, but probably each of podman run --net=slirp4netns invocations creates a dedicated slirp4netns?

[giuseppe]

you don't need to specify --net=slirp4netns, it is used automatically for rootless containers.

Every time a new network namespace is created, slirp4netns is used internally to forward the data to the host namespace. A new network is created for each new container/pod. The slirp4nets network is not accessible from the host, as an unprivileged process has no way to change the routing for the host namespace.

Once slirp4netns will support port forwarding, it will be possible to redirect a single port (-p) from the host to the process inside the network namespace.

[rhatdan]

Can you modify the man page with this information to satisfy this issue?

[gerritbinnenmars]

Hello, I already tried the suggestion of leaving out --net option and it is correct that it also uses slirp4netns but the problem remains the same. How can two containers be connected. For the client I tried three addresses: 127.0.0.1, localhost and 10.0.2.100 I agree with Akihiro Suda because it seems every containers gets the 10.0.2.100 address. 1. Thanks for the quick responses!

…

On Fri, Sep 14, 2018 at 1:40 PM Daniel J Walsh ***@***.***> wrote: Can you modify the man page with this information to satisfy this issue? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1453 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHvFa1ZdEMcuJgrPy70syaCNeQh9pEniks5ua5WWgaJpZM4WmGCn> .

[AkihiroSuda]

Running 2nd container --net=container:1st-container-id SHOULD work? (If implemented)

[gerritbinnenmars]

Seems not implemented?

Error indication: error reading container (probably exited) json message: EOF

[gerritbinnenmars]

podman inspect on the client code shows:
HostConfig {
NetworkMode: container:
...

[mheon]

I think rootless isn't able to join the userns of the first container to successfully grab it's network namespace yet

[gerritbinnenmars]

So nothing I can do right now? I tried putting both containers in the same pod, but also then it is not possible to get it going using localhost.

[giuseppe]

@gerritbinnenmars I've opened a PR to support this use case as well:

#1507

[gerritbinnenmars]

Thanks

[hlev]

Just a sidenote, but when leaving --net=slirp4netns off, the rootless container will end up in "NetworkMode": "bridge" on my version

# Fedora 27
$ podman version
Version:       0.8.3
Go Version:    go1.9.7
OS/Arch:       linux/amd64

[baude]

For the record, we stopped building on F27 in August because the dependancies were getting too difficult to maintain. Your observation is no longer the case with F28/F29.

[hlev]

It still is the case with F28. slirp4netns is started, the interface tap0 in the container is created, and assigned an IP, but podman inspect still shows "NetworkMode": "bridge"

Version:       0.10.1.3
Go Version:    go1.10.4
OS/Arch:       linux/amd64

Not an issue per se at the moment, just for the record.

[rhatdan]

@giuseppe WDYT?

[TomasTomecek]

I actually have a different problem, but related. When I run a rootless container, there are no metadata for networking in the inspect output:

        "NetworkSettings": {                                           
            "Bridge": "",                                                                                                                    
            "SandboxID": "",                 
            "HairpinMode": false,     
            "LinkLocalIPv6Address": "",                                  
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": [],                                     
            "SandboxKey": "",                                       
            "SecondaryIPAddresses": null,                                
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",                              
            "Gateway": "",       
            "GlobalIPv6Address": "",       
            "GlobalIPv6PrefixLen": 0,                                                    
            "IPAddress": "",                    
            "IPPrefixLen": 0,           
            "IPv6Gateway": "",                                                                                                                                                                                     
            "MacAddress": ""                                                     
        },

As @hlev pointed out, the NetworkMode is set to bridge.

Is this expected? Am I able to access the network of the rootless container from my host?

[mheon]

Changing inspect to note if we're using slirp4netns is probably simple. I don't think the remaining fields will populate though - we don't have a dedicated container IP address, no ports can be forwarded, etc. @giuseppe can you confirm?

[giuseppe]

We have a RFE on how we handle slirp4netns (#1733), if we go that way then we will have more information to display. That RFE must still be discussed/investigated (personally, I am not really convinced about having a single process handling all the rootless containers) but at the moment all we can really do is to show it is using slirp4netns instead of bridge

[giuseppe]

started working on it: #1849