[
https://issues.apache.org/jira/browse/NET-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545312
]
Edward Sargisson commented on NET-89:
-------------------------------------
I'd like to provide some additional support for fixing this.
We have a situation where we have some hardware crypto modules connected to a
Lantronix EDS4100 serial-to-IP device. We need to use Telnet to connect to the
Lantronix box. However, the hardware crypto modules use \r as the line
seperator. When running our software on Linux this causes a failure because:
1. The Unix line separator means that FromNetASCIIInputStream is used.
2. The FromNetASCIIInputStream#__read method reads a \r then waits for the next
character.
3. Because our hardware crypto modules only send one line of response with a \r
terminator there is no next character.
4. The read then times out.
There are two basic issues here: One is that JRE properties are being used to
configure the library with no method for the developer to override this. The
second is that the code expects a character after every \r when there is no
guarantee this might happen.
In conclusion, I would like a way to either turn off line feed conversion or to
have access to the unconverted input stream.
> [net] TelnetClient broken for binary transmissions + solution
> -------------------------------------------------------------
>
> Key: NET-89
> URL: https://issues.apache.org/jira/browse/NET-89
> Project: Commons Net
> Issue Type: Bug
> Environment: Operating System: All
> Platform: All
> Reporter: Colin Surprenant
>
> TelnetClient does not handle correctly binary transmissions in two places:
> First in TelnetClient#_connectAction_() the telnet input and output streams
> are
> wrapped in the NetASCII streams to handle net vs platform line separator
> conversion which breaks the binary data. My quick solution was to simply
> remove
> those two wrapping streams. A more general solution might be to provide access
> to the unfilterer stream with methods like getUnfilteredInputStream and
> getUnfilteredOutputStream or to dynamically stop the NetASCII stream from
> 'corrupting' the stream when a TelnetOption.BINARY option is negotiated.
> Also, in TelnetInoutStream#__read() there is a bug in the __receiveState
> handling for the _STATE_IAC state. When a second consecutive IAC (0x255) is
> received to encode the single 0x255 character, read does not return 0x255 but
> instead move on to reading the next char in the stream.
> The current code reads:
> case _STATE_IAC:
> switch (ch)
> {
> case TelnetCommand.WILL:
> __receiveState = _STATE_WILL;
> continue;
> case TelnetCommand.WONT:
> __receiveState = _STATE_WONT;
> continue;
> case TelnetCommand.DO:
> __receiveState = _STATE_DO;
> continue;
> case TelnetCommand.DONT:
> __receiveState = _STATE_DONT;
> continue;
> /* TERMINAL-TYPE option (start)*/
> case TelnetCommand.SB:
> __suboption_count = 0;
> __receiveState = _STATE_SB;
> continue;
> /* TERMINAL-TYPE option (end)*/
> case TelnetCommand.IAC:
> __receiveState = _STATE_DATA;
> break;
> default:
> break;
> }
> __receiveState = _STATE_DATA;
> continue;
> case _STATE_WILL:
> but it should be:
> case _STATE_IAC:
> switch (ch)
> {
> case TelnetCommand.WILL:
> __receiveState = _STATE_WILL;
> continue;
> case TelnetCommand.WONT:
> __receiveState = _STATE_WONT;
> continue;
> case TelnetCommand.DO:
> __receiveState = _STATE_DO;
> continue;
> case TelnetCommand.DONT:
> __receiveState = _STATE_DONT;
> continue;
> /* TERMINAL-TYPE option (start)*/
> case TelnetCommand.SB:
> __suboption_count = 0;
> __receiveState = _STATE_SB;
> continue;
> /* TERMINAL-TYPE option (end)*/
> case TelnetCommand.IAC:
> __receiveState = _STATE_DATA;
> break; // exit to enclosing switch to return from read
> default:
> __receiveState = _STATE_DATA;
> continue; // move on the next char
> }
> break; // exit and return from read
> case _STATE_WILL:
> I'll provide patches for this.
> Colin.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
