I've got a thing for DOS-based BBSs. And they are becoming more rare to enounter in the wild as it's becoming more difficult to run them,
particuarly since Windows has stopped suppoerting 32-bit/x86 OSs -- not to mention the risk of running outdated Windows OSs connected to the
internet - sure, you can firewall them off. But more difficult. Here's
what I've experimented with:

WINDOWS - PURE x86
I recently spun up a Windows 7 x86 box on proxmox (Renegade, PCBoard) and
it was a pretty big PitA. Do-able, and probably the most reliable way
given built-in 16-bit support, but still ponderous just getting the
thing updated with the latest patches. Win 10 32-bit is also an option,
but high overhead. Net2BBS works well.

WINDOWS 10 & 11 - x64 w/NTVDMX64
If you have a machine that can run Windows 11, I've found NTVDMX64 a
decent option, but it has its hiccups and sometimes just doesn't work
reliably. Again -- high overhead for a dedicated machine or VM. Has some
issues with the NTVDMx64 version of Net2BBS, but probably user error.

OS/2
OS/2 w/ArcaOS is def. an option given SIO's telnet ability, but
Arca is expensive and doesn't install on a lot of hardware (not to
mention Warp4 - ugh). But I think Arca is probably a path of least
resistance if you are familar with OS/2. It screams on even old Thinkpads.

DOS
Most complicated option for multinode capable BBSs. Multiple machines, or DESQVIEW, null modems, etc. But it's definitely the "purist" approach
when combined with something like NET2BBS.

LINUX
There's a perl script package (https://github.com/Geryon/TelnetBBS) that
I've had luck with, but it's not pretty. But it's functional! Don't know
if DOSBOX or DOSBOX-X or DOSBOX-STAGING resolve some of the SHARE type
issues I've seen in the past, but this might be the most future-proof
method out there. But pretty hard to run headless without X.

You could also run GAMESRV (older ubuntu only, fails on modern versions)
or something like Mystic BBS as a Telnet server that immediately loads a
DOS BBS, but I couldn't get downloads or doors to work with this method.

If you made it this far...

I'd love to have a 'modern' telnet app for linux that has a WFC screen
and handles comms -- like Net2BBS for linux -- and uses Dosemu2 (which
may have the best chance of longer term support for DOS console apps)?

Is such a thing possible? Other ways I'm missing?

Thanks retro folks :)


|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

j0HNNY a1PHA wrote to All <=-

I've got a thing for DOS-based BBSs. And they are becoming more rare to enounter in the wild as it's becoming more difficult to run them, particuarly since Windows has stopped suppoerting 32-bit/x86 OSs -- not
to mention the risk of running outdated Windows OSs connected to the internet - sure, you can firewall them off. But more difficult. Here's what I've experimented with:

Virtualization is the best of both worlds. You can run a 16-bit OS in a
secure, patched, supported 64-bit OS.

WINDOWS - PURE x86
I recently spun up a Windows 7 x86 box on proxmox (Renegade, PCBoard)
and it was a pretty big PitA. Do-able, and probably the most reliable
way given built-in 16-bit support, but still ponderous just getting the thing updated with the latest patches. Win 10 32-bit is also an option, but high overhead. Net2BBS works well.

I've been running realitycheckBBS on 32-bit Windows 10, and it's not
that bad. I had it running on an old mobile dual core laptop with 3 GB
of RAM, and it ran well. I've been thinking of moving the BBS to a
64-bit OS since I got rid of my DOS dependencies, but it works fine
as-is.



... Make a blank valuable by putting it in an exquisite frame
--- MultiMail/Win v0.52
* Origin: realitycheckBBS.org -- information is power. (21:4/122)

I've got a thing for DOS-based BBSs. And they are becoming more rare to enounter in the wild as it's becoming more difficult to run them, particuarly since Windows has stopped suppoerting 32-bit/x86 OSs -- not
to mention the risk of running outdated Windows OSs connected to the internet - sure, you can firewall them off. But more difficult. Here's what I've experimented with:

We share a predilection for DOS-based BBSes! (also I saw mention of Opus which brings back fond memories, I got started calling a couple local Opus BBSes, never ran Opus myself but did (and do) run Maximus which was heavily inspired by Opus)

I have been experimenting with DOSBox-X inside of which I run MS-DOS 6.22 and Maximus BBS software for DOS. Inside MS-DOS I am running QEMM and X00 FOSSIL driver, really replicating my 1990s setup at a software level.

