[jira] Commented: (NET-89) [net] TelnetClient broken for binary transmissions + solution

["Sebb (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NET-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12887182#action_12887182 ] 

Sebb commented on NET-89:
-------------------------

The use of ToNetASCIIOutputStream/FromNetASCIIInputStream to wrap the streams does seem to be a bit odd.

Those classes look OK for wrapping FTP file transfers (which is where they are otherwise used) but  I'm not sure that they should be used with Telnet, given that the Telnet I/O streams also perform some EOL conversions. Also, the Telnet I/O streams take account of BINARY mode, whereas the NetASCII classes don't.

Seems to me that all the EOL handling should be done in the I/O streams.

There should be a means of specifying what EOL conversion (if any) is to be performed by the streams.
This should probably be set initially and not changed.

Though in the case of Telnet output, I wonder whether any conversion should be done,  given that the Java code could include the correct EOLs anyway.

> [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.
> {quote}
> Also, in TelnetInputStream#__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.
> ...
> {quote}
> The above bug report has been moved to the subtask NET-329
> 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.