Re: DOSemu networking made easy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 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.

To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux Console]     [Linux Audio]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Camping]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Samba]     [Linux Media]     [Fedora Users]

  Powered by Linux