Project

General

Profile

Feature #4341

setup for telnet access to legacy BBSs

Added by laforge 9 months ago. Updated 9 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
01/01/2020
Due date:
% Done:

0%

Spec Reference:

Description

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...

History

#1 Updated by keith 9 months ago

laforge wrote:

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/...

Is that what tcpser does?

#2 Updated by keith 9 months ago

UPDATE: seems to have potential to work...

I'm running FRONT DOOR and X00 in dosemu with
$_com2 = "/dev/tnt0" in /etc/dosemu/dosemu.conf

Then tcpser -d /dev/tnt1

FD initialises the "modem" fine, and when I telnet to localhost 6400, I get RING, FD sends ATA, tcpser sends back CONNECT 38400, and FD says Carrier Detected. So far nothing else happens there. I think FD is waiting for a signal for a fido mailer to id itself, or for the dialling in user to press some key that I can't remember what it is, what's weird is I'm not seeing anything from FD on the com port after carrier detected and it doesn't seem to be receiving.
If I tell FD to hang up, the AT sequence works fine.

I can see all I type in tcpser's trace output.
Maybe something to do with the fossil, I'll play with locked baud rate..

#3 Updated by keith 9 months ago

It seems that FrontDoor does not like the CONNECT 38400 coming "immediately" after DCD going high.

I added a sleep(1) and now it works.

diff --git a/src/modem_core.c b/src/modem_core.c
index 222f58e..26c8135 100644
--- a/src/modem_core.c
+++ b/src/modem_core.c
@@ -243,6 +243,7 @@ int mdm_answer(modem_config *cfg)
     cfg->conn_type = MDM_CONN_INCOMING;
     mdm_off_hook(cfg);
     mdm_set_control_lines(cfg);
+    sleep(1);
     mdm_print_speed(cfg);
   }
   else if (cfg->conn_type == MDM_CONN_INCOMING) {

(this version): https://github.com/FozzTexx/tcpser

tcpser also works nicely the other way round so that one can use a terminal comms program to telnet to the BBS.

tcpser -d /dev/tnt2 -n111=localhost:6400 -p 2323 -s 38400
minicom -D /dev/tnt3 -c on -b38400

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)