Running Microsoft Network Client for DOS, a network drive is mapped to D: inside the DOS session. SHARE.EXE is loaded in config.sys and is working.

Currently I have four DOSBox-X instances, each running a node of Maximus. Two nodes are connected to USRobotics V.Everything modems using 'directserial' in DOSBox-X. The other two nodes listen for telnet connections using 'modem' in DOSBox-X. Each node has the same network drive mapped to D: and this shared drive is used for storing message and file bases, and communication between BBS nodes.

Some notes about DOSBox - there are multiple versions of DOSBox, including DOSBox Staging and DOSBox-X, many features are shared but there are also some differences particularly in which areas have been focused on for accurate emulation. Multiple forks of DOSBox are under active development, so they are all kind of a moving target.

At the time I started searching, DOSBox-X seemed to have the best support for applications and non-game use. I have been using DOSBox-X quite a lot (daily for months) and it has been working well, running MS-DOS 6.22 and QEMM memory manager and even DESQview for multitasking within a single DOSBox-X instance. (I don't run the BBS in DESQview, because separate DOSBox instances makes it easier to manage memory constraints.)

An issue I ran into with DOSBox-X is incomplete telnet support (last I checked, the other DOSBox versions had the same problem). The issue was twofold for me: 1) I didn't realize I had to specifically enable telnet mode on the 'modem' port. In DOSBox-X this is done by sending AT+NET1 - and this must be done before making/receiving a connection each DOSBox session. In some DOSBox versions there is a parameter to add to the config file to permanently enable telnet mode. If telnet mode is not enabled, then the data is sent over a raw TCP socket which will only work if the other end is using a raw socket (but mostly everyone uses telnet).

Issue 2) The telnet emulation in DOSBox only processes received telnet commands (sequences starting with a 0xFF byte) - but sent data needs to also be processed. The actual problem is that if your terminal program sends a 0xFF, in telnet mode that must be escaped with a second 0xFF but DOSBox telnet emulation doesn't do that. The symptom of this problem is that Zmodem (and any other binary protocol) uploads do not work.

I am now running a version of DOSBox-X with patches to the telnet emulation, so binary transfers work properly in both directions. I also added a 'callerid' feature so that the IP address of callers is passed to the BBS software in the same format as caller ID from a USRobotics modem.

My DOSBox-X patches haven't been submitted yet, so I mention them to raise awareness that if you run into Zmodem problems in DOSBox connecting via telnet, it is a solvable problem.

Because each node of my BBS is in its own DOSBox session and each "virtual modem" in DOSBox binds to its own port, I have a setup with node 1 on port 2301, node 2 on port 2302, node 3 on port 2303, etc. To provide one port that can accept connections and pass them to the next open node, I wrote a small "Telnet Ringdown server". The Ringdown server listens on port 23 and attempts to connect to a list of BBS ports. I am starting to work on some bot and scanner detection for the Ringdown server, to reduce the number of wasted connections to BBS nodes. (yesterday I counted 527 connections in 18 hours from IP scanners.) The Telnet Ringdown server project is at https://github.com/akacastor/ringdown

I am still configuring new things (OK so it's a BBS, I know that's endless), my plan is to run several more dialin modem nodes and more telnet nodes. Things seem fairly scalable at this point, I can spin up more DOSBox-X instances for more nodes.


Chris akacastor

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (21:2/150)

At the time I started searching, DOSBox-X seemed to have the best
support for applications and non-game use. I have been using DOSBox-X quite a lot (daily for months) and it has been working well, running MS-DOS 6.22 and QEMM memory manager and even DESQview for multitasking within a single DOSBox-X instance. (I don't run the BBS in DESQview, because separate DOSBox instances makes it easier to manage memory constraints.)

When I run DOS things in 'production' I've always found dosemu a bit more stable and usable - I run in a Linux environment, so I don't want the graphical overhead of DOSBox for things like BBS softwares...

I think in a Windows environment it might not be as valid as a point, but I like using DOSEmu/DOSEmu2 - might be worth taking a peek at.



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (21:2/150)

When I run DOS things in 'production' I've always found dosemu a bit more stable and usable - I run in a Linux environment, so I don't want the graphical overhead of DOSBox for things like BBS softwares...

I think in a Windows environment it might not be as valid as a point,
but I like using DOSEmu/DOSEmu2 - might be worth taking a peek at.

I had problems with dosemu and SHARE.EXE, but that may have been my fault or may have been fixed in the meantime.

I do like having the DOS windows open on the BBS server, as this mimics the way the BBS was run in the 90s and allows to watch caller activity and break into chat as sysop, etc. On my i7-870 (1st gen i7) running 4 DOSBox-X nodes and a few additional services it is at 50% CPU usage (with no real tweaking for performance). So the DOSBox overhead is real, but maybe not a dealbreaker with modern hardware, depending on a person's hardware and goals.


- Chris akacastor

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (21:2/150)

Running Microsoft Network Client for DOS, a network drive is mapped to
D: inside the DOS session. SHARE.EXE is loaded in config.sys and is working.

Ah, OK. Have you used EtherDFS? Don't know how reliable it is, but it's a
lot easier setup than MSFT setup (at least when using FreeDOS).

Currently I have four DOSBox-X instances, each running a node of
Maximus. Two nodes are connected to USRobotics V.Everything modems
using 'directserial' in DOSBox-X. The other two nodes listen for
telnet connections using 'modem' in DOSBox-X. Each node has the same network drive mapped to D: and this shared drive is used for storing
message and file bases, and communication between BBS nodes.

totaly makes sense. I wired up 3 FreeDOS 1.3 virtual machines in prox
mox, and created serial port connections between them.

At the time I started searching, DOSBox-X seemed to have the best
support for applications and non-game use. I have been using DOSBox-X
quite a lot (daily for months) and it has been working well, running
MS-DOS 6.22 and QEMM memory manager and even DESQview for multitasking within a single DOSBox-X instance. (I don't run the BBS in DESQview,
because separate DOSBox instances makes it easier to manage memory constraints.)

Good to know -- I wasn't sure which would be better for BBSs -- DOSBox-X
or Staging. Sounds like X is the way to go.

I am now running a version of DOSBox-X with patches to the telnet
emulation, so binary transfers work properly in both directions. I
also added a 'callerid' feature so that the IP address of callers is
passed to the BBS software in the same format as caller ID from a
USRobotics modem.

Is this something that can be shared or downloaded from a BBS? I bet the
BBS Community would love to have a build like this (with instructions,
etc.).

Because each node of my BBS is in its own DOSBox session and each
"virtual modem" in DOSBox binds to its own port, I have a setup with
node 1 on port 2301, node 2 on port 2302, node 3 on port 2303, etc.
To provide one port that can accept connections and pass them to the
next open node, I wrote a small "Telnet Ringdown server". The
Ringdown server listens on port 23 and attempts to connect to a list
of BBS ports. I am starting to work on some bot and scanner detection
for the Ringdown server, to reduce the number of wasted connections to
BBS nodes. (yesterday I counted 527 connections in 18 hours from IP scanners.) The Telnet Ringdown server project is at https://github.com/akacastor/ringdown

This was the missing piece for me. Fantastic, I'm going to check it out.
This could be a fantastic package to get multinode DOS BBSs up easier and
more securely.

I'd like to try this with FreeDOS v1.3 proxmox and avoid DOSBox
altogether, but that may be a different problem to solve :)

Thanks for this info!



|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

When I run DOS things in 'production' I've always found dosemu a bit
more stable and usable - I run in a Linux environment, so I don't want
the graphical overhead of DOSBox for things like BBS softwares...

Yeah, i try to use dosemu2 when possible.
There's less info on dosemu2 (e.g. tutorials on setting up doors) in
BBSland, but since dosemu hasn't been in the offcial repos since 18? I
think dosemu2 makes the most sense longer-term.

Maybe a good segment for TECH HEART? :)



|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

Running Microsoft Network Client for DOS, a network drive is mapped to D: inside the DOS session. SHARE.EXE is loaded in config.sys and is working.

Ah, OK. Have you used EtherDFS? Don't know how reliable it is, but it's a lot easier setup than MSFT setup (at least when using FreeDOS).

Just the other day I learned of EtherDFS - it looks very useful and definitely looks more straightforward to setup than the Microsoft Network Client (though the Microsoft Network Client is doable, it certainly isn't the lightest). I haven't tried EtherDFS, it isn't clear to me if it supports multiple simultaneous clients with SHARE.EXE etc.

There is some instability in the Microsoft Network Client for DOS - I am not sure if it is inherent to the client or if it is specific to my share configuration - after some time accessing files over the network results in "Too many files open" errors and the share must be disconnected and reconnected to fix it. My workaround has been to close/reopen the network share between BBS sessions, which 'mostly works'. I'm still working on debugging it further.

totaly makes sense. I wired up 3 FreeDOS 1.3 virtual machines in prox
mox, and created serial port connections between them.

I haven't dived into proxmox at all yet, another interesting tool to dig into sometime..

Good to know -- I wasn't sure which would be better for BBSs -- DOSBox-X or Staging. Sounds like X is the way to go.

It was a while ago when I settled on DOSBox-X, so I can't guarantee that other forks haven't caught up with it, but it does work well for me.

I am now running a version of DOSBox-X with patches to the telnet emulation, so binary transfers work properly in both directions. I also added a 'callerid' feature so that the IP address of callers is passed to the BBS software in the same format as caller ID from a USRobotics modem.

Is this something that can be shared or downloaded from a BBS? I bet the BBS Community would love to have a build like this (with instructions, etc.).

I have intended to make the DOSBox-X patches public, the holdup has just been that I wasn't sure my code is ready to send a pull request. So yes it's time for me to get off my ass and share.

I will do another cleanup pass on my DOSBox-X patches and send a pull request. If anybody wants to test it in the meantime (compiling from source), let me know and I'll hook you up with my changes.

Instructions is a piece I have on my to-do list also, I found it got pretty confusing learning about telnet vs raw socket mode and configuring DOSBox and BBS software, and then when I thought it worked there were still Zmodem issues (the incomplete telnet escaping of FF bytes).. It didn't help that DOSBox is a moving target, with documentation for different forks that sometimes are the same but sometimes have differences, and sometimes outdated documentation.

Related to this, it might be useful to include information about some common Y2K patches and fast-machine patches often required by DOS software.

scanners.) The Telnet Ringdown server project is at https://github.com/akacastor/ringdown

This was the missing piece for me. Fantastic, I'm going to check it out. This could be a fantastic package to get multinode DOS BBSs up easier and more securely.

The telnet ringdown project was just started this week, so it hasn't been thoroughly tested, and I have been adding fixes and features daily. It seems to be working well in my testing. There is a bit of cleanup to do in the source code, consider it a beta version right now.

Some simple bot detection has been added - for the first 20 seconds of the connection or until Escape is pressed (while the front-end mailer prompt is displayed), the ringdown server monitors data sent by the client to see if it's an obvious bot login attempt like 'root' or 'admin'. If the client sends suspicious strings then a 5 minute ban is placed on their IP.

I'd like to try this with FreeDOS v1.3 proxmox and avoid DOSBox altogether, but that may be a different problem to solve :)

Finding weird problems to solve is why we are here, I guess. :)

I looked a bit at 86box, that is kind of going in the other direction though, lower level emulation so a bit heavier load. 86box looks like a great option for an accurate DOS environment, but it doesn't have a telnet softmodem built in so would need that added, or a workaround. I do like the low level emulation of 86box, when I run into an issue in DOSBox I have been sanity checking by testing in 86box to see if it is broken DOS software or an emulation issue.


Chris akacastor

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (21:2/150)

Re: Re: Future-proofing DOS BBSs
By: akacastor to j0HNNY a1PHA on Thu Feb 15 2024 13:19:20

Running Microsoft Network Client for DOS, a network drive is mapped to D:

Currently I have four DOSBox-X instances... Each node has the same
network drive mapped to D: and this shared drive is used for storing message and file bases, and communication between BBS nodes.

I am curious what is serving that network drive?

I have been fantasizing about a similar configuration using ProBoard as
the BBS software.

Someone mentioned EtherDFS. Reading the protocol documentation, i see it
has support for locking regions within a file.

Thanks for your notes about DOSBox-X. I will be interested to see those patches when you publish them.

-Ben
--- SBBSecho 3.20-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (21:2/101)

Re: Re: Future-proofing DOS BBSs
By: j0HNNY a1PHA to akacastor on Fri Feb 16 2024 15:19:07

Ah, OK. Have you used EtherDFS? Don't know how reliable it is, but
it's a lot easier setup than MSFT setup (at least when using FreeDOS).

I scanned ethersrv-linux.c and found that file locking is a NOP.
If i understand correctly, this means that EtherDFS is NOT suitable for communication between multiple concurrent BBS nodes if they rely on
SHARE.EXE style locking.

```
} else if ((query == AL_LOCKFIL) || (query == AL_UNLOCKFIL)) { /* 0x0A / 0x0B */
/* I do nothing, except lying that lock/unlock succeeded */
```

-Ben
--- SBBSecho 3.20-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (21:2/101)

message and file bases, and communication between BBS nodes.

I am curious what is serving that network drive?

It's a Samba share in Ubuntu 20 - took a bit of trial and error to get it configured to allow an old enough protocol to be compatible with the DOS client, but it does seem to work well. (aside from an ongoing issue where after some time accesses will fail with 'Too many open files' until I remount the drive)

Been a while since I set it up, but from what I remember the key points were:

- creating a user and password for the samba share (I think I used smbpasswd for this)

- setup in [global] section of /etc/samba/smb.conf
client max protocol = SMB3
client min protocol = CORE
min protocol = CORE
max protocol = SMB3
lanman auth = yes
client lanman auth = yes
client plaintext auth = yes
ntlm auth = yes

- add a share to the end of /etc/samba/smb.conf
[dosshare]
comment = dos share
path = /home/dosbox/share
browseable = yes
read only = no
guest ok = no
create mask = 0776
force create mode = 0776
security mask = 0776
force security mode = 0776
directory mask = 0777
force directory mode = 0777
directory security mask = 0777
force directory security mode = 0777

I am not sure if every setting I mention in smb.conf is necessary, but this is where I got to with it working.

On the client side - Microsoft Network Client 3.0 - I had to install TCP/IP (it only had NetBEUI by default). In AUTOEXEC.BAT a pile of stuff is run:

net initialize
netbind.com
umb.com
tcptsr.exe
tinyrfc.exe
emsbfr.exe
net start
net logon USER PASS
net use D: \\servername\dosshare

On boot it gets an IP address via DHCP, but I have had somewhat mixed results with being able to mount shares by the server name. Usually it works but a couple times I have set it up and had trouble with name resolution. To solve this I added my server name and IP to LMHOSTS in the Microsoft Network Client directory.

SHARE.EXE locking seems to work, and as a bonus I am able to access the share from my other computers to conveniently edit/move files around, etc.

I have been fantasizing about a similar configuration using ProBoard as the BBS software.

I'd love to check that out!

Thanks for your notes about DOSBox-X. I will be interested to see those patches when you publish them.

Now that I mentioned them I will have to get off my ass and publish them ASAP!


akacastor

--- Maximus 3.01
* Origin: Another Millennium - Canada - another.tel (21:1/162)

I had problems with dosemu and SHARE.EXE, but that may have been my
fault or may have been fixed in the meantime.

I do like having the DOS windows open on the BBS server, as this mimics the way the BBS was run in the 90s and allows to watch caller activity
and break into chat as sysop, etc. On my i7-870 (1st gen i7) running 4 DOSBox-X nodes and a few additional services it is at 50% CPU usage
(with no real tweaking for performance). So the DOSBox overhead is real, but maybe not a dealbreaker with modern hardware, depending on a
person's hardware and goals.

Well I'm glad yer here and having fun w/ bbSes in 2024 aka... let us know if you prop that system online so I can make a user account. :P Nothing like fun w/ retro programs in the current day and age!



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (21:2/150)

