[jira] [Updated] (FTPSERVER-449) Custom SocketFactory and ServerSocketFactory in DataConnectionConfigurationFactory.
[ https://issues.apache.org/jira/browse/FTPSERVER-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Schwaninger updated FTPSERVER-449: -- Attachment: FTPSERVER449.patch Patch proposal based on version 1.0.6. I will use it for some kind of port forwarding/reverse proxy to open the socket on another host. > Custom SocketFactory and ServerSocketFactory in > DataConnectionConfigurationFactory. > --- > > Key: FTPSERVER-449 > URL: https://issues.apache.org/jira/browse/FTPSERVER-449 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Mathias Schwaninger >Priority: Minor > Attachments: FTPSERVER449.patch > > > Would like to have a possibility to use custom SocketFactory and > ServerSocketFactory in DataConnectionConfigurationFactory. > That could be used for special use-cases for active and passive data > connections in IODataConnectionFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-449) Custom SocketFactory and ServerSocketFactory in DataConnectionConfigurationFactory.
[ https://issues.apache.org/jira/browse/FTPSERVER-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776537#comment-13776537 ] David Latorre commented on FTPSERVER-449: - What kind of cases are you thinking of? Anyway, feel free to provide a patch. > Custom SocketFactory and ServerSocketFactory in > DataConnectionConfigurationFactory. > --- > > Key: FTPSERVER-449 > URL: https://issues.apache.org/jira/browse/FTPSERVER-449 > Project: FtpServer > Issue Type: New Feature > Components: Core >Reporter: Mathias Schwaninger >Priority: Minor > > Would like to have a possibility to use custom SocketFactory and > ServerSocketFactory in DataConnectionConfigurationFactory. > That could be used for special use-cases for active and passive data > connections in IODataConnectionFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FTPSERVER-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776535#comment-13776535 ] David Latorre commented on FTPSERVER-320: - Can anybody apply the patch? I'm quite busy with work and I don't have git installed (nor I know how to use it). > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.1.0 > > Attachments: IODataConnectionFactory.java.patch > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FTPSERVER-449) Custom SocketFactory and ServerSocketFactory in DataConnectionConfigurationFactory.
Mathias Schwaninger created FTPSERVER-449: - Summary: Custom SocketFactory and ServerSocketFactory in DataConnectionConfigurationFactory. Key: FTPSERVER-449 URL: https://issues.apache.org/jira/browse/FTPSERVER-449 Project: FtpServer Issue Type: New Feature Components: Core Reporter: Mathias Schwaninger Priority: Minor Would like to have a possibility to use custom SocketFactory and ServerSocketFactory in DataConnectionConfigurationFactory. That could be used for special use-cases for active and passive data connections in IODataConnectionFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SSHD-256) SSH_MSG_CHANNEL_REQUEST for Putty handled incorrectly
[
https://issues.apache.org/jira/browse/SSHD-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Tatham updated SSHD-256:
--
Attachment: 0001-Consistently-send-replies-to-channel-requests.patch
I've been investigating this same issue (having had it reported initially as a
bug against PuTTY). I agree that Michael Heemskerk's patch is sensible, but I
also think that the problem with ignoring the "want reply" flag goes
considerably further than just this one request type. I looked through the
request handling in the various channel classes and discovered that "want
reply" is often ignored in other situations, which is a source of further
latent bugs just waiting for a peer implementation to trigger them.
I've attached my own suggested patch which centralises the handling of
responses to channel requests, so as to make sure a response is _always_ sent
if "want reply" is true, and _never_ sent if it is not, regardless of the
channel type or whether the request is recognised. I haven't been conveniently
able to check the behaviour in previously failing cases, but I have run the
result through "mvn test" which reported no failures.
I would recommend applying this patch _in addition_ to Michael Heemskerk's
patch.
> SSH_MSG_CHANNEL_REQUEST for Putty handled incorrectly
> -
>
> Key: SSHD-256
> URL: https://issues.apache.org/jira/browse/SSHD-256
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 0.7.0, 0.8.0, 0.9.0
>Reporter: Michael Heemskerk
> Attachments: 0001-Consistently-send-replies-to-channel-requests.patch
>
>
> Symptom:
> SSH connection is kept open after the command completes when using Putty,
> Plink or TortoisePlink, or rather Putty does not finish.
> See:
> * https://code.google.com/p/tortoisegit/issues/detail?id=1880
> * https://jira.atlassian.com/browse/STASH-3824
> Cause:
> ChannelSession has special handling for SSH_MSG_CHANNEL_REQUEST messages that
> are sent by Putty:
> if (type != null && type.endsWith("@putty.projects.tartarus.org")) {
> // Ignore but accept, more doc at
> //
> http://tartarus.org/~simon/putty-snapshots/htmldoc/AppendixF.html
> return true;
> }
> There are really two problems with this workaround that was introduced in
> SSHD-77:
> 1) This code ignores the "want reply" flag on the field and simply ignores
> the request. According to the SSH protocol specification, the server MUST
> send back a reply (success or failure) if the "want reply" flag is set to
> true.
> 2) Putty _intentionally_ sends an invalid request and _expects_ to receive a
> SSH_MSG_CHANNEL_FAILURE response (see
> http://tartarus.org/~simon/putty-snapshots/htmldoc/AppendixF.html), which is
> the default behaviour of ChannelSession.
> I don't know whether changes in Putty or changes in MinaSSHD have made the
> workaround obsolete, but it is obsolete. I've verified that without the bit
> of code I quoted above, the Putty terminates normally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FTPSERVER-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre updated FTPSERVER-320: Attachment: IODataConnectionFactory.java.patch > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.1.0 > > Attachments: IODataConnectionFactory.java.patch > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (FTPSERVER-320) Passive Data connections are slow when using SSL
[ https://issues.apache.org/jira/browse/FTPSERVER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reopened FTPSERVER-320: - Assignee: David Latorre I think it makes sense that we get rid of the reverse DNS lookup in the stable/1.0.x branch. All the other improvements by Sai are available in trunk. > Passive Data connections are slow when using SSL > > > Key: FTPSERVER-320 > URL: https://issues.apache.org/jira/browse/FTPSERVER-320 > Project: FtpServer > Issue Type: Improvement > Components: Core >Affects Versions: 1.0.2 >Reporter: Sai Pullabhotla >Assignee: David Latorre > Fix For: 1.1.0 > > > Creation of passive data sockets is slow when using SSL. The issue is that > the code calls InetAddress.getHostName() method which performs a reverse name > lookup. This is an expensive operation (at least on all the systems I've > tried). We really don't have a need to get the host name, so change the code > to get string version of the IP address and use it instead. More information > on this issue is available at > http://www.mail-archive.com/dev@mina.apache.org/msg13644.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
