Subj : Strange rlogin.js behavior
To : Digital Man
From : Greyb34rd
Date : 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
DM> Okay, so you're connecting from a Telnet client to a Synchronet v3.20
DM> server and then gatewaying (via rlogin.js) to a Synchronet v.318 server?
DM> 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.
DM> As for the "extra characters", most likely, it's a line-feed (ASCII 10)
DM> character. Telnet clients normally send CR/LF (0x0D, 0x0A) any time the
DM> ENTER key is pressed. You can use any network packet capture
DM> utility/program to confirm that. Those Telnet CRLF's normally should be
DM> translated by Synchronet to just a CR (carriage-return) sent to the rlogin
DM> gateway provided: The Telnet connection is not in "binary mode" (normally
DM> used for file transfers) and the TG_PASSTHRU telget gateway mode flags is
DM> not used.
DM> 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.
DM> If you want confirm this translation of CRLF->CR is actually happening (on
DM> the server that's executing the rlogin.js), you can change this line in
DM> main.cpp: #if 0 /* Debug CR/LF problems */
DM> to this:
DM> #if 1 /* Debug CR/LF problems */
DM> And then for any received CR/LF combination, you should see an info-level
DM> log message that says something to the effect of "CR/0A detected and
DM> 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.)
DM> It's likely the Telnet client is not actually sending a '.' character, but
DM> rather that's just what LORD happens to echo-back to the user for
DM> unsupported/recognized input characters.
This makes sense because Usurper behaves differently but still oddly.
DM> There have been big changes in the telnet/rlogin gateway recently (mainly
DM> for better support of Telnet servers that are the destination of the
DM> gateway), so it's possible there was a regression somewhere. So I'd like
DM> to help you get to the bottom of it.
I really appreciate this and will do whatever I can to help out!
