You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Chris Jones (JIRA)" <ji...@apache.org> on 2010/08/16 16:26:17 UTC
[jira] Created: (NET-335) TelnetOutputStream incorrectly doubles-up
IAC when sending IAC+EOR in BINARY transmission mode
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: 2.0, 1.4
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.
[jira] Commented: (NET-335) TelnetOutputStream incorrectly
doubles-up IAC when sending IAC+EOR in BINARY transmission mode
Posted by "Chris Jones (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (NET-335) TelnetOutputStream incorrectly
doubles-up IAC when sending IAC+EOR in BINARY transmission mode
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ 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.