DOSBox-X NE2000 Networking: Guest Drivers, Backends, and Host Boundaries

DOSBox-X can emulate an NE2000-compatible Ethernet adapter so a DOS or Windows 9x guest can run network software against a virtual card. That is a different path from DOSBox-X’s built-in IPX tunnel: NE2000 presents hardware to a guest driver, while the emulator’s Ethernet backend connects that emulated card to the host or a user-mode network stack.

The boundary matters. A guest packet driver, an emulated IRQ and I/O range, the emulator’s selected backend, the host’s network permissions, and upstream DHCP or firewall policy are separate layers. A configured card is not proof of network reachability, and a networked guest should not be assumed safe merely because its operating system is old.

Use an explicit, contained configuration first

Recent DOSBox-X source models the card under [ne2000] and reads the enable flag, backend name, IRQ, I/O base, and MAC address separately. The following profile sketch selects the slirp backend rather than capturing from a physical host adapter:

[ne2000]
ne2000=true
backend=slirp
nicirq=10
nicbase=300
macaddr=random

nicbase=300 is hexadecimal 0x300 in the emulator configuration. Use the same I/O base and interrupt in the guest’s NE2000 driver. IRQ 10 is accepted by the reviewed source revision, but can still conflict with the guest’s configured devices; choose resources supported by the emulator and guest driver. macaddr=random asks the current source implementation to generate a locally administered unicast address, reducing accidental duplicate MACs when separate emulator instances join the same layer-2 network.

Backend availability is build-dependent. In the current DOSBox-X source snapshot reviewed for this draft, slirp and pcap are compiled conditionally; an explicit backend that the binary does not include fails to initialize. Read the startup log and confirm that it reports the intended backend instead of assuming the configuration was accepted. The auto selection may choose a different compiled backend on another build, so use it only when that variation is acceptable.

Match the DOS driver to the emulated card

The guest still needs a driver and a protocol stack. A packet driver is not itself a TCP/IP stack: mTCP uses a class-1 packet-driver interface, and the guest’s card driver must agree with the virtual card’s resources. An mTCP-style sequence is:

SET MTCPCFG=C:\MTCP\SAMPLE.CFG
NE2000 0x60 10 0x300
DHCP

Use the packet-driver executable and mTCP configuration file from their official distributions. Replace C:\MTCP\SAMPLE.CFG with the real path and ensure its adapter, IP, DNS, and timeout settings are suitable for the virtual network. Do not copy an IRQ, I/O address, packet interrupt, or static address from a different emulator profile. The packet interrupt (0x60 above) is the software interface used by packet-driver clients; it is not the card’s hardware IRQ.

If the guest reports a driver initialization error, compare the driver’s card settings with [ne2000] before changing DHCP or DNS. If the packet driver starts but DHCP times out, confirm the emulator log shows an initialized network backend, then inspect the guest’s link and DHCP output. Only after the guest has an address should you diagnose name resolution or an application-specific port failure.

Choose between user-mode networking and host packet capture

slirp and pcap solve different problems. DOSBox-X routes the slirp backend through libslirp when that backend was compiled in; its configuration includes a private IPv4 network, host-side virtual address, name server, DHCP range, and optional TCP/UDP port forwards. Treat slirp as a user-mode connectivity backend, not as a host-isolation boundary or proof of controlled outbound-only access. At the pinned upstream revision, dosbox-x.reference.full.conf sets both restricted = false and disable_host_loopback = false in [ethernet, slirp]. Setting restricted = true disables guest access to the host, but the upstream configuration comments warn that services such as libslirp’s DHCP server will no longer work. disable_host_loopback = true separately disables guest access to the host’s loopback interfaces; it is not a general host-access restriction. These options are distinct controls, not a guarantee that a VM is isolated.

Before connecting a guest, inspect the effective configuration and startup log for the exact DOSBox-X binary and build: check which backend was compiled and selected, the active [ethernet, slirp] values, any later config overrides, and port forwards. Do not infer safe settings from a sample file or from the presence of the slirp name. If enabling restricted, account for the resulting loss of host-provided services such as DHCP and provide only the guest services actually needed. Use host firewall rules and an isolated test network for additional containment. Port forwarding deliberately creates an inbound path that needs a separate firewall and exposure review; SLIRP also does not promise that every protocol or legacy broadcast-based discovery mechanism will work.

The pcap backend opens a selected host capture interface in promiscuous mode in the current source. It can put guest Ethernet frames directly onto an interface, but its availability and permissions depend on the host, capture library, build, and operating-system policy. The project wiki’s older setup guide notes that some wireless adapters do not support the bridging behavior that guide expects. Do not “fix” a failed capture by granting broad privileges or attaching an untrusted guest to a work or home LAN. Use an isolated test network and host-approved capture configuration.

Keep the emulator’s data boundary narrow whichever backend you choose. Mount a dedicated guest directory rather than a home folder, make source material read-only where possible, keep save data separate, and do not store current credentials inside an obsolete guest. If a legacy program only needs a local peer, prefer a private virtual segment over the physical LAN. Remove port forwards after the test and stop any IPX tunnel server when no longer needed.

Keep IPX tunneling separate from NE2000 emulation

DOSBox-X also provides an integrated IPXNET tunneling utility for games that need IPX. The project describes this as IPX over its own tunnel; it does not require enabling the NE2000 adapter. Conversely, the NE2000 path is useful for a guest operating system or TCP/IP software that expects a network card and packet driver. Do not install extra guest drivers just because the emulator supports both mechanisms.

If using IPXNET, read the command’s current help, test only with peers you control, and constrain reachability at the host or network layer. Treat it as a separate guest-traffic path, not evidence that a peer has been authenticated or that the guest is isolated from host reachability. Do not expose a listener publicly as a shortcut around the game’s original network configuration.

Validate each layer and preserve a reproducible profile

Keep a per-game configuration alongside the guest’s driver version, machine type, and network purpose. Before a session, verify the profile’s backend, nicirq, nicbase, and MAC policy; confirm the startup log identifies the chosen backend; then check the guest driver’s initialization, packet-driver clients, DHCP result, DNS result, and game or application behavior in that order. A successful PING only proves the path used by that test, not that every legacy protocol or peer-discovery feature will work.

Test a clean boot, a second emulator instance with a different generated or explicit MAC, loss of the host network, and shutdown while traffic is active. If the guest needs inbound access, add one narrow forwarding rule at a time and confirm the host firewall blocks everything else. Capture only on a lab interface you are authorized to monitor. Save the emulator log and configuration with the game profile so a later session can distinguish guest-driver drift from a changed host backend.

Configuration and available backends vary by DOSBox-X build. The project’s networking guide’s latest listed revision is October 7, 2023, before the pinned source snapshot’s October 10, 2026 commit. The guide documents both PCAP and SLIRP, but it cannot establish whether an installed binary includes either backend or shares the reference defaults. For a real installation, inspect the effective configuration and startup log for that exact binary. Use realnic only with PCAP; it does not configure SLIRP.

Related:

Sources: