commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Oberhuber (JIRA)" <j...@apache.org>
Subject [jira] Commented: (NET-89) [net] TelnetClient broken for binary transmissions + solution
Date Fri, 07 Nov 2008 16:46:45 GMT

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

Martin Oberhuber commented on NET-89:
-------------------------------------

For us, the unconditional wrapping of the inputStream in a FromNetASCIIInputStream in the
_connectAction_() is also problematic. We have a Java vt100 terminal implementation, which
can run on Windows or UNIX. For the vt100 Terminal, we need the CRLF line endings because
LF-only must be interpreted as "line down only". 

We could wrap the inputStream in another ToNetASCIIInputStream when on UNIX, but I don't fancy
this idea too much since there is still a risk of losing data (LF-only _MAY_ be different
than CRLF, not only in binary but in Terminal apps as well, or am I mistaken?) - IMHO using
the System.property for deciding on NetASCII decoding or not was not a good idea in the first
place at all.

What about simply introducing a field e.g. TelnetClient#setNetASCIIConversion(boolean b) in
order to switch on or off the auto-conversion? Should be called before connecting. I'd assume
that anyone dealing with actual Terminals or binary transmission would want to switch the
auto conversion off.

I also like switching off the auto-conversion when BINARY transmission is negotiated, but
I'm a little bit worried about what should happen when the binary negotiation happens at a
time where e.g. the CR is already consumed but the LF not yet...

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


Mime
View raw message