I've been playing with Talisman, and I'm getting some weird results
when trying to setup the doors.

My test door fails detection, and looses it's mind. (I should handle
that better). Setting up Galactic Dynasty, it also seems to lose
keys. (3-4 presses for any key prompts.) Seems to "work" better if
I time a few seconds between keystrokes, but annoying.

I'm running under Ubuntu 22.04. I know doors run fine on Smuggler's
Cove, so I'm not sure what I'm doing. I even tried wireshark to
watch the terminal and BBS traffic. The terminal is sending the
cursor position responses as expected, but my door isn't seeing them.

My debug logs show I get 2 out of 3 reponses, I get part of the 3rd
and it never completes. The rest isn't late, it just never shows up.

When running cmake, I get this:
-- Found ICONV: /usr/lib/x86_64-linux-gnu/libc.so
-- Performing Test ICONV_SECOND_ARGUMENT_IS_CONST
-- Performing Test ICONV_SECOND_ARGUMENT_IS_CONST - Failed

Is this bad/OK/normal/related to my issue?

Is it just me? Goldmine is neat, but I like local doors too. ;)

Take care,
bugz

... "Ah, the vastness of space and time... and I end up here..."
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Red-Green BBS - bbs.red-green.com (0:0/0)

When running cmake, I get this:
-- Found ICONV: /usr/lib/x86_64-linux-gnu/libc.so
-- Performing Test ICONV_SECOND_ARGUMENT_IS_CONST
-- Performing Test ICONV_SECOND_ARGUMENT_IS_CONST - Failed

Is this bad/OK/normal/related to my issue?

That's normal.

I'm running under Ubuntu 22.04. I know doors run fine on Smuggler's
Cove, so I'm not sure what I'm doing. I even tried wireshark to

Smuggler's Cove runs on Windows 10, which does doors differently to
linux. On linux doors are piped through STDIO, and talisman will convert codepages to whatever the user who logged in has their codepage set as.
whereas on windows it passes the socket.

i will have a look and see if i can figure it out

Andrew

--- Talisman v0.46-dev (Windows/x64)
* Origin: Smuggler's Cove - Private BBS (21:1/182)

I've been playing with Talisman, and I'm getting some weird results
when trying to setup the doors.

My guess is you're using door32.sys on linux. Don't do that with
talisman. Because door32.sys passes the socket, and talisman redirects
stdio instead to the socket, you get a lot of interference.

door.sys works fine on linux as well as chain.txt.

I did however see a bug in binki which i've fixed now.

Andrew


--- Talisman v0.46-dev (Windows/x64)
* Origin: Smuggler's Cove - Private BBS (21:1/182)

apam wrote to Bugz <=-

I'm running under Ubuntu 22.04. I know doors run fine on Smuggler's
Cove, so I'm not sure what I'm doing. I even tried wireshark to

Smuggler's Cove runs on Windows 10, which does doors differently to
linux. On linux doors are piped through STDIO, and talisman will

I didn't remember what I had sent you. I guess I sent the windows build
too? That would explain it! But the ANSI shows Debian, and ANSI is
never wrong. (Except when it is!)

I added some quick door.sys support, and it's working. I sure get some
weird almost working happenings with Linux/door32. :P

Ok, I was wondering about time remaining math. I see door.sys
line 18 1449 and line 19 999.

I just grabbed minutes, since that's what door32.sys gives. :O
I see 999 hard coded, Door.cpp line 494:

- f2 << "999" << LINE_END;
+ f2 << std::to_string(n->get_timeleft() / 60) << LINE_END;

convert codepages to whatever the user who logged in has their codepage set as. whereas on windows it passes the socket.

I <3 linux file descriptors, they just work and sockets have 'em. Weird windows...

i will have a look and see if i can figure it out

Thank you!

Take care,
Bugz

... "press any key to continue. release to detonate."
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Red-Green BBS - bbs.red-green.com (0:0/0)

- f2 << "999" << LINE_END;
+ f2 << std::to_string(n->get_timeleft() / 60) << LINE_END;

Thanks,

I've added this change.

Andrew


--- Talisman v0.46-dev (Windows/x64)
* Origin: Smuggler's Cove - Private BBS (21:1/182)

Hi apam,

Interesting, I changed the door32.sys dropfile like this, and it
work:

#!/bin/bash

NODE=$1
# fixup door32.sys:
sed -i '1c\0' ../temp/${NODE}/door32.sys

Replacing line 1 with "0" (local) makes my door work with door32.sys.
In local mode my door uses stdin/stdout, which is what Talisman expects.
I'm not sure if that's correct usage of door32 or not, but specs are
made to be bent/broken/redefined anyway.

Maybe "0" would be a better default under Linux?

Ok, my door32 tester passes off the connection fd as fd 3 when running
the door.

It works (for me), and there's options. ;)

Take care,
bugz

... Stand back! It's a Beta version!
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Red-Green BBS - bbs.red-green.com (0:0/0)

Bugz wrote to apam <=-

Ok, my door32 tester passes off the connection fd as fd 3 when running
the door.

Yeah, but a telnet socket and a ssh channel are completely different
animals. I should have remembered that. You can't handle them the same.
(But you'd sure like to be able to.)

Take care,
bugz

... She was only a moonshiner's daughter & I love her still.
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Red-Green BBS - bbs.red-green.com (0:0/0)

Yeah, but a telnet socket and a ssh channel are completely different animals. I should have remembered that. You can't handle them the
same.

on talisman when you connect via ssh it creates a raw loopback connection
so the socket that is passed is that socket not the ssh one.

andrew


--- Talisman v0.46-dev (Windows/x64)
* Origin: Smuggler's Cove - Private BBS (21:1/182)

On Sat Feb 4 19:00:00 2023, apam wrote to Bugz <=-

on talisman when you connect via ssh it creates a raw loopback connection
so the socket that is passed is that socket not the ssh one.

apam wrote to Bugz <=-

on talisman when you connect via ssh it creates a raw loopback
connection so the socket that is passed is that socket not the ssh one.

Ah, ok. Neat. I'll have to dig into that and see how that ticks. ;)

Last time I worked with C++ sockets, I was using ASIO. Ugh!

FYI, in go, it has interfaces (think "duck typing" in python). I wrap the channel in an object that satisfies the interface a socket has. I also do some other crazy things (like overriding the close function), so calling code can call close, but it doesn't.

That's how I got the "magic" to work with using one port for both telnet and SSH! There'd probably be a lot of patches to libssh to do similar in C++. I do patch go's ssh code, but it's just a few lines, to adjust the socket's read timeout (if the SSH handshake was successful). Otherwise,
it fails (with a timeout), tries to close and returns failure.

Take care,
Bugz

==================================
bugz
SysOp Red-Green BBS
==================================

... If it isn't broke then you're not trying.
=== TitanMail/linux v1.2.3
--- SBBSecho 3.14-Linux
* Origin: Red-Green BBS - bbs.red-green.com (0:0/0)