mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fulvio Cavarretta (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SSHD-776) SSHD local port forwarding close session unexpectedly
Date Wed, 11 Oct 2017 08:19:00 GMT

    [ https://issues.apache.org/jira/browse/SSHD-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199911#comment-16199911
] 

Fulvio Cavarretta edited comment on SSHD-776 at 10/11/17 8:18 AM:
------------------------------------------------------------------

Hi [~lgoldstein], I've submitted the pull request [#https://github.com/apache/mina-sshd/pull/38]

# {{AbstractConnectionService.channelWindowAdjust}}: we did the same modifications as for
{{channelEof}}; checking RFC there is the same level of ambiguity
# {{Nio2Session.exceptionCaught}}: the session should be any closed (the {{close}} method
is already resilient to subsequent calls). This was necessay because we found some messages
in {{write}} queue afer the exception management.
# {{TcpipServerChannel.close}} this have been changed to let the connector to close immediatly
os gracefully, accordingly to the way the API is called. Most of the problem we have found
where related write messages still pending during a gracefull close
# {{TcpipServerChannel.handleWriteDataFailure}}: this have been necessary because in case
the remote server had closed the connection, some data could be still waiting  in the channel
to be written to the outgoing session (even if channel close have been already sent) that
could be already closed. In that case we should simply have to discard those error.

Please let me know if it's possible to accept these modifications in the next SSHD release


was (Author: fcava):
Hi [~lgoldstein], I'm not sure how can I submit a pull request, so I've attached it here the
git formatted patch [^sshd.SSHD-776.patch].
This patch contains the following modifications (we have successfully tested in our environment
with a whole day long run):

# {{AbstractConnectionService.channelWindowAdjust}}: we did the same modifications as for
{{channelEof}}; checking RFC there is the same level of ambiguity
# {{Nio2Session.exceptionCaught}}: the session should be any closed (the {{close}} method
is already resilient to subsequent calls). This was necessay because we found some messages
in {{write}} queue afer the exception management.
# {{TcpipServerChannel.close}} this have been changed to let the connector to close immediatly
os gracefully, accordingly to the way the API is called. Most of the problem we have found
where related write messages still pending during a gracefull close
# {{TcpipServerChannel.handleWriteDataFailure}}: this have been necessary because in case
the remote server had closed the connection, some data could be still waiting  in the channel
to be written to the outgoing session (even if channel close have been already sent) that
could be already closed. In that case we should simply have to discard those error.

Please let me know if it's possible to accept these modifications in the next SSHD release

> SSHD local port forwarding close session unexpectedly
> -----------------------------------------------------
>
>                 Key: SSHD-776
>                 URL: https://issues.apache.org/jira/browse/SSHD-776
>             Project: MINA SSHD
>          Issue Type: Bug
>    Affects Versions: 1.6.0
>            Reporter: Fulvio Cavarretta
>            Assignee: Goldstein Lyor
>              Labels: channel, eof, forwarding, sshd
>         Attachments: dmzagent-1.7.0-snapshot.trc, dmzagent-WriteAbortException.trc, dmzagent.trc,
dmzagent.trc.2, sshd.SSHD-776.patch
>
>
> Apache SSHD used in local port forwarding mode.
> A client is connecting to a remote FTP server through Apache SSHD via a custom software.
> When a new logical channel inside a single SSHD session get an IO error (e.g. the remote
destination close the connection suddenly, the whole session is shut down causing all other
logical channel to be closed (see line 8861of attached trace file).
> It seems like the _exceptionCaught_ mathod should not be called in this case



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message