Some causes of data loss on Telnet connection
When creating a network connection between the ports of two Lantronix servers I am seeing data loss, why?
If you want to transfer full 8-bit data, use a raw connection, not a
telnet connection. See below:
Lantronix servers have the option of making or receiving connections to
ports with either telnet IAC interpretation (RFC2217) or as a 8-bit clean (raw)
data connections.
MSS Device Servers:
The telnet range is specified by the physical port number plus 2000,
i.e. to connect to physical port 4 with telnet IAC interpretation (RFC2217)you
would form a socket connection to port 2004. The 8-bit clean range is
physical port number plus 3000.
CoBos family Device Servers:
To enable RFC2217 on a Cobos device Server like the UDS1100, you need to enable
the Telnet Com Port Cntrl option in the webmanager menu channel x/connections menu.
Evolution and Linux Device Servers:
To enable RFC2217 on a Evolution or Linux based device Server like the PremierWave or EDS1100, you need to enable
the TruPort option in the webmanager menu Tunnel/Serial settingss menu.
When a telnet connection is initiated, the telnet host will attempt to
negotiate with its peer on the other side of the link. If the other
side is not responding to the telnet negotiation attempt, a valid
connection may not occur. This is very implementation dependent.
Once a valid telnet connection has been established, in order to send
a 0xff across the link, it must actually be sent as 0xff 0xff. This
is a very simple IAC (Interpret as Command) sequence which means take
this IAC and replace it in the datastream with 0xff. (basically
quoting the 0xff character)
There are four possible combinations when dealing with IAC processing:
Type Input Data On the network Output Data Type Telnet 0xff 0xff 0xff 0xff Telnet Telnet 0xff 0xff 0xff 0xff 0xff Raw Raw 0xff 0xn1 0xn2 0xff 0xn1 0xn2 (nothing) * Telnet Raw 0xff 0xff 0xff Raw
* The telnet processor will see the 0xff in the data stream and will attempt to make a valid IAC sequence. Normally this will result in the loss of at least the 0xff character, and often one or two additional bytes of data. In addition, when a telnet connection is established, special processing occurs with the CR and LF characters. From RFC854: Note that "CR LF" or "CR NUL" is required in both directions (in the default ASCII mode), to preserve the symmetry of the NVT model. Even though it may be known in some situations (e.g., with remote echo and suppress go ahead options in effect) that characters are not being sent to an actual printer, nonetheless, for the sake of consistency, the protocol requires that a NUL be inserted following a CR not followed by a LF in the data stream. The converse of this is that a NUL received in the data stream after a CR (in the absence of options negotiations which explicitly specify otherwise) should be stripped out prior to applying the NVT to local character set mapping. For more information, refer to RFC 854, "Telnet Protocol Specification."
[Originally Published On: 06/28/1999 02:31 PM]