[
https://issues.apache.org/jira/browse/NET-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899333#action_12899333
]
Chris Jones commented on NET-335:
---------------------------------
Having studied the code a bit , I think the first option I suggested above is
the better way to go, since TelnetOutputStream already has code specific to
BINARY mode in the write method, and it would simply be a case of making a
change as follows:-
public void write(int ch) throws IOException
{
:
:
else if (ch == TelnetCommand.IAC &&
__client._requestedWont(TelnetOption.BINARY)) // don't double IAC if BINARY
{
__client._sendByte(ch);
__client._sendByte(TelnetCommand.IAC);
} else
__client._sendByte(ch);
}
}
> TelnetOutputStream incorrectly doubles-up IAC when sending IAC+EOR in BINARY
> transmission mode
> ----------------------------------------------------------------------------------------------
>
> Key: NET-335
> URL: https://issues.apache.org/jira/browse/NET-335
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet
> Affects Versions: 1.4, 2.0
> Environment: Windows XP SP3, Java 1.6.0_21
> Reporter: Chris Jones
>
> This is related to NET-180 which I reported a couple of years back, and is
> reported fixed in 2.1. I've since re-visited the code, and found another issue
> background
> ----------------
> I have a TN5250 client (see rfc1205) which extends TelnetClient. Basically,
> the client negotiates BINARY transmission and operates in block-mode. The
> client sends IAC+EOR to notify the host that the data is complete, but the
> TelnetOutputStream doubles-up the IAC automatically as if it was a data byte,
> which iis not the case, resulting in IAC+IAC+EOR.
> Two possible solutions come to mind:
> 1. Do not double-up IAC when in BINARY transmission in TelnetOutputStream
> (i.e. leave it to the client)
> 2. Add a method to TelnetClient like -- sendCommand(byte b) {........} which
> would act similar to sendAYT, only allowing the client to specify the value.
> On balance, I like the second option, as it would give more future
> possibilities.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
