[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference lassie::ucx

Title:DEC TCP/IP Services for OpenVMS
Notice:Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System
Moderator:ucxaxp.ucx.lkg.dec.com::TIBBERT
Created:Thu Nov 17 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5568
Total number of notes:21492

5222.0. "TELNET CREATE sending a couple of characters" by CSC32::J_MORTON (O8-OO-2b || ! 2b) Thu Feb 13 1997 13:47

    Hi,
    
    We have a customer reporting that when he does a 'TELNET CREATE' he
    gets a couple of extra characters initially before any user data is
    sent to the remote port.
    
    He has demonstrated this by using the command procedure below and
    going to the POP port, then looking at the logfile. He sees:
    
    	1996-12-03 14:46:50 thread 0: initializing thread
    	1996-12-03 14:46:50 thread 0: client address is 139.187.192.19,1467
    	1996-12-03 14:46:51 thread 0: rx: <255><255>X
    	1996-12-03 14:46:51 thread 0: unknown command: "<255><255>X"
    
    I've tested this to the SMTP port and also see a couple of extra
    characters (with "UCX$SMTP_RECV_TRACE" = "1"):
    
            . . .
            recv buf=\ffffffff\fffffffd\18\d\aQUIT\dData:\9\d\a\0\dData:\9
    
    Is this expected behavior?
    
    Thanks,
    
    Jim
    
    The customer's procedure to test this (a few changes would be necessary
    to use it - remote hostname, possibly the tn device, etc.). The key is
    that we are seeing characters before "QUIT" is sent:
    
    $       set noon
    $       lf[0,8] = 10
    $       cr[0,8] = 13
    $       telnet/create fmis05 110 3
    $       set term tna3:
    /notype_ahead/unknown/hostsync/ttsync/nointeractive/nowrap/eightbit/hard/pasth
    ru/nobroadcast/notab/noecho/nodisconnect/nofull/nohangup/perm
    $       open/append rtest TNA3:
    $       write rtest "QUIT"
    $
    $READ_LOOP:
    $       read/time=2/error=READ_DONE rtest output
    $       write sys$output output
    $       goto READ_LOOP
    $
    $READ_DONE:
    $       wait 00:00:5
    $DELETE_PORT:
    $       if f$trnlnm("RTEST") .nes. "" then close rtest
    $       telnet/delete 3
    $       exit
T.RTitleUserPersonal
Name
DateLines
5222.1LASSIE::GEMIGNANITue Feb 18 1997 17:209
    Actually, it is.
    
    The outgoing TELNET connection that you created is attempting to
    initialize the connection with the TELNET protocol.  It is basically
    advertising to the remote TELNET server that it wants to be in
    character-at-a-time mode.
    
    The newer TELNET servers have disabled this feature, though.
    Please be sure that you have the latest TNDRIVER.
5222.2CSC32::J_MORTONO8-OO-2b || ! 2bWed Feb 19 1997 14:056
    The customer sees this with V4.1 ECO 4. Is the behavior
    changed later than this?
    
    Thanks!
    
    Jim
5222.3Is a later ECO needed?CSC32::J_MORTONO8-OO-2b || ! 2bThu Feb 27 1997 11:331
    
5222.4UCXAXP::GEMIGNANIThu Feb 27 1997 14:397
    The code should have been in SSB 4.1.
    
    I added an undocumented /OPTIONS=(ECHO,SGA) to turn on the negotation.
    Most people didn't want it to negotiate these options, just a raw data
    stream.
    
    You are definitely seeing THIS negotiation, right?
5222.5CSC32::J_MORTONO8-OO-2b || ! 2bFri Feb 28 1997 11:2011
    Hi John,
    
    What I put in .0 is what the log files show. I'm not exactly sure
    what those leading characters are, just that they exist.
    
    The customer is at V4.1 ECO 4. Is there anything else we can
    do to verify what these characters are? or eliminate them?
    
    Thanks,
    
    Jim
5222.6UCXAXP::GEMIGNANIFri Mar 07 1997 19:0626
    It turns out that all of these things are based upon the TELNET
    protocol.  This means several things:
    
    	1) Special command sequences are transmitted as <255><...>.
    	   The TELNET RFC covers these.
    
    	2) REAL <255>s are sent as <255><255>, that is, they are doubled.
    
    	3) Lines terminated as \n (newline character, LF) become CR/LF
           pairs and real CRs sent alone are <CR><NULL>.
    
    FTP, SMTP, and others are based upon the TELNET protocol, while they
    don't provide a TELNET service.
    
    Is the application sending <255>X (which is being expanded to
    <255><255>X per the description above)?
    
    I am assuming that the X is the character sent by the user's program.
    Keep in mind that the TELNET protocol sends <IAC><option> [IAC is 255,
    and means Interpret-As-Command].
    
    Be sure that the customer knows that the TNAs speak TELNET protocol.
    A future release of UCX will give you the option to create TELNET or
    RAW TN devices (with or without TELNET protocol).
    
    
5222.7more info.CSC32::J_MORTONO8-OO-2b || ! 2bMon Mar 10 1997 12:5549
    Hi John,
    
    I'm not sure what that "X" is either. The customer sent the log along with
    the command procedure in .0.
    
    Below is a procedure I'm using and my SMTP log. I do the following:
    
        $ DEFINE/SYSTEM UCX$SMTP_PROTO_TRACE 1
        $ DEFINE/SYSTEM UCX$SMTP_PROTO_DEBUG 1
    	$ UCX STOP MAIL
    	$ UCX START MAIL
    	$ @<the_procedure>
    
    fyi/thanks,
    
    Jim
    
    -----------------
    
    $       set noon
    $       read sys$command tn/prompt="Enter TN #: "
    $       lf[0,8] = 10
    $       cr[0,8] = 13
    $       telnet/create stitr 25 'tn
    $       set term tna'tn: -
    /notype_ahead/unknown/hostsync/ttsync/nointeractive/nowrap/eightbit/hard-
    /pasthru/nobroadcast/notab/noecho/nodisconnect/nofull/nohangup/perm
    $       open/append rtest TNA'tn:
    $       write rtest "QUIT"
    $
    $READ_LOOP:
    $       read/time=2/error=READ_DONE rtest output
    $       write sys$output output
    $       goto READ_LOOP
    $
    $READ_DONE:
    $       wait 00:00:5
    $DELETE_PORT:
    $       if f$trnlnm("RTEST") .nes. "" then close rtest
    $       telnet/delete 'tn
    $       exit
    
    -----------------
    
    . . .
    #smtp_read_reply:recv:status=26, vaxc$errno=1
    recv buf=\ffffffff\fffffffd\18\d\aQUIT\dData:\9\d\a\0\dData:\9
    #smtp_read_reply:B4 ucx$select: vaxc$errno=1, errno=65535
    . . .
5222.8LASSIE::GEMIGNANITue Mar 11 1997 13:1817
    
    Yeah, I found it.
    
    That's IAC/DO/TTYPE -- the TNA wants the remote system
    to do terminal type negotiation.  The driver does this
    as part of the initialization of the created session.
    
    Keep in mind that this is a TELNET connection speaking the
    protocol, and this is valid TELNET protocol.  One solution
    is for the customer to treat this as protocol and either
    NOT respond -or- respond with IAC/WONT/TTYPE (<FF><FC><18>).
    
    The other solution is to submit a priority 3 IPMT (making it
    a nicety, not a necessity).  I have done similar stuff for
    SGA and ECHO (which, you may have noticed, doesn't come out
    unless you enable it).