Subj : Strange rlogin.js behavior
To   : Greyb34rd
From : Digital Man
Date : Thu Sep 12 2024 10:11 pm

  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
 >
 >  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
 >  DM> 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';

 >  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
 >  DM> rlogin gateway provided: The Telnet connection is not in "binary mode"
 >  DM> (normally used for file transfers) and the TG_PASSTHRU telget gateway
 >  DM> mode flags is 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.

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.

 >  DM> If you want confirm this translation of CRLF->CR is actually happening
 >  DM> (on the server that's executing the rlogin.js), you can change this
 >  DM> line in 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
 >  DM> info-level log message that says something to the effect of "CR/0A
 >  DM> 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

.