!LoRa BBS: Keep it simple, stupid! --- agk's diary 14 September 2026 --- written on GPD MicroPC (2019) --- My vision for the local BBS over non-internet, non- cellphone, non-HAM wireless was the following: (I've never diagrammed a network before, let me know if this makes sense, or what is missing or unclear) BBS | (serial link | <------ over USB) | RNode | (reticulum link over ----------------------------------- wireless | | | <---- LoRa) | | | RNode RNode RNode | | | (serial | | | <---- over | | | USB) Client ttyS/ Client Kermit/ Client x/ Core Linux DOS OS y http://agk.sdf.org/ware/heltec.jpg <---(photo of lap- top connect- ed to RNode by USB) The plan: - Standalone RNodes have routable identities on our reticulum network. - Client computers won't have reticulum network identities. They'll be dumb terminals. - The RNode to RNode reticulum network will be invisible to client computers, which will see an async serial connection to the BBS. - The BBS may exchange gopher, news, or email with other BBSes nightly or weekly. That link isn't depicted. We learned that RNodes don't work the way I want them to. At least, not yet: - We couldn't find a serial data interface in any RNode firmware. - Reticulum is designed for routable identities to be associated with client devices, not RNodes. - When microReticulum is configured for the RNode to operate in standalone mode, with support for a legacy protocol (packet radio), it broadcasts all packets unencrypted, accompanied by a call- sign every 5 minutes, instead of encrypting packets and routing over the reticulum link layer. My correspondent p/sldpt[^1] encourages me to tell stories of wild goose chases, not only successes. The rest of this textfile is the goose chase. [^1]: gopher://sdf.org:70/1/users/psldpt/ Asynchronous serial; packet radio --------------------------------- We assumed by using "withered" (mature) communicat- ion standards, we could run any BBS software, and access it from old, solid, retrocomputing-friendly software on virtually any client computer. If RNode firmware supported a RS-232 async serial link over our reticulum network, we'd be done. Since it doesn't, we thought maybe we could route packet radio data over reticulum. Async serial and packet radio are indeed withered standards: - The RS-232 serial communication standard dates from 1960. Teletypewriters and terminals exchang- ed data with computers over RS-232 serial cables nearly seventy years ago. - The X.25 standard protocol suite for packet- switched data communication in wide area networks dates to 1976. Compuserve (US) and Minitel (France) used the protocol. Amateur radio operat- ors started using a wireless version of the protocol suite in 1978. The oldest electronic Bulletin Board Systems I know of (predating PCs and home answering machines) were only reachable by amateur packet radio. - Revisions of both are still used. From the point of view of a client, as I understand it, the packet radio terminal node controller (TNC) is a tiny computer that a dumb terminal can talk to over a serial line. It talks to other TNCs over packet radio. This was nearly the configuration we wanted! Packet radio BBS and client --------------------------- LinBPQ is a computer Bulletin Board Service for packet radio. It installed easily on a 2007ish core2 duo ThinkPad and ran. I have no notes on using it, because we spent half a day getting a client to work, then realized the RNode wasn't routing traffic over the encrypted reticulum network when we used TNC functionality. We abandoned KISS-attach, the first client we tried. The documentation quality is poor. There are two setup guides online: One for Arch, one for Debian. Both assume you'll use software called direwolf to make your soundcard act as a modem, translating data to sound. We didn't want to do that. We mistakenly thought we were merely pretending to use packet radio while routing data over reticulum. KISS-attach relies on a bunch of depreciated depend- encies. It wouldn't compile without us guessing which dependencies we wouldn't need and removing them. Then it complained our mKISS drivers appear to be missing. mKISS drivers have been in the Linux kernel for a long time. It's unclear why KISS-attach couldn't find them. This was turning into a mess. We wanted to be able to use any serial terminal on any machine running any OS to talk to our reticulum TNC. This was not that. Next we tried the heavier (but functional) Graywolf. It has a mode we didn't use where it's a full soft- ware TNC with modem virtualization, and the mode we used to drive a hardware TNC or LoRa radio like our RNode. Once we were driving a working client (albeit one with a WebUI that depends on a web browser to render it, far from our original retrocompatible goalpost), we learned it wasn't using the reticulum link layer at all. Why the packet radio approach was bad ------------------------------------- Even if the zany idea of "packet radio over retic- ulum" had worked, it's dumb. It would have involved unnecessary translation, into packet radio's data format, into modulated sound, into reticulum's data format, back into modulated sound, demodulated back to packet radio's data for- mat, then into something the client speaks. It has very limited choices of clients and BBS servers. It won't get arbitrary machines from any decade since the early '80s talking to each other. It's immaterial, because this approach doesn't even call the BBS over the reticulum link layer. Why the packet radio approach is interesting -------------------------------------------- When retrocomputing enthusiasts get a Commodore 64 or such on the modern internet, they use an inter- mediate computer as a "jump box." The jump box is often a single board computer (like a Raspberry Pi Zero) or a microcontroller (like an ESP32, the MCU controlling most LoRa boards). The host computer connects to the jump box some way it knows how. The FujiNet device presents a serial interface to the host (the approach we hope to rep- licate), as do, if I'm not mistaken, packet radio TNCs. If the host has an Ethernet or Bluetooth card and drivers and a TCP/IP stack, the hop to the jump box can be telnet. We don't want no stinkin' TCP/IP or network card drivers. We want to run MS DOS Kermit and type: > set port com 1 > set speed 9600 > set parity none > set flow none > connect The TNC or FujiNet approach is in fact the approach we want. An RNode jump box mode just doesn't exist yet. Next steps ---------- My guests are regrouping and considering how tough it would be to fork or patch microReticulum firmware to make it do what we want. When microReticulum's in host mode, it routes 500- byte reticulum packets, but depends on Reticulum- specific software running on the host computer, including for cryptography and identity. This limits the salvaged hardware and operating systems it could work with. In standalone transport mode, microReticulum firm- ware generates its cryptographic identity on-device. I believe it also presents a serial interface to the RNode's provisioning and management console. How tough would the programming project be to make a translation layer allowing dumb terminal control of *and* communication via the RNode in transport mode? Would BBS server software need modification, or can the RNode "just work" as if it was a modem or a telnet port? One thing I'm learning along the way is that lateral thinking with salvaged withered tech generally depends on hardware "glue layers" between devices. Dongles, jump boxes, flash drive system disks, and peripherals enable hardware composability. Elements can be stuck together in unexpected cool ways. But some hardware needs firmware. And sometime the old firmware has not yet died and the new firmware struggles to be born. This is the time of monsters. --- Watch the BBS documentry; download BBS server software: http://www.bbsdocumentary.com/