hatestheinternet
post image is Old Modem Front by Rex Roof

Host Networking

Now that we've got TCP/IP set up and running in DOS, we have to rig up a way to make it talk to the outside world.  I'm shaky on how to do this on Windows because I've only done it once, so YMMV, but the Linux instructions should work.  The tap process will be automated in Linux later on through our BBS startup script, Windows we'll just leave it there.

Host Setup: Windows

To make this thing work seamlessly in Windows, you're going to need a TAP driver.  The one I recommend is TAP-Win32 V8 from the coLinux project.  Installation is a piece of cake: Extract the ZIP you downloaded, navigate there in a command prompt and type tapcontrol install oemwin2k.inf tap0801co.  A dialog warning that the developers didn't pay Microsoft's bribe will show up, but tell it to "Continue Anyway".

Find a Network Connections icon, right click on it and go to "Properties".  When the window opens, you should have a new connection type claiming it's a "TAP-Win32 Adapter V8 (coLinux)".  The easiest thing to do at this hold control, click on the new Local Area Connection, then the Local Area Connection you use to access the internet.  Right click and go to "Bridge Connections".  A bunch of crap will happen and you'll loose connectivity for a second, but when things come back traffic will be able to flow freely to and from the virtual machine's "connection".

Before bridging the connections, I'd highly recommend you rename whatever Local Area Connection name was assigned to the TAP adapter to "tap0" to make the rest of the networking instructions easier to follow.

Also, before closing your command prompt do a quick ipconfig /all to see what the gateway, netmask, etc settings for your bridge are.  You'll need to edit your wattcp.cfg to match these values.

Host Setup: Linux

Host setup for Linux is slightly different than host set for Windows.  By "different", I mean a lot harder.  The easiest thing to do is type tunctl --help.  If the command's not found, you need to track down the tun module for your kernel and install it.  I can't help you with this, but if you check the documentation for your distribution and version (or just google), something will come up.  I can tell you on Slackware it was as easy as make modules && make modules_install.

After you have the modules you need installed and tested, you'll need to allow whatever unprivileged user you decide to run qemu as access to tunctl through the sudo command, so log in as root, type visudo and add the following line:

{your user name} ALL=(root) NOPASSWD: /usr/bin/tunctl

Now type exit and go back to your regular user (You weren't going to run this as root, were you?  Please say no.)  Now all that's left is to grab a TAP device for us to use, so:

$ sudo tunctl -b -u {your_user_name}

If the command is successful, it's output will be the name of the TAP device assigned to your user.  In most cases this will be tap0 so I'll use that for the rest of this section.

Please note that you're responsible for configuring the tap interface so far as IPs go.  You can bridge it with another interface, I have a bbs start/stop script (more on that later) that handles assigning IPs based on interface number.

Final Touches: QEmu

Now that we have the host ready to roll, we have to tell qemu how the host is going to provide it with it's link to the outside world.  To do this, we add the following to our qemu command line:

-net nic -net tap,ifname=tap0

-net nic tells qemu we want to create a new network card, -net tap,ifname=tap0 tells it this new NIC will use TAP and the name of the interface is tap0.  In Linux, this will be whatever the tunctl command returned, in Windows it will be whatever you named the interface in the host setup.  For Windows, I'd recommend avoiding spaces in the name you use here.

So, when we put this section together with everything else we've done, our qemu command line now looks like this:

qemu -vnc :24100 -hda bbs.hd -m 8 -net nic -net tap,ifname=tap0

So, that's pretty much it.  We've configured our IP addresses and we're reasonably certain our TCP/IP settings are correct, but who needs to bother with stuff like testing when you're so close to the brass ring?