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
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net
