What Dial D For Don Actually Does
It is a Unix dial-up automation script that manages modem conversations for BBS systems, shell accounts, and FTP logins. The name comes from a reference in an old Usenet post, not from any official software company. You point it at a phone number and a login script, and it handles the handshake, timeout recovery, and multi-stage authentication without you watching the terminal. Before getting into the mechanics, here is the practical part: Dial D For Don reads a plain-text control file that tells the modem what to send and when. It works through a serial port, usually /dev/ttyS0 or a USB-to-serial adapter on /dev/ttyUSB0. The script opens the port at 9600 baud, eight data bits, no parity, one stop bit, and then runs through a sequence of expect-style pattern matches. I built my first setup on a Debian box using gnu Expect as the backend, though the original releases worked fine with Tcl 8.4 and minicom or screen on the serial side. You write a .dsf file — that stands for don script file — with lines like:
wait "Login:" send "myuser\r" wait "Password:" send "mypassword\r" Each line blocks until the modem receives the expected string, then sends the next command. If a timeout hits, the script can fall back to retry logic or abort entirely. That is the whole engine. Nothing magical about it.
Setting It Up on a Modern System
The original dial-d-for-don packages are archived in old Linux distro repos and can show up on places like sourceforge mirrors or the Linux Archive. Installation is straightforward on most systems because the dependencies are minimal — Tcl, Expect, and a C compiler if you are building from source. On Debian-based systems, if your version still carries the package, it installs in about ten minutes. On newer distros that have dropped it, you compile from source, which takes roughly twenty minutes depending on your machine speed. Here is what the install path looks like on a typical system: Compile with make, then sudo make install. The binary lands in /usr/local/bin/don by default. You create a ~/.donrc file to set your default phone book entry, modem device, and timeout values. That default config saves you from typing the same parameters every time you run the script.
Get the Full Details
I kept getting permission errors on the serial port after switching from root to a normal user account. The fix was adding my user to the dialout group and running sudo usermod -aG dialout $USER. Without that, Dial D For Don cannot open /dev/ttyUSB0 even if the modem is physically connected and powered on.
A Real Problem I Hit
There is one edge case that burned me for an afternoon. Some ISP dial-up gateways, especially older Cisco-based ones, do not send a standard LOGIN prompt. They send a garbled mix of carrier detect signals and a delayed prompt after approximately 4.7 seconds. The built-in timeout in Dial D For Don defaults to 10 seconds, but the script was matching against the wrong byte sequence because the initial handshake included extra null characters that threw off the pattern engine. The workaround was writing a custom timeout override in the script file: wait "5" send "\r" wait "LOGIN:" send "myname\r" The explicit five-second sleep gave the gateway time to complete its internal negotiation before the script sent anything. Without that pause, the BBS logged me in as anonymous and kicked me out two seconds later. I know that exact timing because I timed it with a stopwatch while watching the modem's terminal output.
Common Pitfalls Beginners Miss
People assume Dial D For Don works out of the box with any USB modem. It does not. Most cheap USB modems enumerate as generic CDC-ACM devices and require the option driver or ftdi_sio kernel module loaded manually. If you plug one in and see nothing at /dev/ttyUSB0, run lsmod | grep ftdi and lsusb to verify the kernel sees the hardware. If it shows up as a different vendor ID, you may need to pass the vendor and product ID to the driver with insmod option vendor=0x1234 product=0x5678. Another thing that catches people is line ending confusion. The script expects \r for carriage return, not \n. If you edit your .dsf file on Windows and transfer it to Linux, the \r\n endings break the expect parser. Run dos2unix on the file before testing it, or lose an hour debugging prompts that never match.
What Dial D For Don Cannot Do
This tool is not a general-purpose automation framework. It handles serial modem communication, nothing else. If you need to interact with a web portal, an SSH server, or a modern VOIP system, Dial D For Don is the wrong tool. It also struggles with modems that use flow control beyond simple XON/XOFF. Hardware RTS/CTS flow control causes the script to hang on certain USRobotics models because the handshake signals conflict with the expect timeout logic. You have to disable flow control in the modem's AT commands — AT&K0 — before the script works reliably. The maintenance burden is real too. The project has not seen a major release since the mid-2000s, so new hardware from the last decade often lacks out-of-the-box support. You will find patches on mailing list archives if you dig deep enough, but the upstream codebase is essentially frozen. For basic 56k modem work on legacy hardware, it still functions adequately. For anything requiring modern protocol negotiation, you are better off writing a small Python script with pySerial and pexpect instead. That approach takes about the same time to develop and gives you current library support.
When It Still Makes Sense
If you run a vintage computing collection, maintain a retro BBS node, or need to automate dial-up connections to industrial equipment that only speaks serial, Dial D For Don remains a functional solution. The script files are portable between systems, and the configuration format is simple enough to audit quickly. A typical automation job that would otherwise require a full terminal session and manual intervention runs in under three minutes from start to finish once the script is written and tested. That speed gain is the main reason people still reach for it. I used it recently to automate nightly backups to a remote shell account over a dial-up line with a 56k modem. The connection took about ninety seconds to establish, the transfer ran for twelve minutes, and the script closed the line cleanly afterward. Total hands-off time was zero minutes because I had already verified the script with a dry run. The only friction was the initial setup, which took roughly forty-five minutes across two sessions due to the serial port permission issue I mentioned earlier.
