[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] Commented: (MATH-439) Refactoring of solvers (package "analysis.solvers")
[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934018#action_12934018
]
Gilles commented on MATH-439:
-
> [...] yes, raising the threshold is an appropriate fix [...]
Fine. Thanks.
> Our exception handling is already quite complex now [...]
Now? I hold that it is much _simpler_ now (or, more exactly: It will be when
the pending tasks are completed):
* A single {{exception}} package, instead of classes interspersed in several
packages.
* More specific (hence, informative) exception types.
* Obvious exceptions hierarchies (rooted at the various "Math...Exception"
classes that themselves inherit from the Java standard exception specific
categories).
* Message factory and exception localization utilities located in package
{{exception.util}}.
* Reduction of the number of message patterns.
* Embryo of exception usage policy (e.g. not propagating
{{NullPointerException}}).
* No checked exceptions :-)
You ask to slow the pace precisely when I propose to keep something from the
previous design, i.e. the already existing {{IntegrationException}} concept
(albeit moving it to the {{exception}} package and integrating it into the new
design, of course).
MATH-195 is a long-running task but it is a single one. We should cross to the
other bank instead of staying in the middle of the river...
> Refactoring of solvers (package "analysis.solvers")
> ---
>
> Key: MATH-439
> URL: https://issues.apache.org/jira/browse/MATH-439
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
> Attachments: AbstractUnivariateRealSolver.java
>
>
> The classes in package "analysis.solvers" could be refactored similarly to
> what was done for package {{optimization}}.
> * Replace {{MaxIterationsExceededException}} with
> {{TooManyEvaluationsException}}:
> Apart from the class {{MaxIterationsExceededException}} being deprecated,
> this approach makes it difficult to compare different algorithms: While the
> concept of iteration is algorithm-dependent, the user is probably mostly
> interested in the number of function evaluations.
> * Implement the method {{solve}} in the base class
> ({{UnivariateRealSolverImpl}}) and define an abstract method {{doSolve}} to
> be implemented in derived classes. This method would then use a new
> {{computeObjectiveFunction}} method that will take care of the counting of
> the function evaluations.
> * Remove "protected" fields (the root is unnecessary since it is returned by
> {{solve}}). Arguingly the function value is also not very useful (as we know
> what it should be), except for debugging purposes (in which case, it might
> not be a problem to call the function's {{value}} method once more).
> * Remove the tolerance setter (accuracy) and make the corresponding fields
> "final".
--
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.
[jira] Reopened: (BEANUTILS-376) Supporting indexed (mapped) properties of Map objects
[
https://issues.apache.org/jira/browse/BEANUTILS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zdeněk Obst reopened BEANUTILS-376:
---
Thanks a lot for answer.
What you are describing is Map property of bean. In my case problem is that
bean itself is Map type (historical heritage I can't change).
Something like this:
class MyBean implements Map {
public String[] listProperty;
}
Than calling of listProperty[0] is causing IllegalArgumentException. Can you
please check this case.
Thanks a lot.
> Supporting indexed (mapped) properties of Map objects
> -
>
> Key: BEANUTILS-376
> URL: https://issues.apache.org/jira/browse/BEANUTILS-376
> Project: Commons BeanUtils
> Issue Type: Improvement
> Components: Bean / Property Utils
> Environment: JDK1.5_22, WinXP
>Reporter: Zdeněk Obst
>Priority: Minor
>
> So far, BeanUtils does not support indexed or mapped properties of Map object
> (PropertyUtilsBean.getPropertyOfMapBean(Map bean, String propertyName) )
> and throw IllegalArgumentException.
> For instance if you have Map and you want to get property
> by calling propName[0] (or propName(0)), method isIndexed (isMapped) of
> DefaultResolver returns true which raises previously mentioned exception.
> From my point of view it seems that method gets data which needs and is
> possible to parse propertyName to get desired result.
> E.g. something similar to:
> {code}
> if (resolver.isIndexed(propertyName)) {
>String name = resolver.getProperty(propertyName);
>int idx = Integer.valueOf(resolver.getIndex(propertyName)); // handle
> NumberFormat exception by your way
>return ((Object[]) bean.get(name))[idx]; // handle ArrayIndexOutOfBounds
> and ClassCast exception by your way
> }
> {code}
> I was a bit surprised that I didn't find this issue in existing ones. I'm
> sorry if there is any which I omitted.
> Is it possible that this funcionality will be provided in any future release?
> Thank you
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
