Subj : telnet_gate
To : Hemo
From : Digital Man
Date : Tue Sep 19 2000 02:28 pm
RE: telnet_gate
BY: Hemo to Digital Man on Sun Sep 17 2000 09:13 pm
> well, I think I have found the problem. This problem can actually be
> dupliacted if you try using telnet_gate into just about any *nix telnetd
> server, and the problem may be simple or not so simple to correct.
I have used telnet_gate to connect to my Linux box, and did _not_ have the
problem mentioned.
> I'm just thinking out loud here, so don't take this as gospel, and correct m
> where I am wrong, please. (Rob)
>
> Synchronet's telnet server is not doing some of the telnet-protocol
> communications between server and client that most *nix based telnet server
> doing.
Not from my research. Synchronet's telnet server does all the necessary
configuration and supports ALL telnet negotiation options. Simply turn on
Telnet->Configure->Received Logged Commands in SBBSCTRL and you'll see all
received telnet commands (which are responded to by Synchronet's telnet
server).
> telnet_gate just opens a pass-thru port to a new IP, and the code yo
> posted looks like it is doing just that.
Well, you can't see the input (from the telnet client) routines, which do the
option processing/negotiation. That is where the problem (if there is one) is
probably located.
> The telnetd on the *nix side,
> however, is sending some control questions out to the terminal, expecting to
> get answers and it is not getting answers. I am assuming my terminal softwa
> is not sending any answers because it is not listening for those control
> questions since it _already_ is in a session ( with Synchronet ).
If it's a properly written telnet client, that is probably NOT the case. What's
more likely is that the response from the telnet client is getting sucked up
(inadvertently) by Synchronet's telnet server.
> I enabled debugging ( to the screen ) on my unix teletd daemon and made a
> connection with my telnet client:
> ----- begin screen paste -----
> td: send do AUTHENTICATION
> td: recv wont AUTHENTICATION
> td: send do TERMINAL TYPE
> td: send do TSPEED
> td: send do XDISPLOC
> td: send do NEW-ENVIRON
> td: send do OLD-ENVIRON
> td: recv will TERMINAL TYPE
> td: recv wont TSPEED
> td: recv wont XDISPLOC
> td: recv wont NEW-ENVIRON
> td: recv wont OLD-ENVIRON
> td: recv suboption TERMINAL-TYPE IS "ansi"
> td: send will SUPPRESS GO AHEAD
> td: send do ECHO
> td: send do NAWS
> td: send will STATUS
> td: send do LFLOW
> td: recv do SUPPRESS GO AHEAD
> td: recv wont ECHO
> td: recv will NAWS
> td: recv suboption NAWS 0 80 (80) 0 25 (25)
> td: recv dont STATUS
> td: recv wont LFLOW
> td: send will ECHO
>
> SCO OpenServer(TM) Release 5 (myopia.ujoint.org) (ttyp0)
>
> login: td: recv do ECHO
> ----- End Screen Paste -----
>
> Wow. That's a lot of crap these two sides are trying to find out. Leaving
> debugging on and trying to connect through my Synchonet door:
>
> ----- Begin Screen Paste -----
> Which or Quit: 7
>
> Press Ctrl-] for a control menu anytime.
>
> Connecting to: myopia.ujoint.org
> td: send do AUTHENTICATION
> ----- End Screen Paste -----
>
> Ahah. So, telnetd is waiting for an answer and never gets it. Synchronet
> won't do it because it is not a telnet client, it's just acting as pass-thru
> My telnet client ain't gonna answer because it is already in a session with
> Synchronet!
I don't think that's what is happening. I think your telnet client probably IS
responding, but the response it getting "eaten" by Synchronet.
> I am not a C or C++ programmer, but I understand enough to read code and get
> fair idea. I generally do bourne or bash scripting on unix, work with SQL,
> program in Visual Basic. This means I know what kind of work could be invol
> to add code to Synchronet to act as a psuedo-telnet-client and anser the
> pre-connecting requests, and then drop into a pass-through mode. I know it
> ain't pretty. If I could suggest something like this happening, then let's
> I just did.
>
> I've got some C/C++ source here for a telnet client and if I can find the
> snippets in question, I'll send them your way...
Thanks, but I do have working option processing code (enable the logging of
received Telnet options in SBBSCTRL to see them work).
> ... if you are interested. I'm off finding other telnet clients and testing
> them to see if it is just my (2) clients acting this way or do they all do t
> to me...
Try this too: modify telgate.src, and add 16 to the end of the telnet_gate
line (and recompile with Baja). Should look like this:
printf "\r\n\1h\1hPress \1yCtrl-]\1w for a control menu anytime.\r\n\r\n"
pause
printf "\1h\1yConnecting to: \1w%s\1n\r\n" str
telnet_gate str 16
cls
This should disable Synchronet's telnet option processing (temporarily, just
for the gate session).
Rob
---
� Synchronet � Vertrauen � Home of Synchronet � telnet://vert.synchro.net
