I'm having an odd issue with rlogin.js.

Years ago I set up Synchronet (3.18) on Windows 7 as a game server, on my internal network. Since then I've only connected to it from a Mystic BBS and it's worked great.

Recently I've been working on Synchronet (last pull from git was just a couple days ago) running on Debian 11.9.

I'm able to make a rlogin connection fine via rlogin.js; however, I'm having an odd issue with CR/LF. Whenever I press the "Enter" key, extra characters are being sent making it impossible to use/play the remote door game.

LORD for example, behaves like below:

What would you like as an alias?
Name: Bob
Bob? [Y] : .
What would you like as an alias?

So when hitting enter, an extra "." is being sent.

My connection under Online Programs looks like this:

Name: LORD 4.06
Internal Code: NHLORD406
Start-up Directory:
Command Line: ?rlogin <internal IP> -c [v01d]@NODE_USER@ -t xtrn=lrd406 (everything else is default)

Anyone have any ideas what might be going on or what I should check?

Thank you for any suggestions
Travis

---
■ Synchronet ■ v01d c1ph3r - void.canerduh.com:23443

Re: Strange rlogin.js behavior
By: Greyb34rd to All on Mon Sep 09 2024 04:00 pm

I'm having an odd issue with rlogin.js.

Years ago I set up Synchronet (3.18) on Windows 7 as a game server, on my internal network. Since then I've only connected to it from a Mystic BBS and it's worked great.

Recently I've been working on Synchronet (last pull from git was just a couple days ago) running on Debian 11.9.

I'm able to make a rlogin connection fine via rlogin.js; however, I'm having an odd issue with CR/LF. Whenever I press the "Enter" key, extra characters are being sent making it impossible to use/play the remote door game.

Okay, so you're connecting from a Telnet client to a Synchronet v3.20 server and then gatewaying (via rlogin.js) to a Synchronet v.318 server? Just to clarify the configuration.

As for the "extra characters", most likely, it's a line-feed (ASCII 10) character. Telnet clients normally send CR/LF (0x0D, 0x0A) any time the ENTER key is pressed. You can use any network packet capture utility/program to confirm that. Those Telnet CRLF's normally should be translated by Synchronet to just a CR (carriage-return) sent to the rlogin gateway provided: The Telnet connection is not in "binary mode" (normally used for file transfers) and the TG_PASSTHRU telget gateway mode flags is not used.

What revision is the rlogin.js file you're using?

