Retronetworking » BBS-Revival

There are plenty of legacy BBS software packages out there, made for DOS. They either directly interface the serial ports (COM1..COM4) or they use a FOSSIL driver to do so. Attaching those to
real serial ports with modems is possible, but not particularly attractive:

• it requires one physical modem per node (and likely one USB/serial adapter)
• it cannot provide direct IP (telnet/ssh) access
• it cannot be combined with using a RAS server like our Livingston_Portmaster_3

For some other OSs (Windows, OS/2) there are solutions like NetFoss to work around this. I've also found references to a DOS based telnet FOSS driver baesed on Ethernet cards with packet driver. No proper solution for a Linux based setup with qemu-kvm seems to be out there.

Using the built-in serial port telnet server of qemu is one idea, but

• it would mean each line (COM port) has a different telnet port
• there doesn't seem to be any escaping for binary (0xFF, ...)

One could build something based on https://github.com/freemed/tty0tty (a virtual nullmodem device), so one side could be passed though qemu, and the other end could be served by some kind of custom telnet daemon. tty0tty has the advantage of at least handling the modem status/control lines properly - very uch opposed to any pty based approach.

The cleanest solution would probably be to implement something based on RFC2217 (Telnet Com Port Control Option). This has the advantage that it fully supports modem control lines, and that it can also be used to interface any actual serial/terminal server hardware, if ever needed.

So either qemu would have to run a RFC2217 telnet server which would then accept e.g. up to 4 or 8 connections, and dispatching any of those to a virtual 8250 serial UART, or it would have to run one RFC2217 telnet client for each virtual 8250 UART.

In case of a telnet server, that server then would also have to implement something like AT command emulation, so the DOS applications think they're talking to a modem with RING/ATA/CONNECT/...

In case of a qemu built-in telnet client, we would provide some kind of external program that provides two telnet servers:

1. one for the qemu side to connect to, and where we emulate a basic AT command interface
2. one for the actual users to connect to, either directly via IP or indirectly from dialup via the Portmaster

I think the approach with qemu built-in telnet client with the external server makes most sense, as it offers greatest flexibility in terms of supported configurations. It also keeps things like AT command emulation out of qemu.

tnt has implemented the qemu side in https://patchwork.kernel.org/patch/11149529/ - but that patch unfortunately is still not yet merged, presumably due to a lack of tests and some other feedback raised by qemu developers. But with a custom qemu build, we could already use it here...