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
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
