Jump to content

Photo

Proof-of-concept for dialup BBS on modern hardware


No replies to this topic

#1 x=usr(1536) OFFLINE  

x=usr(1536)

    Dragonstomper

  • 879 posts
  • Location:913 S. Broadway, Los Angeles, CA 90015

Posted Sun Mar 4, 2018 6:54 PM

Having run across this thread earlier, it occurred to me that there might be some interest in a project that I've been fiddling with on and off in my spare time for the last few months.

 

Some background: about four years ago, it became necessary to have an actual fax machine at home.  Our printer already had the capability, but we didn't want to have to pay for a landline in order to be able to use it.  In searching for a solution to this, I ran across Obihai, who make devices that can bridge Google Voice service to analogue phones - or faxes, or pretty much anything else capable of making use of dialtone and an RJ-11 connector.

 

As it turned out, this worked surprisingly well, and also proved that usably passing data over VoIP was at least possible.  But it left me wondering if it was possible to run a BBS or other modem-based dial-in service over VoIP, a thought which I didn't put any real effort into at the time.  Eventually, however, some free time fell into my lap and I decided to put something together to test the idea.

 

The environment that was built used the following:

  • A pair of Google Voice accounts (one for testing, one to dedicate to the BBS)
  • An Obihai 202 Google Voice to analogue telephony adapter
  • A pair of TrendNet TFM-561U USB 56Kbps modems (one for the BBS, one for the machine I'm testing dialup to the BBS with)
  • A V-Tech CD1103WH analogue phone for testing purposes ($6 at Wal-Mart)
  • The VMWare ESXi hypervisor
  • A rotating cast of virtual machines running under VMWare ESXi.

The first thing to do was to get dialtone to both the phone jack in my office and the BBS' modem.

 

Configuring the Obihai for both Google Voice accounts, one of its phone ports was dedicated to the test number with the other phone port dedicated to the BBS number.  The test number port was plugged directly into one of the house's disused phone jacks, which conveniently brought dialtone to the phone jack in my office; the BBS' modem was cabled directly to its phone port on the Obihai.

 

One of the TrendNet USB modems was installed on the machine on my desk; the other was attached to the VMWare server that the BBS would reside on.  The Wal-Mart phone was used to test that calls could be made from the test number's modem to the BBS number and vice-versa.

 

With that out of the way, it was time to build the proof-of-concept.

 

This went through a number of iterations.  Frankly, I wasn't happy with any of them, and still haven't settled on a final configuration.  For now, however, it's a Windows XP (more on that further down) virtual machine running a mix of SEXPOTS, the NSSM service manager, the ncat general-purpose network connector, and fortune for Windows.  It's cobbled together so that the following happens (and all network connections are made on the loopback address):

  1. At boot, SEXPOTS starts as a service on its own; NSSM starts ncat as a service.
  2. ncat listens on TCP/17.
  3. SEXPOTS redirects dial-in sessions from the modem to TCP/17.
  4. When ncat sees a session come in on TCP/17, it runs fortune and sends its output over TCP/17 to SEXPOTS.
  5. SEXPOTS takes the data it received on TCP/17 and crams it back down the modem to the dial-in session.
  6. The person who dialled in sees the fortune printed on their terminal and the session is automatically disconnected.

Some notes on why this particular arrangement was chosen follow.  Apologies for any gaps in the explanations; I've almost certainly forgotten things since this was initially configured.

  • Windows XP was chosen for compatibility reasons with older BBS software.  Yes, XP is an unsupported security nightmare these days, but the VM it runs under is configured without the network adapter connected to a vswitch.  Even if it did get 0wned, there wouldn't be much that could be done with it that would be useful since it has no connectivity beyond the modem.
  • TCP/17 is being used for the ncat listener because that's the same port as was originally allocated to QOTD (Quote of the Day).  Since this part of the PoC basically replicates QOTD's functionality, I decided to be anal about things and use its port.  RFC compliance is Serious Business in an undertaking like this.
  • If I hadn't wanted to use TCP/17 and had instead stuck with the default port of 23 (telnet) that SEXPOTS uses, NSSM and ncat could have been eliminated and Net2BBS used instead.
  • NSSM, ncat, and Net2BBS can all coexist without stepping on each other.  This opens up the possibility of having Net2BBS handle connections to the BBS under normal conditions while ncat handles connections to, say, a message informing callers that the BBS is down for maintenance, etc.  Just repoint SEXPOTS to the appropriate TCP port that ncat is listening on, restart the SEXPOTS service, and callers get a 'try again later' message when attempting to connect; flip it back over to pointing at Net2BBS to resume normal service.
  • Doing this under Linux by way of mgetty is also a possibility - and, indeed, the original plan had been to do this on a Raspberry Pi.  However, the BBS software options weren't exactly what I was looking for under Linux, so it ended up running on Windows.
  • There are some batch files that glue various small but significant things together.

In a nutshell, that's how it does it.  Now for the 'why'.

 

The more I thought about it, the more I was entertained by the idea of using a (mostly) modern technology stack to replicate the functionality of a communications method and medium that are largely considered to be obsolete - and ones that are particularly relevant to the career path I later took.  There was also the 'can it be done?' aspect:

this almost certainly wasn't the first time that someone had tried it, but there wasn't any clear record of anyone else having done so.

 

One other thing was appealing in all of this: finding a practical use for old software.  There is a surprising amount of BBS software still available, with many packages still being maintained and developed.  All they really need is a modem to be useful, and those are easy to get.

 

There are plans to make some changes - a USRobotics Courier 56Kbps Business Modem (which are practically constructed to withstand harsher environments than cockroaches can endure) fell into my lap on Friday, and will probably end up being the BBS modem.  This will pull a digital / analogue conversion stage out of the VoIP environment that's introduced by the USB modem, which may help with data rates.  Or not, and it will just look completely proper.

 

There is one other thing I want to do with this, but I'm not certain that it can be accomplished in the way that I'd like it to be.  But that's for later on icon_wink.gif






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users