COVID-19 Project - Making Your Own Dial-Up Server
About a month back on my personal Twitter, I made a post about getting my own dial-up system going. I wanted to explain what it took to get everything working as there were quite a few people interested in this project.
My setup consisted of a 1993 Apple PowerBook 160 running System 7.1 (and later a 1998 PowerBook G3 "Wallstreet"), one Raspberry Pi to act as the dial-up server, one virtual machine running Issabel PBX (a CentOS-based Linux distribution intended as an easy-to-use PBX solution), two Grandstream HT701 ATAs, and a US Robotics Sportster 56k modem. And, of course, some phone cable.
The setup was pretty simple, starting out with Issabel PBX running on my desktop computer in VMware Workstation. Once installed, I logged into the web interface, set up two extensions for the two Grandstream HT701s, manually configured both the HT701s via their web interfaces, set up the Raspberry Pi with the US Robotics modem plugged into one HT701, and my PowerBook 160 plugged into the other. On the Raspberry Pi end, I set up minicom on /dev/ttyUSB0 where the modem was active on. On the PowerBook 160, I dialed the Raspberry Pi, and was met with some moderate success. Both devices were able to communicate, but something was very wrong as the handshake almost always failed, or if it did succeed, the connection would almost immediately disconnect. With the basic setup out of the way, it was time to delve a bit deeper and start the troubleshooting process.
The first thing that I thought could be an issue was jitter, or dropped packets. Although everything was running through my LAN, it could still theoretically be an issue. So, I spent several hours adjusting the jitter on Issabel with mixed results. Sometimes it seems like it'd work longer, sometimes it'd seem like it got worse. No matter what, it seemed like regardless of what I tried, jitter didn't appear to be an issue. However, to rule out the possibility of this being an issue down the road, I set up a very small jitter buffer. You want to keep your jitter buffer very small here as the bigger it is, the more latency you'll have.
The next thing I looked into is the codec being used. As we're using our VoIP system to send data through, we want to ensure that we're using something uncompressed and high-quality. However, after having a look at both Issabel and the Grandstream ATAs, both were set to use G.711 U-LAW which is the best codec to use in a situation like this. Again, I didn't see this as the problem and left it alone.
The next thing I decided to try was seeing if I could get any connection going at all by adjusting the link speed manually on the US Robotics modem connected to the Pi instead of letting it determine the speed on its own. At first I tried the absolute lowest it could go, 300 baud, and it still didn't work for some reason. However, upon trying 1200 baud, I finally got a stable connection going.
But still, that was only 1200 baud. I tried 2400 baud and was able to get it connected as well, but it was a lot less stable. The modems would have to retrain almost every few seconds, and the connection would often drop. I refused to believe that 1200 baud was the fastest that this setup could pull a connection at, but it was very late and I was tired, so I stopped working on it for the night.
I slept on it a bit and when I woke up, I thought about something and some friends on Twitter also pointed out exactly what I was thinking: echo cancellation. Most ATAs have some form of it enabled by default, and that could be what's wreaking havoc on the data connection. I got everything set back up, checked the Grandstream ATAs, and sure enough, echo cancellation was enabled on both. Disabled it, tried dialing again without manually specifying a speed, and... success. I brought out the PowerBook G3 which had a much faster modem than the 160 to really test out speeds. Everything was perfect now.
The last step I wanted to do now that all the pieces were together was making the Raspberry Pi automatically answer the calls and provide a terminal over this data connection. This was as simple as installing mgetty and configuring it to listen automatically on /dev/ttyUSB0. With that set, I tried it out one more time and... bingo, we had a real dial-up server.
There is more that can be done with this, such as setting up PPP to allow for direct Internet access through dial-up, but I haven't done this as of yet. If you are interested in getting to that point, there's a great write-up on Doge Microsystems that explains how to go about doing this.
There is also the possibility of doing something even crazier, such as connecting an ATA wirelessly, connecting it using a VPN tunnel at a different location... or both. Essentially, you could have your own dial-up system anywhere if you wanted to get to that point... and that may be a post for a later time.