Just the other day I learned of EtherDFS - it looks very useful and definitely looks more straightforward to setup than the Microsoft
Network Client (though the Microsoft Network Client is doable, it
certainly isn't the lightest). I haven't tried EtherDFS, it isn't
clear to me if it supports multiple simultaneous clients with
SHARE.EXE etc.

So it sounds like etherdfs doesn't support SHARE file locking, that's
good to know. I was hoping to use FDNET (instead of MSCLIENT), but
based on file locking needs, going to adjust my plans!

Here's my new approach using my local proxmox for all the VMs:

1. Want to test your Ringdown to handle incomoing connections on a
dedicated linux machine to handle incoming (and SMB file share). I was
thinking about HAPROXY approach but I love what you are doing with bot detection!

2. 4x FreeDOS v1.3 VMs, each with own IP under MSCLIENT, etc.

3. Multi-node capable DOS BBS running on each FreeDOS machine (Renegade or Iniquity or PCBOARD)

4. RLFOSSIL - a shim program to allow each BBS node to accept incoming
telnet connections.

Item 5 is now my biggest question mark, I read in forums that it works suprisingly well, but curious how reliable it is.

I had a similar setup earlier this year, but I was using SOCAT to do
null-modem stuff and it was very brittle, as I had written my own telnet
server to handle incoming connections and manage routing (in Go) which
just wasn't very good :(

Cheers and thanks again for all the great info, especially the MSCLIENT
configs you posted.

|08.|05j|13A|08.


--- Talisman v0.53-dev (Linux/x86_64)
* Origin: R3tr0/X BBS :: retrox.us:1992 (21:4/158)

Well I'm glad yer here and having fun w/ bbSes in 2024
aka... let us know if you prop that system online so I
can make a user account. :P Nothing like fun w/ retro
programs in the current day and age!

Thanks Paulie, yeah it's a great time for sure! My BBS is currently in 'mostly running but regular random shutdowns' as I work out configuration issues and test automation and resiliency - so I consider it to be 'pre-release' still - looking at April 20th as the Grand Opening (a good day for a celebration). If you're interested in checking out the progress, it is usually online at another.tel port 23. You can also be assured that I will flood you with posts about it being 'fully open' in the future. ;)


akacastor

--- Maximus 3.01
* Origin: Another Millennium - Canada - another.tel (21:1/162)

So it sounds like etherdfs doesn't support SHARE file locking, that's
good to know. I was hoping to use FDNET (instead of MSCLIENT), but
based on file locking needs, going to adjust my plans!

The SHARE locking is for sure a deal breaker, I am still curious about EtherDFS - it wasn't abandoned decades ago, so may be our best hope for better network file sharing in DOS over the longer term. I've never implemented network file sharing drivers etc, so I am not sure how complex it will be to add file locking. Definitely gotta keep it on the radar!

1. Want to test your Ringdown to handle incomoing connections on a dedicated linux machine to handle incoming (and SMB file share). I was thinking about HAPROXY approach but I love what you are doing with bot detection!

There could be a lot more directions to go with bot detection, it's an interesting problem. The detection currently is pretty simple but seems to have mostly solved the annoyances for me. I'd like to keep false positives to a minimum, I know in the past when I've unknowingly triggered an IP ban while testing different clients it has been frustrating as a caller. But man oh man are there are alot of bot connections if you do nothing at all!

2. 4x FreeDOS v1.3 VMs, each with own IP under MSCLIENT, etc.

I haven't run the MSCLIENT inside FreeDOS but otherwise that is similar to my setup. (and a bunch of networked DOS machines is accurate to 90s BBSes - if only I could afford a network at the time. or more than one computer.)

3. Multi-node capable DOS BBS running on each FreeDOS machine (Renegade or Iniquity or PCBOARD)

Inquity I am not familiar with, but based on the other two you have fine taste in DOS BBS software.

4. RLFOSSIL - a shim program to allow each BBS node to accept incoming telnet connections.

Since I am running the BBS inside DOSBox and using the telnet modem emulation built into DOSBox, I am running a 'regular' FOSSIL driver (X00 or BNU) to access "COM1" which DOSBox transparently manages as a telnet modem.

On my system I don't have a packet driver installed in DOS because it would conflict with the MSCLIENT networking.

I had a similar setup earlier this year, but I was using SOCAT to do null-modem stuff and it was very brittle, as I had written my own telnet server to handle incoming connections and manage routing (in Go) which just wasn't very good :(

My Telnet Ringdown server project has an amateur sheen to it too. I have only minimally dabbled in sockets and pthreads so I am learning on the job here. :)


akacastor

--- Maximus 3.01
* Origin: Another Millennium - Canada - another.tel (21:1/162)

Thanks Paulie, yeah it's a great time for sure! My BBS is currently in 'mostly running but regular random shutdowns' as I work out
configuration issues and test automation and resiliency - so I consider
it to be 'pre-release' still - looking at April 20th as the Grand
Opening (a good day for a celebration). If you're interested in
checking out the progress, it is usually online at another.tel port 23. You can also be assured that I will flood you with posts about it being 'fully open' in the future. ;)

Alright - I'll be heading over sometime soon!! :P



|07p|15AULIE|1142|07o
|08.........

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: 2o fOr beeRS bbS>>20ForBeers.com:1337 (21:2/150)