If you want confirm this translation of CRLF->CR is actually happening (on the server that's executing the rlogin.js), you can change this line in main.cpp:
#if 0 /* Debug CR/LF problems */

to this:
#if 1 /* Debug CR/LF problems */

And then for any received CR/LF combination, you should see an info-level log message that says something to the effect of "CR/0A detected and ignored" in your server log output.

LORD for example, behaves like below:

What would you like as an alias?
Name: Bob
Bob? [Y] : .
What would you like as an alias?

So when hitting enter, an extra "." is being sent.

It's likely the Telnet client is not actually sending a '.' character, but rather that's just what LORD happens to echo-back to the user for unsupported/recognized input characters.

My connection under Online Programs looks like this:

Name: LORD 4.06
Internal Code: NHLORD406
Start-up Directory:
Command Line: ?rlogin <internal IP> -c [v01d]@NODE_USER@ -t xtrn=lrd406 (everything else is default)

Anyone have any ideas what might be going on or what I should check?

There have been big changes in the telnet/rlogin gateway recently (mainly for better support of Telnet servers that are the destination of the gateway), so it's possible there was a regression somewhere. So I'd like to help you get to the bottom of it.
--
digital man (rob)

Synchronet "Real Fact" #87:
Synchronet Message Base and its library, SMBLIB, was used by AXiS BBS Software Norco, CA WX: 93.6°F, 23.0% humidity, 8 mph W wind, 0.00 inches rain/24hrs
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Strange rlogin.js behavior
By: Digital Man to Greyb34rd on Mon Sep 09 2024 07:06 pm

Okay, so you're connecting from a Telnet client to a Synchronet v3.20 server and then gatewaying (via rlogin.js) to a Synchronet v.318 server? Just to clarify the configuration.

Yes this is correct. And for further clarity, the behavior is the same with Telnet or SSH, and with SyncTerm, IcyTerm and Netrunner.

As for the "extra characters", most likely, it's a line-feed (ASCII 10) character. Telnet clients normally send CR/LF (0x0D, 0x0A) any time the ENTER key is pressed. You can use any network packet capture utility/program to confirm that. Those Telnet CRLF's normally should be translated by Synchronet to just a CR (carriage-return) sent to the rlogin gateway provided: The Telnet connection is not in "binary mode" (normally used for file transfers) and the TG_PASSTHRU telget gateway mode flags is not used.

What revision is the rlogin.js file you're using?

Apologies as my git skills are pretty low. But it's the same as the latest revision in the gitlab repo, with a SHA commit of: e5eca8bc43ad91d3a5ab0debee5515cf055efb1e if that helps at all.

If you want confirm this translation of CRLF->CR is actually happening (on the server that's executing the rlogin.js), you can change this line in main.cpp: #if 0 /* Debug CR/LF problems */

to this:
#if 1 /* Debug CR/LF problems */

And then for any received CR/LF combination, you should see an info-level log message that says something to the effect of "CR/0A detected and ignored" in your server log output.

I believe I've done this, and I ran cleanall.sh and recompiled (make install SYMLINK=1). I then restarted sbbs but I'm not sure where I should be seeing the info-level log message.

I looked under data/logs, as well as error.log, or should I be checking the node.log while I'm connected. (Sorry for being a pain.)

It's likely the Telnet client is not actually sending a '.' character, but rather that's just what LORD happens to echo-back to the user for unsupported/recognized input characters.

This makes sense because Usurper behaves differently but still oddly.

There have been big changes in the telnet/rlogin gateway recently (mainly for better support of Telnet servers that are the destination of the gateway), so it's possible there was a regression somewhere. So I'd like to help you get to the bottom of it.

I really appreciate this and will do whatever I can to help out!

---
■ Synchronet ■ v01d c1ph3r - void.canerduh.com:23443

Re: Strange rlogin.js behavior
By: Greyb34rd to Digital Man on Thu Sep 12 2024 07:00 pm

Re: Strange rlogin.js behavior
By: Digital Man to Greyb34rd on Mon Sep 09 2024 07:06 pm

Okay, so you're connecting from a Telnet client to a Synchronet v3.20 server and then gatewaying (via rlogin.js) to a Synchronet v.318 server? Just to clarify the configuration.

Yes this is correct. And for further clarity, the behavior is the same with Telnet or SSH, and with SyncTerm, IcyTerm and Netrunner.

Interesting. I assume it happens when using RLogin from those terminals (that support it) too?

The telnet/rlogin gateway code does have a mode that can expand CR to CRLF (it's called TG_CRLF), but it's not enabled by default in any script accept mudgate.js. You're not using mudgate.js by any chance, are you?

If you're not, and you're not passing TG_CRLF on the rlogin.js command-line, you can try disabling this feature in the source code by removing or commenting out the following lines from telgate.cpp to see if the behavior changes:
if((mode&TG_CRLF) && buf[rd-1]=='\r')
buf[rd++]='\n';

As for the "extra characters", most likely, it's a line-feed (ASCII 10) character. Telnet clients normally send CR/LF (0x0D, 0x0A) any time the ENTER key is pressed. You can use any network packet capture utility/program to confirm that. Those Telnet CRLF's normally should be translated by Synchronet to just a CR (carriage-return) sent to the rlogin gateway provided: The Telnet connection is not in "binary mode" (normally used for file transfers) and the TG_PASSTHRU telget gateway mode flags is not used.

What revision is the rlogin.js file you're using?

Apologies as my git skills are pretty low. But it's the same as the latest revision in the gitlab repo, with a SHA commit of: e5eca8bc43ad91d3a5ab0debee5515cf055efb1e if that helps at all.

That commit is from August 12. It might be worth updating your code and rebuilding, just in case it's something that's already been addressed.

If you want confirm this translation of CRLF->CR is actually happening (on the server that's executing the rlogin.js), you can change this line in main.cpp: #if 0 /* Debug CR/LF problems */

to this:
#if 1 /* Debug CR/LF problems */

And then for any received CR/LF combination, you should see an info-level log message that says something to the effect of "CR/0A detected and ignored" in your server log output.

I believe I've done this, and I ran cleanall.sh and recompiled (make install SYMLINK=1).

make install SYMLINK=1 is not the correct "recompile" command-line. That's the command-line used for a fresh/original install. See https://wiki.synchro.net/install:nix#updating for the correct "recompile" command line, depending on your situation.

I then restarted sbbs but I'm not sure where I should be seeing
the info-level log message.

If you're running sbbs daemonized, then most likely it'd go wherever your syslog output goes:
https://wiki.synchro.net/monitor:syslog

I looked under data/logs, as well as error.log, or should I be checking the node.log while I'm connected. (Sorry for being a pain.)

Server log output goes through syslog on *nix when running sbbs daemonized (e.g. as a systemd service) or with the 'syslog' command-line option.
--
digital man (rob)

Synchronet "Real Fact" #78:
Synchronet Match Maker had at one time over 4000 profiles of men and women Norco, CA WX: 64.2°F, 81.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net