It appears telnet access to my board is bolloxed. I can log in locally, but
any attempt at telnet access even from the local network direct to the Pi's IP is dropped immeidately. mis.log shows only:

+ 2019.01.08 11:13:00 TELNET > Connect on slot 1/4 (10.10.10.101)
+ 2019.01.08 11:13:00 TELNET 1-HostName Unknown
+ 2019.01.08 11:13:00 TELNET 1-Creating terminal process
+ 2019.01.08 11:13:01 TELNET 1-Closing terminal process

The telnet server configuration hasn't changed recently.

Active: Yes
ID: TELNET
Adapter Type: IPv4+IPV6
IPV4 Adapter: 0.0.0.0
IPV6 Adapter: ::
Port: 2323
Max Allowed: 4
Auto IP Ban: 4 in 120 secs
Country Block: No
Send Blocked: No
Dup IP Limit: 1

Ideas?

_ __ _ __ _ _ __ jenandcal.familyds.org
\|/ |_|| ||\/|/ \|\ |/__/ \| |(_ \|/ |_)|_)(_ Telnet:2323 SSH:2222
/|\ | ||_|| |\_/| \|\_|\_/|_|__) /|\ |_)|_)__) Sysop: Nathanael Culver
* Message Boards * * Door Games * * File Downloads * MysticBBS 1.12 A41

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

* An ongoing debate between nathanael and All rages on ...

IPV4 Adapter: 0.0.0.0

Set this? Mine is ...


.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet|ssh://cmech.dynip.com |
| |
| vvvvvv Email: fido4cmechSPAM(at)lusfiberBLOCK.net |
| { O O } Home page: http://cmech.dynip.com/homepage/ |
| __m___oo___m__ |
`--| | | |-- -------------------------------------------------'

... It's hard to appreciate nostalgia when you can't remember it...
--- GoldED+/W32-MSVC v1.1.5-g20180902 + MIS v1.12 A42 2018/12/30 23:39:36
* Origin: FSXNet - Positronium: telnet://cmech.dynip.com (21:2/117)

IPV4 Adapter: 0.0.0.0

Set this? Mine is ...

It can be left as 0.0.0.0 unless you're running on a multi homed server or a server with multiple connections and you want to specify which one to bind to.

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Fusion BBS ~ Newcastle, Australia (21:4/132)

I tried to connect to your bbs and got "BUSY"

I can't remember the fix for it.

Try shutting down your BBS and deleting all the .bsy files in the semaphore directory.

Someone smarter than me will have the exact answer.

--- Mystic BBS v1.12 A39 2018/04/21 (Raspberry Pi/32)
* Origin: Fusion BBS ~ Newcastle, Australia (21:4/132)

On 08 Jan 2019, nathanael pondered and said...

It appears telnet access to my board is bolloxed. I can log in locally, but any attempt at telnet access even from the local network direct to
the Pi's IP is dropped immeidately. mis.log shows only:

+ 2019.01.08 11:13:00 TELNET > Connect on slot 1/4 (10.10.10.101)
+ 2019.01.08 11:13:00 TELNET 1-HostName Unknown
+ 2019.01.08 11:13:00 TELNET 1-Creating terminal process
+ 2019.01.08 11:13:01 TELNET 1-Closing terminal process

The telnet server configuration hasn't changed recently.
Active: Yes
ID: TELNET
Adapter Type: IPv4+IPV6
IPV4 Adapter: 0.0.0.0
IPV6 Adapter: ::
Port: 2323
Max Allowed: 4
Auto IP Ban: 4 in 120 secs
Country Block: No
Send Blocked: No
Dup IP Limit: 1

I also tried to connect at got the BUSY message. So that tells me the total number of available connections to your server is used up.

I'd try a a few things.

Set Dup IP to 0, Raise Max Allowed to 8

Head to mystic -cfg > servers > general options > max BBS nodes and raise
that value by 6-8

Also run nodespy and look to see if the current telnet nodes are in fact tied up. If they are, but they really should not be, press enter on the node and choose 'kill ghost' to free the node(s)

° Ý °° þ Þßßßßßßßßßßßßß ß Node Spy ß
Ä ### ÄÄ User ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÛßßßßßßßßßßßßßßßßßßßßÜÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1 Avon Û S Snoop Û
2 Waiting Û C User Chat Û
3 Waiting Û K Kick User Û
4 Waiting Û G Kill Ghost Û
5 Waiting ßÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÛ

Be sure to shut down mis and restart after you make the changes suggested above.

How many other servers have you enabled, and what number of Maximum
concurrent connections have you set for each? Be sure to provision a total number of max BBS nodes to accommodate the values you set/spread across your assorted servers you have running.


ÄÄÄÄ Eùavon@bbs.nz ÄÄÄÄÄÄ Wùbbs.nz ÄÄÄ ÄÄÄÄ Kùkeybase.io/avon ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 08 Jan 2019, Michael Borthwick pondered and said...

Set this? Mine is ...

It can be left as 0.0.0.0 unless you're running on a multi homed server
or a server with multiple connections and you want to specify which one
to bind to.

Correct leaving it as 0.0.0.0 will allow Mystic to use the available
resources of the box unless you want to force a specific adapter to use (IPv4 and/or IPv6)

:)


ÄÄÄÄ Eùavon@bbs.nz ÄÄÄÄÄÄ Wùbbs.nz ÄÄÄ ÄÄÄÄ Kùkeybase.io/avon ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 08 Jan 2019, Michael Borthwick pondered and said...

I tried to connect to your bbs and got "BUSY"

I can't remember the fix for it.

Try shutting down your BBS and deleting all the .bsy files in the semaphore directory.

The files in the semaphore directory are used for the various programs like
mis and fidopoll to let other Mystic programs know they are running. Removing them would not help this particular problem but may cause some others if the system is running.

From some old notes I found this

[snip]

BUSY NOTIFICATIONS
==================

If a connection is made when all of the nodes configured for telnet are
being used, MIS will attempt to send them the contents of busy.txt from
the Mystic DATA directory. If this file does not exist, it will simply
print "BUSY" to the terminal and disconnect them.

[snip]

Best, Paul


ÄÄÄÄ Eùavon@bbs.nz ÄÄÄÄÄÄ Wùbbs.nz ÄÄÄ ÄÄÄÄ Kùkeybase.io/avon ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I also tried to connect at got the BUSY message. So that tells me the total number of available connections to your server is used up.

In Unix this can also happen when there is an access (ownership) issue as
well.

--- Mystic BBS v1.12 A42 2018/12/31 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

In Unix this can also happen when there is an access (ownership) issue as

Is that what's going on? This happen to me a few weeks back and after struggling with it for a day or two, I simply reinstalled from scratch.

Yesterday it happened again, so I've spent probably twenty hours over the
past couple of days rebuilding again. Do you have more details on what exactly the ownership might be? It'd probably be a two-minute fix.

'Course, I've reinstalled so many times at this point I think I could
blow through Avon's vids in fifteen minutes flat :-)

+=======================+ +=========+ ---------------------------------------
| *:H:U:M:O:N:G:O:U:S:* | | :B:B:S: | nathanael : jenandcal.familyds.org:2323 +=======================+ +=========+ ---------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

In Unix this can also happen when there is an access (ownership) issu

Is that what's going on? This happen to me a few weeks back and after struggling with it for a day or two, I simply reinstalled from scratch.

Yeah I think so.

If my memory serves me when Mystic tries to calculate an available node number it ultimately ends up unable to do so if the accesses/ownerships are wrong
so the end result is a "BUSY" message.

Another cause of it could be if Mystic is killed in a non-graceful way (like a kill -9 or a bad crash or something) so that it can't properly shut down. What happens is you get a "ghost node" where Mystic thinks a user is logged in when they actually aren't. Considering your issues with CTRL-C maybe this could have been the issue too.

The two ways to fix the ghost nodes is you can run the following command recommended only when no users are logged in to reset all node data:

sudo rm /mystic/data/node*.dat

Or you can load "./nodespy" and look at the who's online list. If there
are ghost users online, press enter on the node and you will have the option
to kill the ghost node.

--- Mystic BBS v1.12 A42 2019/01/23 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Another cause of it could be if Mystic is killed in a non-graceful way

Well this could be me. I've got a homebrew bash script which autostarts
mis, nodespy and the client, and can autoshutdown everything, too. I
run mis -shutdown on the server, but I'm not aware of any way to
gracefully shutdown the client from a command line. Is there a
-shutdown equivalent? ATM I'm just doing a tmux kill-session.

The issue is occrring again. But nodespy only shows one node in use, nor do I see any /mystic/data/node*.dat.

+=======================+ +=========+ ---------------------------------------
| *:H:U:M:O:N:G:O:U:S:* | | :B:B:S: | nathanael : jenandcal.familyds.org:2323 +=======================+ +=========+ ---------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Been doing a bit more playing around.

Turns out Mystic is behaving as if only one connection at a time is allowed: whether local or remote, if I've got one connection, all others get dropped until I log out of the first.

I've got Max BBS Nodes set to 8, and the telnet server Max Allowed also set to 8. Nodespy shows me logged into 1, and 2-8 waiting. But I can still only do
one connection at time. Is there another setting somewhere I'm missing?

+=======================+ +=========+ ---------------------------------------
| *:H:U:M:O:N:G:O:U:S:* | | :B:B:S: | nathanael : jenandcal.familyds.org:2323 +=======================+ +=========+ ---------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Well this could be me. I've got a homebrew bash script which autostarts mis, nodespy and the client, and can autoshutdown everything, too. I

Do you start these as root? All of mystic, mis, and nodespy will change out of whatever you start it as to the owner of the executable on startup. Maybe there is something weird going on with access.

I'll have to look at the code to see exactly what its doing. Maybe there is a way to give a better description. I tried to intentionally leave the messages vague while calculating the node number, for those people that might use Mystic as a shell replacement. But maybe I can log some more detail to errors.log.

The issue is occrring again. But nodespy only shows one node in use, nor do I see any /mystic/data/node*.dat.

It sounds like the issue is not a ghosted node then, maybe an access/ownership issue.

--- Mystic BBS v1.12 A42 2019/01/23 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Do you start these as root?

No, as the defaul user pi.

It sounds like the issue is not a ghosted node then, maybe an access/ownership issue.

Yeah, something. The following may be a repeat, but with all the
reinstalling, I don't know if things got out.

With Nodespy showing only one of eight nodes active, I was only permitted a single connection. If I were logged on locally then tried to telnet in, I'd
get dropped, or vice versa. There were no /mystic/data/node*.dat.

I reinstalled again today (I'm getting quite good at it :-).

Question: is there a graceful way to tell the client to shut down gracefully from the command line, a la mis -shutdown? Or maybe sending it a SIGTERM?

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Do you start these as root? All of mystic, mis, and nodespy will change out of whatever you start it as to the owner of the executable on
startup. Maybe there is something weird going on with access.

FWIW, this has never fully worked for me. For example, it allegedly drops to
my standard user after owning the ports, but then trying to do something like run a dos door will fail because it's trying to run dosemu as root. So, I
think there is still a fair bit of nuance here.

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)

Do you start these as root?

No, as the defaul user pi.

Okay, Mystic is designed to be started as root and it switches to the user/group that owns the executable. So you want to make sure that everything in the Mystic folder is owned by the Pi user and then it should be started as root. There are ways around that, but that is the way its designed to work.

Its difficult for me to assess anything without knowing how you're starting things up and seeing logs but you could try to chown the entire mystic directory to the Pi user. I think you mentioned slowness and pausing in some places in the past and that is exactly what happens when access and ownership is wrong because Mystic is trying over and over again to access things but it can't and eventually gives up.

--- Mystic BBS v1.12 A42 2019/01/25 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

FWIW, this has never fully worked for me. For example, it allegedly
drops to my standard user after owning the ports, but then trying to do something like run a dos door will fail because it's trying to run
dosemu as root. So, I think there is still a fair bit of nuance here.

I just ran a quick test by running ./mystic and ./mis and ./mide all as sudo.

Looking at TOP, Mystic and MIS show running as the bbs user while mide (which doesn't do the drop access) shows running as root.

If you have any ideas of how to reproduce an issue let me know. I wonder if it could be related to how its started up? Do you start it automatically on boot or anything? Does TOP show it running as root?

I remember dosemu complaining in the past because its NOT running as root but its been so long since I've tried to set it up. I am planning to move my BBS to a Linux laptop as soon as I can find the time, so hopefully that will give me some more time on the Linux side to notice things that need to be cleaned
up or changed.

--- Mystic BBS v1.12 A42 2019/01/31 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)