[unnah]

Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?

[rwmj]

SLIRP is a clever tool that turns network traffic (raw IP frames on one side) into connect(2), read, write etc system calls on the other side. eg. If it sees a virtual machine is making a connection by sending a TCP SYN packet, it will on one side turn that into a connect(2) system call, and on the other side send back the appropriate TCP packets to complete the connection. It also does ARP, DNS, etc. If you think of a kernel as something that turns socket system calls into packets, then SLIRP is the opposite.

SLIRP is mainly useful when you don't have (or don't want) root permissions to send raw packets. I may be one of the few people here to have used SLIRP back in the early 90s for its original purpose: You have dial up access to a shared SunOS terminal login, how do you turn that into a full network connection for your local Linux PC? SLIRP (+ expect, SLIP and some scripting) solved this exact problem.

Passt (https://passt.top/passt/about/) is a more modern replacement for SLIRP that amongst other things fully supports IPv6 and is more secure architecturally (runs in a separate process, uses modern Linux mechanisms for isolation etc). There was a talk about it here: https://kvmforum2022.sched.com/event/15jJY/slirp-is-dead-lon...

This pull request is using Pasta which is something on top of Passt that does something with network namespaces which I'm not entirely clear on, but some docs here: https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstr...

[jasonjayr]

> I may be one of the few people here to have used SLIRP back in the early 90s for its original purpose

While I was still in college in 1999 -- I figured out how to pair a local ppp device with SLIRP on the Sun machines we had shell access on over ssh, enabling me to bounce internet access through our CS network, which got access to a few things we couldn't directly access from our dorms.

Later in my career I learned about the TCP-over-TCP meltdown effect, which explained why I had to restart it every once in a while.

Good times :)

[anderspitman]

I have a project that relies on user mode networking. passt is a very welcome development. Really hoping it supports Windows QEMU hosts at some point.

[bonzini]

Very difficult, it's not portable so it would be basically a rewrite. I read that similar APIs are present in FreeBSD, but at least it's POSIX-based so that does not really say anything about the complexity of a Windows port.

Anyhow, the presentation mentioned above explains which Linux extensions are needed.

[sbrivio]

You might be right, but I hope you're not. :)

I had a look at Winsock documentation a while ago, that doesn't look so bad in terms of what we need. See also: https://lore.kernel.org/qemu-devel/20220919232441.661eda8d@e.... Replacing epoll might be messy, though.

[sascha_sl]

Because you want containers to be able to allocate ports that are already in use on your host. Or at least you don't want that to be a source of errors.

[sbrivio]

On top of that, you usually want to isolate the container workload with an observable network abstraction instead of granting it full (albeit non-root) access to host network facilities (including sockets).

See https://medium.com/nttlabs/dont-use-host-network-namespace-f... for just an example of what can go wrong otherwise.