Subj : telnet_gate
To : Digital Man
From : Hemo
Date : Sun Sep 17 2000 02:13 pm
RE: telnet_gate
BY: Digital Man to Hemo on Sun Sep 17 2000 04:15 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'm just thinking out loud here, so don't take this as gospel, and correct me
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 are
doing. telnet_gate just opens a pass-thru port to a new IP, and the code you
posted looks like it is doing just that. 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 software
is not sending any answers because it is not listening for those control
questions since it _already_ is in a session ( with Synchronet ).
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
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 am not a C or C++ programmer, but I understand enough to read code and get a
fair idea. I generally do bourne or bash scripting on unix, work with SQL, and
program in Visual Basic. This means I know what kind of work could be involved
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 say
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...
... 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 this
to me...
---
� Synchronet � The Universal JoiNT - bbs.ujoint.org - under seda..construction
