[ 
https://issues.apache.org/jira/browse/SSHD-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Goldstein Lyor resolved SSHD-800.
---------------------------------
       Resolution: Fixed
         Assignee: Goldstein Lyor
    Fix Version/s: 1.8.0

Made the value configurable - and after some consideration decided to make the 
default _false_ - i.e., don't reply to such messages - which means you don't 
need special SSHD configuration

> Numerous SSH_MSG_CHANNEL_FAILURE messages sent for SSH_MSG_CHANNEL_DATA  on 
> unknown channel
> -------------------------------------------------------------------------------------------
>
>                 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
>            Assignee: Goldstein Lyor
>            Priority: Major
>             Fix For: 1.8.0
>
>
> 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)

Reply via email to