How to Set Up Networking on FreeDOS with mTCP

mTCP is the actively-maintained TCP/IP stack most commonly used to get real networking working on FreeDOS today — this walks through a complete setup, from a packet driver up to a working FTP client.

Step 1: identify your network card and get its packet driver

Networking under DOS-era systems works through a packet driver — a standardized low-level interface between the network card and TCP/IP stacks like mTCP. For a virtual machine, an emulated NE2000-compatible card is the most broadly supported choice:

# QEMU example, emulating a widely-supported NE2000 card
qemu-system-i386 -hda freedos.img -netdev user,id=net0 -device ne2k_isa,netdev=net0

For real hardware, you’ll need a packet driver matching your specific network card — many are available from the Crynwr packet driver collection, still archived and available today.

Step 2: load the packet driver

C:\NET\NE2000.COM 0x60

0x60 here is the software interrupt number the packet driver registers itself on — mTCP’s tools need to know this same number to talk to it.

Step 3: download and install mTCP

Copy the mTCP package (.zip) onto your FreeDOS system, or install it via FDNPKG if it’s available in your configured package repository:

C:\>FDNPKG install mtcp

Step 4: create mTCP’s configuration file

# C:\MTCP\MTCP.CFG
PACKETINT 0x60
HOSTNAME freedos-pc
IPADDR 192.168.1.50
NETMASK 255.255.255.0
GATEWAY 192.168.1.1
NAMESERVER 1.1.1.1

PACKETINT must match the interrupt number the packet driver registered on in step 2. Adjust the IP address, gateway, and DNS server to match your actual network — mTCP doesn’t include a DHCP client by default in older versions, so static configuration like this is the standard approach, though a DHCP utility is available separately.

Step 5: set the MTCPCFG environment variable

SET MTCPCFG=C:\MTCP\MTCP.CFG

Add this to AUTOEXEC.BAT so it’s set automatically on every boot, since every mTCP application looks for this environment variable to find its configuration.

Step 6: test basic connectivity

C:\MTCP\PING.EXE 192.168.1.1

If this succeeds, your packet driver and mTCP configuration are both working correctly at the IP level — a good sign before testing anything higher-level.

Step 7: test DNS resolution and internet connectivity

C:\MTCP\PING.EXE google.com

If the direct IP ping worked in step 6 but this fails, the problem is specifically DNS resolution — double-check the NAMESERVER line in MTCP.CFG.

Step 8: use FTP to transfer files

C:\MTCP\FTP.EXE ftp.example.com

mTCP’s FTP client supports the standard commands (get, put, ls, cd) for transferring files between your FreeDOS system and any FTP server — genuinely useful for moving files to and from a FreeDOS machine without needing physical media.

Step 9: try Telnet for remote terminal access

C:\MTCP\TELNET.EXE bbs.example.com

Step 10: browse the web, within DOS’s real limitations

mTCP includes a very basic HTTP/gopher client suitable for simple, mostly-text pages — genuinely useful for retro-computing purposes and simple text-based services, though modern, JavaScript-heavy websites are entirely out of scope for what a DOS-era browser can reasonably render.

Why mTCP specifically

mTCP is actively maintained (unlike many DOS-era networking tools that stopped receiving updates decades ago), well-documented, and specifically designed with modern packet driver compatibility and virtualization environments in mind — making it the practical, current choice for real networking on FreeDOS today, whether the goal is retro-computing, legacy system integration, or simply moving files to and from a FreeDOS machine efficiently.

Who actually maintains it, and under what license

mTCP is the work of a single author, Michael B. Brutman, who wrote the original TCP/IP kernel in 2009 specifically for DOS-class machines, aiming for genuinely high performance even on slow, memory-constrained period hardware — the networking stack itself is written in a mix of C++ and assembler for exactly that reason. Brutman released mTCP under the GNU General Public License version 3 in 2011, and continues to publish new dated releases directly from his own site rather than through a separate distribution project, which is worth knowing if you ever need to confirm you’re running a current version or want release notes for a specific build.

Why a single-author, still-active project matters for something this fundamental

Networking is exactly the kind of subsystem where an abandoned, unmaintained tool becomes a real liability over time — protocol quirks, changing packet driver behavior under newer virtualization platforms, and compatibility issues that only surface on hardware or hypervisors that didn’t exist when a tool was last touched. A single dedicated maintainer who has kept mTCP updated for over a decade, rather than a project that shipped once and was abandoned, is a meaningfully different risk profile for something this foundational to get right.

What to check first if PING fails at every step

A PING failure at the direct-IP stage (step 6) narrows the problem to exactly three candidates: the packet driver never actually loaded (recheck the boot messages from step 2), the PACKETINT value in MTCP.CFG doesn’t match the interrupt the packet driver actually registered on, or the IP configuration itself (address, netmask, gateway) doesn’t match your actual network segment. Checking these three, in that order, before assuming a deeper problem covers the overwhelming majority of “networking just doesn’t work at all” cases.

Related:

Sources:

Networking FreeDOS - mTCP