mTCP Configuration

DHCP or Static - It's your choice!

Introduction

mTCP is a library that implements ARP, IP, UDP, TCP, DNS resolving and a few other useful features. Applications that use the mTCP library have common configuration requirements, mostly related to setting up TCP/IP addresses and telling the mTCP library code how to talk to the packet driver for your Ethernet card. This document explains how to setup the basic parameters for applications that use mTCP. Each individual application (like IRCjr) may have some additional setup that needs to be done.

General Hardware requirements:

8088 processor or better
Somewhere between 96KB and 128KB available RAM
Display: CGA, EGA, VGA or MDA
Supported Ethernet card

Software requirements:

DOS 2.0 or newer (DOS 3.3 or newer recommended)
Packet driver for your Ethernet card

Pre-requisites:

Your Ethernet hardware has to be installed and you should know what IRQ and port settings you have configured on the card.

Loading the packet driver

All mTCP applications interface to the Ethernet hardware through the packet driver for the Ethernet hardware. So before you run an mTCP program, you have to successfully load your packet driver.

The parameters on the packet drivers will vary but one that you will always have to provide is the software interrupt number that the packet driver is going to take control of. The software interrupt number is the address of the 'service' that the packet driver is going to provide to mTCP applications, and that service is the ability to send and receive packets on the Ethernet hardware.

Note that the software interrupt number has nothing to do with the configuration of the Ethernet hardware. The software interrupt number is assigned by you and you are telling the packet driver which software interrupt to use. Software interrupt numbers are usually in the range of 0x60 (hex) to 0x66 (hex). You need to pick one that is not in use already but since most DOS software does not these software interrupts 0x60 is usually available.

Here is an example showing an NE2000 clone card being loaded using the default I/O ports and IRQ3. It is also being told to use software interrupt 0x60:

ne2000
0x60 3

Here is another example featuring an older Western Digital 8003 card:

smc_wd
0x60 0x03 0x280 0xD000

In this example the software interrupt to use is 0x60, the IRQ is 3, the I/O ports start at 0x280, and the shared memory address for the RAM on the card is going to be located at 0xD000:0000 in memory.

Consult your packet driver documentation for options. The best place to find packet drivers for an Ethernet adapter is in the original drivers and software shipped with the card. A good place to find open source packet drivers is http://www.crynwr.com/ .

For a general discussion on packet drivers see the DOS Packet Drivers page.

Configuration Overview

All applications built using the mTCP library need to read some parameters when they start. The parameters tell the applications some very useful things, like what the IP address of the machine is, where the gateway is, and where the DNS nameserver is.

The parameters are read from a configuration file that the application looks for at startup. The path and name of the configuration file is specified by the 'MTCPCFG' environment variable which you need to set before the application starts. For example:

set MTCPCFG=c:\packet\tcp.cfg

What you put in the configuration file depends on how you are going to setup IP addresses for your machine. There are two possible paths:

Setup the machine using the mTCP DHCP client. When you run the mTCP DHCP client it will automatically try to setup the configuration file by talking to a DHCP server on your network. If you have a cable modem, DSL modem, or router on your network that assigns addresses to machines automatically then you can use this method.
Setup the machine by hand. You will provide a set of required IP addresses that describe your network. This is recommended for advanced users who understand their network.

Configuration using DHCP

Using the DHCP client to configure your machine is easier and it should work fine on modern networks where there a DHCP server. When you configure your network using the DHCP client you only need to have two parameters in the configuration file. One parameter tells the mTCP library what software interrupt the packet driver is listening on and the other parameter gives your machine a name.

Here is an example of a minimum configuration file for mTCP:

PACKETINT
0x60


HOSTNAME PCjr

That's it! To configure your machine follow the following steps:

Create the configuration file. Be sure to specify the same software interrupt number that you told the packet driver to use. Use your favorite text editor.
Set the MTCPCFG environment variable to point at your configuration file. It is a good practice to specify a full pathname - that way the configuration file can be found no matter what your current drive and directory are. Example:

set MTCPCFG=c:\packet\tcp.cfg
Run 'DHCP.EXE' from the mTCP programs. This is the DHCP client. It will read your configuration file to figure out how to talk to the packet driver, then try to talk to the DHCP server on your network. If all goes well it will tell you what address it was assigned by the DHCP server and it will update the mTCP configuration file with additional parameters that the other mTCP applications need.
Now you are setup to run any other mTCP application!

Here is a screenshot of the DHCP client running:

Note that you only have to run DHCP.EXE once in a while. The exact timing depends on your DHCP server, but a good rule of thumb is once a day before you start using mTCP applications. If your machine is acting strange and can't connect to other machines it will not hurt you to run DHCP.EXE again - the DHCP server might have dropped your machine due to a reset or a short lease time.

Configuring by Hand (Static addresses)

Use this method if you understand your network topology well and do not want to use DHCP.

When you configure your machine by hand you need to provide a few IP addresses and related information that the DHCP client would have automatically fetched for you. Don't worry, it's not hard. Here are the parameters that you need to include in the configuration file:

Parameter Name	Purpose	Required for Static Config	Required for DHCP
PACKETINT	This is the software interrupt number that the packet driver is listening on. This should match the software interrupt number that you told the packet driver to use.	Required	Required
IPADDR	IP address of this machine (eg: 192.168.2.3)	Required	DHCP fills this in
NETMASK	Network mask setting for your local area network (eg: 255.255.255.0)	Required	DHCP fills this in
GATEWAY	The IP address of your router (eg: 192.168.2.1) If you don't provide this or if you set it wrong you will not be able to communicate with machines that are not directly connected to your LAN.	Optional	DHCP fills this in
MTU	The MTU size for your Ethernet (typically 1500). This can have a big impact on file transfer performance - see the discussion below.	Optional	Optional - you provide
NAMESERVER	If you don't provide this or if you set it wrong you will not be able to convert machine names to IP addresses.	Optional	DHCP fills this in

Here is a sample configuration file:

PACKETINT
0x60

IPADDR 192.168.2.6

NETMASK 255.255.255.0

GATEWAY 192.168.2.1

NAMESERVER 68.115.71.53

MTU 1500

Note that these are sample values only, and that the last three lines were optional. You must adjust all of the parameters for your particular network.

Other Configuration Parameters

The mTCP configuration file can be used for more than network configuration. Other mTCP applications will read it to look for their configuration settings.

In general, you can put anything you want in the configuration file. Lines that the DHCP client don't understand will be left unaltered. Here are the rules:

Blank lines are ok
Lines should never exceed 75 characters
If you use the DHCP client, it will rewrite the configuration file and write new values for IPADDR, NETMASK, GATEWAY, and NAMESERVER. The previous values will be lost, but no other lines in the file will be altered.
Other mTCP programs read but do not alter the file. They will skip lines that they do not understand.

So for example, here is a more complex mTCP configuration file:

DHCPVER
DHCP Client version Apr 26 2009

TIMESTAMP Sun Apr 26 17:59:54 2009

# Parms for my machine

#

packetint 0x60

mtu 1500

hostname DOSBox

# IRCjr parms

#

ircjr_nick Brut_DOSBox

ircjr_user Brutman

ircjr_name Brutman on IRCjr for DOS

ircjr_connect_timeout 15

ircjr_register_timeout 60

# FTP parms

#

ftp_connect_timeout 15

# DHCP generated settings will appear here

#

IPADDR 192.168.2.102

NETMASK 255.255.255.0

GATEWAY 192.168.2.1

NAMESERVER 24.159.193.40

LEASE_TIME 86400

More on the MTU setting

MTU stands for 'Maximum Transmission Unit' and it tells the TCP/IP stack how big of a packet it can send on the local network. Bigger packets generally mean less overhead.

In a world where all networks are built using the same technology the MTU setting would not be needed. But that is not our world. Ethernet predominates, but there are other physical transports out there that you might not be aware that you are using. Your Ethernet traffic will be transmitted over many different things that don't look like Ethernet before it reaches its final destination.

For normal TCP/IP stacks this is an issue because packets that are too big for a network will have to be broken up. This causes some performance loss as the packets have to be broken up and then later reassembled. For mTCP this is a serious issue because mTCP does not support fragmenting or reassembling packets. A packet that was broken up in flight into fragments WILL JUST BE DROPPED. This is obviously not a good thing, but I decided not to implement packet fragmenting and reassembly in mTCP because it is very memory and CPU intensive. (I may revisit this design decision.)

The good news is that you have some control over the problem.

Applications that use TCP sockets will tell the remote side what their MSS (Maximum Segment Size) is. MSS is based on MTU. This happens during the socket connect and once the remote side knows your MSS it will not knowingly send you a packet that needs to be fragmented. (Something in the middle might cause fragmentation though.)

If you are having problem with dropped packets on a TCP socket, drop your MTU to 576. That is guaranteed to work on all networks, all gateways and all routers.

UDP applications are not so lucky - UDP messages do not have the concept of MSS. If a UDP packet is too big it will be fragmented and dropped by mTCP.

The good news is that mTCP applications only use UDP for DNS lookups, and DNS lookups were designed with this limitation in mind. So DNS response packets send by UDP *never* exceed 512 bytes of data.

For best performance, set MTU to 1500 - that is the maximum for Ethernet. Only drop down to 576 if you are experiencing dropped packets.

SLIP Users!

If you are using a packet driver that does SLIP you are going to be interested in this.

Prior versions of this stack didn't work with packet drivers running over serial ports even if ethernet emulation was used on the packet driver. This is because the stack would try to ARP to find the MAC address of the gateway machine (the machine on the other end of the serial cable) and the gateway machine would probably not respond or the packet driver would not pass the ARP packet.

I have a new 'workaround' for this problem. If you set the "MTCPSLIP" to anything the stack will think it has an ARP entry for the gateway even though one will never actually be sent. This should allow you to use something like CSLIPPR with the ethernet emulation option.

set MTCPSLIP=true

Try it and let me know how it works ..

Created July 31st, 2008, Last updated September 25th, 2009
(C)opyright Michael B. Brutman, mbbrutman@yahoo.com