QEMU and Slirp
This is an explanation of how Qemu's user mode networking works. It is written from the perspective of a Linux/GNU host and guest, though this should apply for all host and guest OS combinations.
Firstly, the name requires some explanation. When qemu was first written, it supported only one networking mode. This is the tuntap networking mode of QEMU. It can also be called the root networking mode of qemu, because it requires special permission from the OS in order to be able to run (usually as the root user, though it is possible to grant individual users the ability as well). The reason that this mode requires special permission to run is because tuntap mode creates a virtual ethernet device in the OS (the host OS to be precise), which is potential a security issue (if a rogue program had permission, it could create a virtual ethernet device and use it to forge ethernet packets and cause all kinds of havoc).
Security wasn't that big an issue to most qemu users of course. Those who had the ability to run qemu with tuntap networking also knew how to secure it, for the most part. The problem was that many qemu users didn't have permission in the first place - they didn't have root access. This caused a problem as qemu users who were unable to run in tuntap mode were unable to run qemu with internet access. The problem was solved by adding a second networking mode to qemu: this is known as User Mode Networking because a regular user with no special permissions is able to use it. That is a long name, so it is sometimes shorted to user networking or user-net (the latter comes from the command-line option used to activate this mode). It is also sometimes called slirp networking, though you will see this name more often in other project such as UML. The name slirp comes from the software that is used to implement networking.
Most qemu users do not use the word slirp for two reasons:
they don't know what slirp is or that its used in qemu
and
those that do know about slirp avoid calling it that because it tends to confuse new users.
It is not possible to explain how User Mode Networking works without explaining how slirp works. Slirp was an ancient program designed in the haydays long before the masses had commercialized ISPs (dialup or otherwise). In those long forgotten times, many college students had dialup access to their university computers (mainframes?) in the form of shell accounts. Basically, what this means is that they dial in, and they see a log in screen. They type in their login id and password, and they see a shell prompt. While this was good enough for running class account programs (a more modern example would be something like matlab), it was not very good for web browsing. Text-only browsers like lynx would have worked, but something like Netscape would not. Also, in order to access the internet at all (be it web surfing, checking email, or using usenet) the students had to use the programs installed on the university machines. They could not use their own software. Slirp was devised as a hack to fix this.
Slirp works by faking a SLIP connection. (SLIP is a predecessor to PPP, which is the standard dialup protocol most ISPs use today.) It works like this: the user dials in, logs into the account, and runs slirp. Then the user sets up his home computer to use a SLIP connection to access the internet, through the dialup connection. At this point, as far as the home computer is concerned, it is connected to the internet by SLIP. It doesn't notice that anything is amiss. On the other side of the dialup connection, slirp reads in SLIP packets. [How? Well, when slirp runs it stays connected to the terminal it is run from, which is normally a dialup modem. Basically, the SLIP packets are feed to slirp's standard input. slirp is able to reply by sending packets through its standard output in the same manner.] slirp runs as a normal user with no special privilidges, so it can't set up a real SLIP connection. Instead, it reads in SLIP packets and does a clever little trick: it analyzes the SLIP packets and performs the equivalent BSD socket operations. It then takes the response and creates a series of SLIP packets which embody that information. As far as the university computer is concerned, slirp is just another program. It doesn't do anything that lynx or telnet or ping doesn't do.
The details of how slirp does its magic are more complicated. However, if you understand that slirp is able to convert SLIP packets into socket calls and socket calls into SLIP packets, then you understand the basics of how it works. qemu uses the slirp code to do something similar, except that qemu converts between ethernet packets and socket calls, instead of SLIP packets (because qemu doesn't emulate a modem but a network card). As far as the host computer is concerned, qemu is just a regular program. And as far as the guest computer is concerned, it has full LAN and internet access through a NAT'ed firewall. qemu also adds a =redir option, which allows you to run servers. Basically, qemu binds itself to a specified port on the host OS, and forwards all traffic it receives to another port in the guest OS (after converting the socket call results into ethernet packets of course). As far as the host is concerned, qemu is just another server. As far as the guest is concerned, it is receiving traffic through port forwarding on the firewall.
Now, an in-depth explanation of how the slirp code in qemu does its magic.
See QEMU and network and http://qemu-buch.de/d/Netzwerkoptionen for further QEMU network related articles.
Back to FrontPage
Hosted by http://qemu-buch.de