Skip to content
Tech News
← Back to articles

Hunting a 34 year old pointer bug in EtherSlip (DOS Networking)

read original get Ethernet Packet Sniffer Tool → more articles
Why This Matters

This article highlights the discovery and investigation of a 34-year-old pointer bug in EtherSlip, a DOS networking tool, emphasizing the ongoing challenges of maintaining legacy systems and the importance of understanding low-level memory management. It underscores how vintage networking solutions still have relevance and potential issues that can impact modern retro-computing or embedded environments, making this a noteworthy case for both developers and enthusiasts. The deep dive into debugging such long-standing bugs demonstrates the enduring complexity of segmented memory and pointer handling in legacy code.

Key Takeaways

Hunting a 34 year old pointer bug in EtherSlip

[email protected]

Posted: 2026-04-19

Tags: DOS, Networking, Segmented memory is hard

A few weeks ago I was revisiting my instructions for running a SLIP connection between a DOS PC and Linux. If you are not familiar with SLIP it stands for Serial Line Internet Protocol, and it lets you run TCP/IP over a PC serial port. TCP/IP is much faster over Ethernet, but a serial port can work too.

There are several packet drivers for DOS that let you make SLIP connections. One that I use often is "EtherSLIP" which is handy because it emulates an Ethernet packet driver but it is really just SLIP over a serial port. The emulation allows you to use programs designed for Ethernet packet drivers unmodified; otherwise, you'd have to run programs that are designed specifically for SLIP packet drivers. All of the mTCP programs expect Ethernet, but they don't actually know what is happening "under the covers" so any packet driver that emulates Ethernet works too. (Besides EtherSLIP there is also a Token Ring packet driver that emulates Ethernet.) EtherSlip is included in the Crynwr packet driver collection, which covers most classic ISA Ethernet cards.

I used Telnet to do my testing and there was something wrong with my cabling; it was slow and dropping packets like crazy. (It turned out to be a hardware problem.) When Telnet exited it gave me this error message:

*** NULL assignment detected

Well, that doesn't sound good. The compiler I use (Open Watcom 1.9) checks the heap at the end of a program to let you know if there was heap corruption, but this is a different error message. I dug through the PDF documentation and I found an explanation in the "Watcom C/C++ Programmer's Guide." Here is a summary of the problem:

Normally it is an error to use a NULL pointer and on a real operating system you will get a signal or an interrupt if you try to read or write using one. 16-bit DOS doesn't have that capability so it is allowed, even if it is an error.

... continue reading