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!

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

.