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:

* 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.