Seeing Data Loss When Using Telenet Connection, Why?

Question:   When creating a network connection between the ports of two Lantronix (or Digi One) servers I am seeing data loss, why?

Answer:
  If you want to transfer full 8-bit data, use a raw connection, not a telnet connection.  Telnet port settings and/or connections for data transfer are not supported, as telnet cannot download a file due to the 0XFF issue explained below:

Lantronix servers have the option of making or receiving connections to ports with either telnet IAC interpretation or as an 8-bit clean (raw) data connection.

The telnet range is specified by the physical port number plus 2000, i.e. to connect to physical port 4 with telnet IAC interpretation you would form a socket connection to port 2004.  The 8-bit clean range is physical port number plus 3000.

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 data stream 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."


Related Articles

Attachments

No attachments were found.

Visitor Comments

No visitor comments posted. Post a comment

Post Comment for "Seeing Data Loss When Using Telenet Connection, Why?"

To post a comment for this article, simply complete the form below. Fields marked with an asterisk are required.

   Name:
   Email:
* Comment:
* Enter the code below:

 

Article Details

Last Updated
10th of October, 2011

Software
Centurion Gold

Hardware
Phoenix, Phoenix RAX, Phoenix RAX II, Unicorn

Would you like to...

Print this page  Print this page

Email this page  Email this page

Post a comment  Post a comment

 Subscribe me

Subscribe me  Add to favorites

Remove Highlighting Remove Highlighting

Edit this Article

Quick Edit

Export to PDF


User Opinions

No users have voted.

How would you rate this answer?




Thank you for rating this answer.

Continue