[jira] [Commented] (LOGGING-37) [logging] LogFactory#getLogFactory should not look for method every time
[
https://issues.apache.org/jira/browse/LOGGING-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14043663#comment-14043663
]
Archie Cobbs commented on LOGGING-37:
-
I noticed this method consuming inordinate CPU on my system as well.
Can the next release of commons-logging drop support for Java 1.1? If so then
this issue can go away... simply invoke {{Thread.getContextClassLoader()}}
directly.
[logging] LogFactory#getLogFactory should not look for method every time
Key: LOGGING-37
URL: https://issues.apache.org/jira/browse/LOGGING-37
Project: Commons Logging
Issue Type: Bug
Affects Versions: 1.0.4
Environment: Operating System: other
Platform: Other
Reporter: Matthias Ernst
LogFactory checks for the existence of Thread#getContextClassLoader every time
#getLogFactory is invoked and does a reflective invocation. This is
unnecessarily expensive if many Log objects are created. An easy patch is to
remember the Method object; the lookup happens only once and it will massively
profit from reflection optimizations after a number of calls (a Java code stub
is generated by the reflection package).
Patch:
419a420,426
private static Method GET_CONTEXT_CLASS_LOADER = null;
static {
try {
GET_CONTEXT_CLASS_LOADER =
Thread.class.getMethod(getContextClassLoad
er, null);
} catch (NoSuchMethodException e) {
}
}
436,439c443
try {
// Are we running on a JDK 1.2 or later system?
Method method = Thread.class.getMethod(getContextClassLoader,
nu
ll);
---
if(GET_CONTEXT_CLASS_LOADER != null) {
442c446
classLoader =
(ClassLoader)method.invoke(Thread.currentThread(
), null);
---
classLoader =
(ClassLoader)GET_CONTEXT_CLASS_LOADER.invoke(Thr
ead.currentThread(), null);
472c476
} catch (NoSuchMethodException e) {
---
} else {
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (NET-387) TelnetClient use of FromNetASCIIInputStream and ToNetASCIIOutputStream breaks binary mode on non-Windows platforms
TelnetClient use of FromNetASCIIInputStream and ToNetASCIIOutputStream breaks
binary mode on non-Windows platforms
--
Key: NET-387
URL: https://issues.apache.org/jira/browse/NET-387
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.2
Reporter: Archie Cobbs
I am trying to use the telnet client in conjunction with the telnet BINARY
option.
However, the commons-net telnet client has ASCII line-ending conversion
hard-coded into it! The result is that even in BINARY mode, any occurrence of
CR-LF is replaced by your platform's default line ending sequence. So unless
you happen to be running Windows, BINARY mode is screwed up. How ironic.
The attached patch works for me: it seems like this line ending conversion that
it's doing is not the job of this library. The telnet protocol has CRLF line
endings by definition so this is what any user of this client should expect. If
the user of this library wants platform-specific line endings then they can
wrap their input in a {{java.io.LineNumberReader}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-387) TelnetClient use of FromNetASCIIInputStream and ToNetASCIIOutputStream breaks binary mode on non-Windows platforms
[
https://issues.apache.org/jira/browse/NET-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-387:
-
Attachment: crlf-bugfix.txt
TelnetClient use of FromNetASCIIInputStream and ToNetASCIIOutputStream breaks
binary mode on non-Windows platforms
--
Key: NET-387
URL: https://issues.apache.org/jira/browse/NET-387
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.2
Reporter: Archie Cobbs
Attachments: crlf-bugfix.txt
Original Estimate: 5m
Remaining Estimate: 5m
I am trying to use the telnet client in conjunction with the telnet BINARY
option.
However, the commons-net telnet client has ASCII line-ending conversion
hard-coded into it! The result is that even in BINARY mode, any occurrence of
CR-LF is replaced by your platform's default line ending sequence. So unless
you happen to be running Windows, BINARY mode is screwed up. How ironic.
The attached patch works for me: it seems like this line ending conversion
that it's doing is not the job of this library. The telnet protocol has CRLF
line endings by definition so this is what any user of this client should
expect. If the user of this library wants platform-specific line endings then
they can wrap their input in a {{java.io.LineNumberReader}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-345:
-
Attachment: combined_NET-343_NET-344_NET-345_patch.txt
Attaching combined patch for NET-343, NET-344, NET-345.
Telnet client: not properly handling IAC bytes within subnegotiation messages
-
Key: NET-345
URL: https://issues.apache.org/jira/browse/NET-345
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Fix For: 3.0
Attachments: combined_NET-343_NET-344_NET-345_patch.txt, patch3.txt,
patch4.txt
Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
IAC SE}}.
Although it's not clearly spelled out in [RFC
854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
these messages must be escaped by doubling. Other clients do this and this is
the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape
{{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
valid {{IAC IAC}} sequence within a subnegotiation message, it will
incorrectly jump back to data input mode, discarding the message and
introducing its remainder as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation
buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
malicious peer triggered this condition.
Finally, a {{IAC SE}} sequence appearing by itself should probably be
discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-344) Telnet client: Support Listener Notification of Incoming Data
[
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-344:
-
Attachment: combined_NET-343_NET-344_NET-345_patch.txt
Attaching combined patch for NET-343, NET-344, NET-345.
Telnet client: Support Listener Notification of Incoming Data
-
Key: NET-344
URL: https://issues.apache.org/jira/browse/NET-344
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: combined_NET-343_NET-344_NET-345_patch.txt, patch2.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper (NET-343) and the other of which would be a real
nice to have. This issue documents the second problem:
The API I am trying to support requires the ability to notify a listener that
new incoming data is available. This would be trivial for me to do if only my
library could somehow itself get a listener notification from the
{{TelnetInputStream}} reader thread every time it reads new data.
Unfortunately, there's no API provided for doing this, even though it would
be trivial. So I have to implement a hack that requires a wrapper
{{InputStream}} with yet another internal reader thread, etc. Bleh.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-343:
-
Attachment: combined_NET-343_NET-344_NET-345_patch.txt
Attaching combined patch for NET-343, NET-344, NET-345.
Telnet client: Support Client-initiated Subnegotiation Messages
---
Key: NET-343
URL: https://issues.apache.org/jira/browse/NET-343
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Fix For: 3.0
Attachments: combined_NET-343_NET-344_NET-345_patch.txt, patch1.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper and the other of which would be a real nice to
have. This issue documents the first problem:
RFC 2217 specifies that serial port events (such as server notifiying about a
change in carrier detect, or the client instructing the server to change the
baud rate) are delivered to the peer by subnegotiations. For example, to
notify the client about carrier detect, the server sends {{IAC SB
COM-PORT-OPTION NOTIFY-MODEMSTATE value IAC SE}} to the client; to set the
serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
value(4) IAC SE}} to the server. These messages can happen at any time and
are not associated with any WILL/WONT/DO/DONT negotiation (according to my
understanding).
The problem is that while one can _receive_ such messages via
{{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
doesn't provide any way to _send_ (i.e., intiate) these messages.
What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
(properly renamed, etc.) as a public method.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-345:
-
Attachment: discard_IAC_SE.txt
Thanks. Just the last bit of the combined patch was left out, i.e., discarding
an IAC SE sequence appearing by itself.
Telnet client: not properly handling IAC bytes within subnegotiation messages
-
Key: NET-345
URL: https://issues.apache.org/jira/browse/NET-345
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Fix For: 3.0
Attachments: combined_NET-343_NET-344_NET-345_patch.txt,
discard_IAC_SE.txt, patch3.txt, patch4.txt
Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
IAC SE}}.
Although it's not clearly spelled out in [RFC
854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
these messages must be escaped by doubling. Other clients do this and this is
the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape
{{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
valid {{IAC IAC}} sequence within a subnegotiation message, it will
incorrectly jump back to data input mode, discarding the message and
introducing its remainder as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation
buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
malicious peer triggered this condition.
Finally, a {{IAC SE}} sequence appearing by itself should probably be
discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002117#comment-13002117
]
Archie Cobbs commented on NET-345:
--
Bleh! Sorry, ignore that last comment and patch ({{discard_IAC_SE.txt}}). That
patch was already included in a slightly different form.
My apologies. I'm getting confused trying to merge all the patches.
Telnet client: not properly handling IAC bytes within subnegotiation messages
-
Key: NET-345
URL: https://issues.apache.org/jira/browse/NET-345
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Fix For: 3.0
Attachments: combined_NET-343_NET-344_NET-345_patch.txt,
discard_IAC_SE.txt, patch3.txt, patch4.txt
Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
IAC SE}}.
Although it's not clearly spelled out in [RFC
854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
these messages must be escaped by doubling. Other clients do this and this is
the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape
{{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
valid {{IAC IAC}} sequence within a subnegotiation message, it will
incorrectly jump back to data input mode, discarding the message and
introducing its remainder as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation
buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
malicious peer triggered this condition.
Finally, a {{IAC SE}} sequence appearing by itself should probably be
discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-344) Telnet client: Support Listener Notification of Incoming Data
[
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-344:
-
Attachment: NET-344_updated.txt
OK, {{NET-344_updated.txt}} contains just the remaining (uncommitted) part of
the combined patch, i.e., it fixes just this issue.
Thanks,
Telnet client: Support Listener Notification of Incoming Data
-
Key: NET-344
URL: https://issues.apache.org/jira/browse/NET-344
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: NET-344_updated.txt,
combined_NET-343_NET-344_NET-345_patch.txt, patch2.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper (NET-343) and the other of which would be a real
nice to have. This issue documents the second problem:
The API I am trying to support requires the ability to notify a listener that
new incoming data is available. This would be trivial for me to do if only my
library could somehow itself get a listener notification from the
{{TelnetInputStream}} reader thread every time it reads new data.
Unfortunately, there's no API provided for doing this, even though it would
be trivial. So I have to implement a hack that requires a wrapper
{{InputStream}} with yet another internal reader thread, etc. Bleh.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001728#comment-13001728
]
Archie Cobbs commented on NET-343:
--
Just to confirm: patch1.txt is/may be obsolete, please use [this combined
patch|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Thanks.
Telnet client: Support Client-initiated Subnegotiation Messages
---
Key: NET-343
URL: https://issues.apache.org/jira/browse/NET-343
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch1.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper and the other of which would be a real nice to
have. This issue documents the first problem:
RFC 2217 specifies that serial port events (such as server notifiying about a
change in carrier detect, or the client instructing the server to change the
baud rate) are delivered to the peer by subnegotiations. For example, to
notify the client about carrier detect, the server sends {{IAC SB
COM-PORT-OPTION NOTIFY-MODEMSTATE value IAC SE}} to the client; to set the
serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
value(4) IAC SE}} to the server. These messages can happen at any time and
are not associated with any WILL/WONT/DO/DONT negotiation (according to my
understanding).
The problem is that while one can _receive_ such messages via
{{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
doesn't provide any way to _send_ (i.e., intiate) these messages.
What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
(properly renamed, etc.) as a public method.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001730#comment-13001730
]
Archie Cobbs commented on NET-343:
--
Ok nevermind previous comment, patch1.txt is pretty trivial and hasn't changed
since originally posted. Thanks.
Telnet client: Support Client-initiated Subnegotiation Messages
---
Key: NET-343
URL: https://issues.apache.org/jira/browse/NET-343
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch1.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper and the other of which would be a real nice to
have. This issue documents the first problem:
RFC 2217 specifies that serial port events (such as server notifiying about a
change in carrier detect, or the client instructing the server to change the
baud rate) are delivered to the peer by subnegotiations. For example, to
notify the client about carrier detect, the server sends {{IAC SB
COM-PORT-OPTION NOTIFY-MODEMSTATE value IAC SE}} to the client; to set the
serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
value(4) IAC SE}} to the server. These messages can happen at any time and
are not associated with any WILL/WONT/DO/DONT negotiation (according to my
understanding).
The problem is that while one can _receive_ such messages via
{{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
doesn't provide any way to _send_ (i.e., intiate) these messages.
What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
(properly renamed, etc.) as a public method.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-344) Telnet client: Support Listener Notification of Incoming Data
[
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12934574#action_12934574
]
Archie Cobbs commented on NET-344:
--
FYI, the latest version of my combined patch to fix NET-343, NET-344, and
NET-345 can be found
[here|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Please use this version as I'll be keeping it up to date.
Telnet client: Support Listener Notification of Incoming Data
-
Key: NET-344
URL: https://issues.apache.org/jira/browse/NET-344
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch2.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper (NET-343) and the other of which would be a real
nice to have. This issue documents the second problem:
The API I am trying to support requires the ability to notify a listener that
new incoming data is available. This would be trivial for me to do if only my
library could somehow itself get a listener notification from the
{{TelnetInputStream}} reader thread every time it reads new data.
Unfortunately, there's no API provided for doing this, even though it would
be trivial. So I have to implement a hack that requires a wrapper
{{InputStream}} with yet another internal reader thread, etc. Bleh.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12934573#action_12934573
]
Archie Cobbs commented on NET-345:
--
FYI, the latest version of my combined patch to fix NET-343, NET-344, and
NET-345 can be found
[here|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Please use this version as I'll be keeping it up to date.
Telnet client: not properly handling IAC bytes within subnegotiation messages
-
Key: NET-345
URL: https://issues.apache.org/jira/browse/NET-345
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch3.txt, patch4.txt
Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
IAC SE}}.
Although it's not clearly spelled out in [RFC
854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
these messages must be escaped by doubling. Other clients do this and this is
the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape
{{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
valid {{IAC IAC}} sequence within a subnegotiation message, it will
incorrectly jump back to data input mode, discarding the message and
introducing its remainder as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation
buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
malicious peer triggered this condition.
Finally, a {{IAC SE}} sequence appearing by itself should probably be
discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12934575#action_12934575
]
Archie Cobbs commented on NET-343:
--
FYI, the latest version of my combined patch to fix NET-343, NET-344, and
NET-345 can be found
[here|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].
Please use this version as I'll be keeping it up to date.
Telnet client: Support Client-initiated Subnegotiation Messages
---
Key: NET-343
URL: https://issues.apache.org/jira/browse/NET-343
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch1.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper and the other of which would be a real nice to
have. This issue documents the first problem:
RFC 2217 specifies that serial port events (such as server notifiying about a
change in carrier detect, or the client instructing the server to change the
baud rate) are delivered to the peer by subnegotiations. For example, to
notify the client about carrier detect, the server sends {{IAC SB
COM-PORT-OPTION NOTIFY-MODEMSTATE value IAC SE}} to the client; to set the
serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
value(4) IAC SE}} to the server. These messages can happen at any time and
are not associated with any WILL/WONT/DO/DONT negotiation (according to my
understanding).
The problem is that while one can _receive_ such messages via
{{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
doesn't provide any way to _send_ (i.e., intiate) these messages.
What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
(properly renamed, etc.) as a public method.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-344) Telnet client: Support Listener Notification of Incoming Data
Telnet client: Support Listener Notification of Incoming Data
-
Key: NET-344
URL: https://issues.apache.org/jira/browse/NET-344
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper (NET-343) and the other of which would be a real nice
to have. This issue documents the second problem:
The API I am trying to support requires the ability to notify a listener that
new incoming data is available. This would be trivial for me to do if only my
library could somehow itself get a listener notification from the
{{TelnetInputStream}} reader thread every time it reads new data.
Unfortunately, there's no API provided for doing this, even though it would be
trivial. So I have to implement a hack that requires a wrapper {{InputStream}}
with yet another internal reader thread, etc. Bleh.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
Telnet client: Support Client-initiated Subnegotiation Messages
---
Key: NET-343
URL: https://issues.apache.org/jira/browse/NET-343
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper and the other of which would be a real nice to have.
This issue documents the first problem:
RFC 2217 specifies that serial port events (such as server notifiying about a
change in carrier detect, or the client instructing the server to change the
baud rate) are delivered to the peer by subnegotiations. For example, to notify
the client about carrier detect, the server sends {{IAC SB COM-PORT-OPTION
NOTIFY-MODEMSTATE value IAC SE}} to the client; to set the serial port baud
rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD value(4) IAC SE}} to
the server. These messages can happen at any time and are not associated with
any WILL/WONT/DO/DONT negotiation (according to my understanding).
The problem is that while one can _receive_ such messages via
{{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
doesn't provide any way to _send_ (i.e., intiate) these messages.
What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
(properly renamed, etc.) as a public method.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-343) Telnet client: Support Client-initiated Subnegotiation Messages
[
https://issues.apache.org/jira/browse/NET-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-343:
-
Attachment: patch1.txt
Attaching patch to fix this issue.
Telnet client: Support Client-initiated Subnegotiation Messages
---
Key: NET-343
URL: https://issues.apache.org/jira/browse/NET-343
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch1.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper and the other of which would be a real nice to
have. This issue documents the first problem:
RFC 2217 specifies that serial port events (such as server notifiying about a
change in carrier detect, or the client instructing the server to change the
baud rate) are delivered to the peer by subnegotiations. For example, to
notify the client about carrier detect, the server sends {{IAC SB
COM-PORT-OPTION NOTIFY-MODEMSTATE value IAC SE}} to the client; to set the
serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
value(4) IAC SE}} to the server. These messages can happen at any time and
are not associated with any WILL/WONT/DO/DONT negotiation (according to my
understanding).
The problem is that while one can _receive_ such messages via
{{TelnetOptionHandler.answerSubnegotiation()}}, the {{TelnetClient}} class
doesn't provide any way to _send_ (i.e., intiate) these messages.
What's needed here is simply to expose {{Telnet._sendSubnegotiation()}}
(properly renamed, etc.) as a public method.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-344) Telnet client: Support Listener Notification of Incoming Data
[
https://issues.apache.org/jira/browse/NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-344:
-
Attachment: patch2.txt
Attaching patch to fix this issue.
Telnet client: Support Listener Notification of Incoming Data
-
Key: NET-344
URL: https://issues.apache.org/jira/browse/NET-344
Project: Commons Net
Issue Type: New Feature
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch2.txt
I am in the process of trying to implement a Java client for [RFC
2217|http://tools.ietf.org/html/rfc2217], which is the protocol for accessing
serial ports over TCP. Unfortunately, the commons-net telnet client is
insufficient for this relatively simple task.
There are two missing features in the commons-net telnet client code, one of
which is a show stopper (NET-343) and the other of which would be a real
nice to have. This issue documents the second problem:
The API I am trying to support requires the ability to notify a listener that
new incoming data is available. This would be trivial for me to do if only my
library could somehow itself get a listener notification from the
{{TelnetInputStream}} reader thread every time it reads new data.
Unfortunately, there's no API provided for doing this, even though it would
be trivial. So I have to implement a hack that requires a wrapper
{{InputStream}} with yet another internal reader thread, etc. Bleh.
I'm going to attempt to come up with a patch and will attach it here if
successful.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
Telnet client: not properly handling IAC bytes within subnegotiation messages
-
Key: NET-345
URL: https://issues.apache.org/jira/browse/NET-345
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch3.txt
Subnegotiation messages in telnet are sent using the sequence {{IAC SB ... IAC
SE}}.
Although it's not clearly spelled out in [RFC
854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
these messages must be escaped by doubling. Other clients do this and this is
the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape {{IAC}}
bytes within subnegotiation messages. Moreover, if it does receive a valid
{{IAC IAC}} sequence within a subnegotiation message, it will incorrectly jump
back to data input mode, discarding the message and introducing its remainder
as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation
buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a malicious
peer triggered this condition.
Finally, a {{IAC SE}} sequence appearing by itself should probably be
discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-345:
-
Attachment: patch3.txt
Telnet client: not properly handling IAC bytes within subnegotiation messages
-
Key: NET-345
URL: https://issues.apache.org/jira/browse/NET-345
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch3.txt
Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
IAC SE}}.
Although it's not clearly spelled out in [RFC
854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
these messages must be escaped by doubling. Other clients do this and this is
the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape
{{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
valid {{IAC IAC}} sequence within a subnegotiation message, it will
incorrectly jump back to data input mode, discarding the message and
introducing its remainder as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation
buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
malicious peer triggered this condition.
Finally, a {{IAC SE}} sequence appearing by itself should probably be
discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages
[
https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Archie Cobbs updated NET-345:
-
Attachment: patch4.txt
Telnet client: not properly handling IAC bytes within subnegotiation messages
-
Key: NET-345
URL: https://issues.apache.org/jira/browse/NET-345
Project: Commons Net
Issue Type: Bug
Components: Telnet
Affects Versions: 2.0
Reporter: Archie Cobbs
Attachments: patch3.txt, patch4.txt
Subnegotiation messages in telnet are sent using the sequence {{IAC SB ...
IAC SE}}.
Although it's not clearly spelled out in [RFC
854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside
these messages must be escaped by doubling. Other clients do this and this is
the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape
{{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a
valid {{IAC IAC}} sequence within a subnegotiation message, it will
incorrectly jump back to data input mode, discarding the message and
introducing its remainder as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation
buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a
malicious peer triggered this condition.
Finally, a {{IAC SE}} sequence appearing by itself should probably be
discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
