[
https://issues.apache.org/jira/browse/SSHD-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fulvio Cavarretta updated SSHD-800:
-----------------------------------
Description:
Hi in case the SSHD server receives a message for a not existing channel, it
sends back a _SSH_MSG_CHANNEL_FAILURE_.
This behaviour is not described in RFC4254, which, I agree, is unclear about
what should be do in this case.
Since the current SSHD implementation send back a _SSH_MSG_CHANNEL_FAILURE_
message (with the local channel id), in our environment, it put the receipient
in an inconsistent state.
In out enviroment happened that the receipient has sent a
_SSH_MSG_CHANNEL_DATA_ while SSHD had already closed the channel.
I fully agree that this should not happen (I will open another issue about
this) but the _SSH_MSG_CHANNEL_FAILURE_ further complicates things.
The problem can be overcome modifying line 78 of
_org.apache.sshd.common.session.helpers.DefaultUnknownChannelReferenceHandler_
letting
{code:java}
case SshConstants.SSH_MSG_CHANNEL_EXTENDED_DATA:
// Not sure if entirely compliant with RFC4254, but try to stem the flood
wantReply = false;
break;
default: // do nothing{code}
instead of
{code:java}
case SshConstants.SSH_MSG_CHANNEL_EXTENDED_DATA:
// Not sure if entirely compliant with RFC4254, but try to stem the flood
wantReply = true;
break;
default: // do nothing{code}
was:
Hi in case the SSHD server receives a message for a not existing channel, it
sends back a _SSH_MSG_CHANNEL_FAILURE_.
This behaviour is not described in RFC4254, which, I agree, is unclear about
what should be do in this case.
Since the current SSHD implementation send back a _SSH_MSG_CHANNEL_FAILURE_
message (with the local channel id), in our environment, it put the receipient
in an inconsistent state.
In out enviroment happened that the receipient has sent a
_SSH_MSG_CHANNEL_DATA_ while SSHD had already closed the channel.
I fully agree that this should not happen (I will open another issue about
this) but the _SSH_MSG_CHANNEL_FAILURE_ further complicates things.
> SSHD port forwarding. Wrong SSH_MSG_CHANNEL_FAILURE
> ---------------------------------------------------
>
> Key: SSHD-800
> URL: https://issues.apache.org/jira/browse/SSHD-800
> Project: MINA SSHD
> Issue Type: Bug
> Affects Versions: 1.7.0
> Reporter: Fulvio Cavarretta
> Priority: Critical
>
> Hi in case the SSHD server receives a message for a not existing channel, it
> sends back a _SSH_MSG_CHANNEL_FAILURE_.
> This behaviour is not described in RFC4254, which, I agree, is unclear about
> what should be do in this case.
> Since the current SSHD implementation send back a _SSH_MSG_CHANNEL_FAILURE_
> message (with the local channel id), in our environment, it put the
> receipient in an inconsistent state.
> In out enviroment happened that the receipient has sent a
> _SSH_MSG_CHANNEL_DATA_ while SSHD had already closed the channel.
> I fully agree that this should not happen (I will open another issue about
> this) but the _SSH_MSG_CHANNEL_FAILURE_ further complicates things.
>
> The problem can be overcome modifying line 78 of
> _org.apache.sshd.common.session.helpers.DefaultUnknownChannelReferenceHandler_
>
> letting
> {code:java}
> case SshConstants.SSH_MSG_CHANNEL_EXTENDED_DATA:
> // Not sure if entirely compliant with RFC4254, but try to stem the flood
> wantReply = false;
> break;
> default: // do nothing{code}
>
> instead of
>
> {code:java}
> case SshConstants.SSH_MSG_CHANNEL_EXTENDED_DATA:
> // Not sure if entirely compliant with RFC4254, but try to stem the flood
> wantReply = true;
> break;
> default: // do nothing{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
