[
https://issues.apache.org/jira/browse/NET-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921309#action_12921309
]
Sebb commented on NET-335:
--------------------------
The problem with option 1 is that this breaks compatibility for existing users,
who expect IAC characters to be doubled.
Indeed if your data includes IAC not followed by EOR, it would not be sent
correctly.
Note that a work-round is to use the protected _output_ field from
SocketClient, which is not subject to any filtering.
> 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.
