[jira] [Commented] (COMPRESS-685) Javadoc for GzipCompressorInputStream contains inaccuracies
[
https://issues.apache.org/jira/browse/COMPRESS-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869800#comment-17869800
]
Archie Cobbs commented on COMPRESS-685:
---
Hi [~ggregory],
Sure - please see [https://github.com/apache/commons-compress/pull/551]
Thanks.
> Javadoc for GzipCompressorInputStream contains inaccuracies
> ---
>
> Key: COMPRESS-685
> URL: https://issues.apache.org/jira/browse/COMPRESS-685
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.26.2
>Reporter: Archie Cobbs
>Priority: Minor
>
> There are two incorrect statements in the Javadoc for
> {{GzipCompressorInputStream}}:
> {quote}
> If you use the constructor {{GzipCompressorInputStream(in)}} or
> {{GzipCompressorInputStream(in, false)}} with some {{InputStream}} in then
> {{read()}} will return -1 as soon as the first internal member has been read
> completely. The stream in will be positioned at the start of the second gzip
> member if there is one.
> {quote}
> That statement is only true if the configured input stream supports
> {{mark()}}/{{reset()}}.
> Otherwise not, an {{IOException}} may be thrown if/when {{reset()}} is
> invoked on the input stream (or maybe not if you get lucky and the stars and
> read buffering align).
> {quote}
> [{{GZIPInputStream}}|https://docs.oracle.com/javase/8/docs/api/java/util/zip/GZIPInputStream.html]
> doesn't decompress concatenated .gz files: it stops after the first member
> and silently ignores the rest.
> {quote}
> That statement was true a long time ago but is no longer true. This support
> was added in JDK 7 (see
> [JDK-4691425|https://bugs.openjdk.org/browse/JDK-4691425]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (COMPRESS-685) Javadoc for GzipCompressorInputStream contains inaccuracies
Archie Cobbs created COMPRESS-685:
-
Summary: Javadoc for GzipCompressorInputStream contains
inaccuracies
Key: COMPRESS-685
URL: https://issues.apache.org/jira/browse/COMPRESS-685
Project: Commons Compress
Issue Type: Bug
Components: Compressors
Affects Versions: 1.26.2
Reporter: Archie Cobbs
There are two incorrect statements in the Javadoc for
{{GzipCompressorInputStream}}:
{quote}
If you use the constructor {{GzipCompressorInputStream(in)}} or
{{GzipCompressorInputStream(in, false)}} with some {{InputStream}} in then
{{read()}} will return -1 as soon as the first internal member has been read
completely. The stream in will be positioned at the start of the second gzip
member if there is one.
{quote}
That statement is only true if the configured input stream supports
{{mark()}}/{{reset()}}.
Otherwise not, an {{IOException}} may be thrown if/when {{reset()}} is invoked
on the input stream (or maybe not if you get lucky and the stars and read
buffering align).
{quote}
[{{GZIPInputStream}}|https://docs.oracle.com/javase/8/docs/api/java/util/zip/GZIPInputStream.html]
doesn't decompress concatenated .gz files: it stops after the first member and
silently ignores the rest.
{quote}
That statement was true a long time ago but is no longer true. This support was
added in JDK 7 (see [JDK-4691425|https://bugs.openjdk.org/browse/JDK-4691425]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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-tabpanel&focusedCommentId=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] [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] [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-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-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-tabpanel&focusedCommentId=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-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] 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 IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> 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-tabpanel&focusedCommentId=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 IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> 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-tabpanel&focusedCommentId=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 IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> 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-tabpanel&focusedCommentId=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 IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> 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] 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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] 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.
[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-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] 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 IAC SE}} to the client; to set the
> serial port baud rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD
> 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-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 IAC SE}} to the client; to set the serial port baud
rate, the client sends {{IAC SB COM-PORT-OPTION SET-BAUD 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.
