As regular readers are aware, I enjoy spending time logged in to a few personal favorites of the myriad telnet bulletin board systems that are presently online and serving as discussion communities for their users. As often as I can, I use one of my vintage systems to “dial” in and read the latest gossip rather than a modern Mac or PC. I use serial-to-WiFi bridge devices to make the process simple and as clutter-free as possible.
Another “modern day” (if you can call it that) use of these vintage systems I like to engage in is keeping an Internet Relay Chat (IRC) instance open on this or that system to glance at across the room and occasionally wheel my chair over and chat a bit on said system. (I hope you didn’t learn about IRC on TV…) This pursuit is less well served by the aforementioned serial-to-WiFi bridges given that many of the systems on my desks lack a proper IRC client. If I want to use such systems to IRC, the best way to go, from my perspective, is to telnet into my always-on desktop Mac and launch my go-to IRC client, the terminal-based irssi, which works quite well as accessed from a remote VT100 terminal. And, nearly all of the systems in question have VT100 emulation supported by a several software terminal emulator programs such as ProTerm on my favorite vintage IRC system, the Apple IIe to my left.
For years (and on many different systems) I would achieve this by utilizing a USB-to-serial adapter on the Mac and running a serial cable from the vintage system in question to said adapter on the Mac. But it was a cumbersome process. And, several OS updates ago Apple redid the USB stack in macOS and rendered the adapters I had on-hand inoperable. To get around this I setup a Raspberry Pi connected via WiFi to my network, specifically to serve as the host system for the remote terminal, as it maintained support for my adapters — it worked (video), but it was a configuration I was never really happy with.
So, I headed to the Apple II Infinitum Slack channel and asked if it was possible to setup a listener on the desktop Mac to allow a vintage system equipped with a serial-to-WiFi adapter to “dial in” to the Mac and be granted a wireless terminal connection. It turned out, it was.
I learned that in a few simple steps you can setup a listener macOS daemon that will allow an incoming telnet connection to a specified port and present a shell session with a login prompt where you can login and execute terminal commands. When I do so, I’m usually there to launch irssi and connect to an IRC server, but other commands work nicely, such as the system monitor top, if you want to keep an eye on how things are doing when fullscreen apps are hogging the displays. (Another nice terminal-based IRC client is WeeChat, by the way.)
I currently have this arrangement up and running on my 2022 Mac Studio (M1 Max) but I originally set this up on the 2017 5K iMac (Intel Core i5) — it will work on either Apple Silicon or Intel-based systems. Here’s how to do it.
If your Mac doesn’t have a static IP on your LAN, it’s a good idea to configure your router to assign it one so that you’ll know what IP to “dial” up. I’ve configured my router to assign the Mac Studio the static IP address
192.168.1.150 on my LAN.
brew install socat
Next, the listener is a .plist that needs to be loaded as a daemon. The file I am using, com.retrogeeks.bbs.plist, was shared with me on the aforementioned Slack channel. Here it is in its entirety:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.retrogeeks.bbs</string> <key>ProgramArguments</key> <array> <string>/opt/homebrew/bin/socat</string> <string>-</string> <string>EXEC:"/usr/bin/login -p",pty,setsid,setpgid,stderr,ctty</string> </array> <key>EnvironmentVariables</key> <dict> <key>TERM</key> <string>vt100</string> </dict> <key>SessionCreate</key> <false/> <key>Sockets</key> <dict> <key>Listeners</key> <dict> <key>Bonjour</key> <false/> <key>SockProtocol</key> <string>TCP</string> <key>SockServiceName</key> <integer>6666</integer> </dict> </dict> <key>inetdCompatibility</key> <dict> <key>Wait</key> <false/> </dict> </dict> </plist>
As can be seen, the daemon sets up a listener on TCP port 6666 (edit the port # as you see fit) and presents a login prompt to any connection established there, using VT100 terminal emulation (edit the emulation as you see fit). The path here to socat is in the standard Homebrew install location — if it’s elsewhere on your Mac, edit the string accordingly.
You can move the .plist from your user directory to its intended destination by issuing the following (and entering the root/admin password when prompted):
sudo mv ~/com.retrogeeks.bbs.plist /Library/LaunchDaemons
To register the daemon with launchd, issue:
sudo launchctl load /Library/LaunchDaemons/com.retrogeeks.bbs.plist
This should have you up and running to allow a remote vintage system equipped with one of the serial-to-WiFi “modems” out there (I use the WiFi232, several others are listed on my BBSing resource page) and a standard terminal program to “dial in” (via telnet) to your Mac using its IP and port number, à la:
And everything will stay nice and put … and listening … after a reboot, as well.
Something that I had to work around after setting this up on the new Mac Studio is due to the shell I’m using: Z shell. In 2019 with macOS Catalina, Apple moved to Zsh from Bash as the default system login shell, and it seems that despite the emulation indicated in the TERM environment variable, Zsh is a little cavalier about outputting fancy prompt characters that are more aimed at an xterm than the comparatively basic VT100. As such, I was seeing characters that ProTerm on the Apple IIe wasn’t able to translate.
To get around this, I added the following code to the top of
/etc/zprofile, which is a script that executes for all users when a login shell is presented.
# Added to facilitate remote login from simple client (WiFi232) if [ _$TERM = "_vt100" ]; then exec bash ; fi
This simple conditional tells the system to present the Bash shell, rather than Zsh, to users logging in with a TERM type of VT100. (If you changed the emulation in the .plist, change the emulation above accordingly.) Problem solved.
[UPDATE – July 2023]: After about six months without connecting to the Mac from one of my vintage systems, I connected and found that I was once again seeing the aforementioned characters that my terminal in VT100 mode could not decode. Looking around the shell config files on the Mac, I found that a recent macOS update ( I’m currently running Ventura ) overwrote
/etc/zprofile, and so I had to add the above bit of code back in. That solved the character issue upon connecting, but none of my Homebrew binaries were in the path. To solve this, I created the file
~/.bashrc and placed the contents of
~/.zprofile within it:
eval "$(/opt/homebrew/bin/brew shellenv)"
All this done, I was back in business. [ /UPDATE ]
Whatever the reason to login to your modern Mac from a vintage “terminal” across the room, it feels like a great way to exercise your systems of olde. I hope this guide is found to be of help for those interested in setting up such a configuration.