[ https://issues.apache.org/jira/browse/SSHD-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Goldstein Lyor updated SSHD-800: -------------------------------- Summary: Numerous SSH_MSG_CHANNEL_FAILURE messages sent for (was: SSHD port forwarding. Wrong SSH_MSG_CHANNEL_FAILURE) > Numerous SSH_MSG_CHANNEL_FAILURE messages sent for > --------------------------------------------------- > > 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: Major > > 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)