Re: DOSemu networking made easy

[Mateusz Viste <mateusz@viste-family.net>]

On 06/24/2013 05:00 PM, Stas Sergeev wrote:
> So basically the static DNS and static gateway are only
> needed to allow the configuration without DHCP? Maybe
> it is not worth the troubles, and only the DHCP-based
> configuration can be left? I mean if you (or anyone else)
> is going to port that inside dosemu, that may be easier.
> But then, remove the static configuration, and suddenly
> not too much is left at all. :)

The static configuration is the base of the whole solution - that's what 
makes it possible for DOSemu to think that it's in a real network. The 
'fake' DNS address, however, is just a redirection to the DNS server 
used by the host machine (it's not adding complexity at all, since it is 
taken care of by SLIRP, so I had only to implement a virtual ARP proxy 
for the 10.0.2.3 IP to make it work).

The DHCP service is just an additional module I wrote later, to avoid 
having to configure the 10.0.2.x adresses in DOSemu by hand.

> Could you please explain a little more how NAT+slirp work
> in that scenario? What was the task of slirp, is there no
> other way to deal with the raw IP packets?

In fact, it's not real NAT (nor PAT, nor anything similar). SLiRP is an 
astonishing piece of code, that accepts IP packets via a SLIP tunnel, 
and emulates a TCP/UDP/IP stack using normal, unpriviliged sockets on 
the host. In this regard, it acts like a proxy (but at a quite low level 
- TCP/UDP). Initially that's what I wanted taprouter to do, I even 
implemented a functional UDP proxy solution, but TCP is way more 
complicated, so instead of spending months on implementing my own TCP 
stack emulator, I used SLIRP as a backend, who does the job perfectly.

Now, why does SLiRP do such complicated things, instead of performing a 
(seemingly) simple IPsrc/PortSrc substitution on a per-packet basis?
Simply because it's dangerous (SLiRP could reuse a src port that is 
already used by the host's kernel, and thus trash an existing 
connection), and also because it would require the use of 'raw' sockets 
(or alternatively 'packet' sockets), which are not accessible to 
unpriviliged processes (so the user would have to run slirp as root, 
which many users - including me - won't agree too).

The role of taprouter is therefore to handle all the ethernet (L2) 
communication with DOSemu via TAP interfaces, intercept some packets 
(notably ARP requests, as well as UDP datagrams that transport 
BOOTP/DHCP requests), and encapsulate all other packets into SLIP 
messages, handing them to SLiRP, who does all the backend magic. And of 
course, taprouter have to do the work in the opposite direction as well 
- ie. listening for SLIP messages from SLiRP, decapsulating IP packets 
from them, checking who they are targeted to, using its ARP cache to 
encapsulate them into an Ethernet II structure with the correct dst MAC, 
and send them over the bridge. Plus some minor sanitazing stuff like 
dealing with broadcasts, using SLIRP only for non-local destinations, etc.

It would be really cool to have this incorporated into DOSemu, so for 
example a network configuration could be something like:

   $_pktdriver = (on)
   $_vnet = "slirp"
   $_netdev = "/usr/bin/slirp"

And such configuration would provide working network connectivity in any 
situation, without the user having to care about anything (as long as 
the host would have network itself).

I even looked at DOSemu source code, and locating the point where DOSemu 
opens the TAP interface wasn't a big deal, and it would be easy to 
implement any other alternative channel there, but I could not locate 
the code where DOSemu sends/recv ethernet frames into/from the TAP. If 
anybody tells me where in the code this happens, I might try to look 
further.

cheers,
Mateusz