[jira] [Commented] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486853#comment-17486853
]
Thomas Wolf commented on SSHD-1244:
---
Yes, but RFC 4254 requires handling window sizes up to 2^32 -1. So it's quite
possible to get a window size larger than {{{}Integer.MAX_VALUE{}}}. Apache
MINA sshd handles the window size as a *signed* 32bit integer, but should
handle it as an *unsigned* 32bit integer. See
{{{}AbstractChannel.handleWindowAdjust(){}}}.
> Client fails window adjust above Integer.MAX_VALUE
> --
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java
>
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
>
> I have attached the client implementation to this issue.
> (Maybe a poor implementation ...)
> The console logs, including the debug logs, were too large to attach.
> The parts that are clearly set for the SSH client are as follows.
> ServerKeyVerifier
> HostConfigEntryResolver
> KeyIdentityProvider
> In the log, the part where the error occurred is as follows.
> You can see that SSHD recognizes the new Window size as a negative value.
> {code:java}
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.sftp.client.impl.DefaultSftpClient$SftpChannelSubsystem -
> handleWindowAdjust(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[kada@/192.168.12.222:18022][sftp])
> SSH_MSG_CHANNEL_WINDOW_ADJUST window=-94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleFailure(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) IllegalArgumentException after 8166700 nanos
> at read cycle=103401: Negative window size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) caught IllegalArgumentException[Negative
> window size: -94217] - calling handler
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl -
> signalAuthFailure(ClientSessionImpl[kada@/192.168.12.222:18022])
> type=IllegalArgumentException, signalled=false, first=false: Negative window
> size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] WARN
> org.apache.sshd.client.session.ClientSessionImpl -
> exceptionCaught(ClientSessionImpl[kada@/192.168.12.222:18022])[state=Opened]
> IllegalArgumentException: Negative window size: -94217
> java.lang.IllegalArgumentException: Negative window size: -94217
> at
> org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
> at
> org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
> at
> org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
> at org.apache.sshd.common.channel.Window.expand(Window.java:123)
> at
> org.apache.sshd.common.channel.AbstractChannel.handleWindowAdjust(AbstractChannel.java:894)
> at
> org.apache.sshd.client.channel.AbstractClientChannel.handleWindowAdjust(AbstractClientChannel.java:448)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.channelWindowAdjust(AbstractConnectionService.java:614)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:477)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:526)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:452)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1524)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:412)
> at
>
[jira] [Work started] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SSHD-1244 started by Lyor Goldstein.
> Client fails window adjust above Integer.MAX_VALUE
> --
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java
>
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
>
> I have attached the client implementation to this issue.
> (Maybe a poor implementation ...)
> The console logs, including the debug logs, were too large to attach.
> The parts that are clearly set for the SSH client are as follows.
> ServerKeyVerifier
> HostConfigEntryResolver
> KeyIdentityProvider
> In the log, the part where the error occurred is as follows.
> You can see that SSHD recognizes the new Window size as a negative value.
> {code:java}
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.sftp.client.impl.DefaultSftpClient$SftpChannelSubsystem -
> handleWindowAdjust(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[kada@/192.168.12.222:18022][sftp])
> SSH_MSG_CHANNEL_WINDOW_ADJUST window=-94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleFailure(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) IllegalArgumentException after 8166700 nanos
> at read cycle=103401: Negative window size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) caught IllegalArgumentException[Negative
> window size: -94217] - calling handler
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl -
> signalAuthFailure(ClientSessionImpl[kada@/192.168.12.222:18022])
> type=IllegalArgumentException, signalled=false, first=false: Negative window
> size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] WARN
> org.apache.sshd.client.session.ClientSessionImpl -
> exceptionCaught(ClientSessionImpl[kada@/192.168.12.222:18022])[state=Opened]
> IllegalArgumentException: Negative window size: -94217
> java.lang.IllegalArgumentException: Negative window size: -94217
> at
> org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
> at
> org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
> at
> org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
> at org.apache.sshd.common.channel.Window.expand(Window.java:123)
> at
> org.apache.sshd.common.channel.AbstractChannel.handleWindowAdjust(AbstractChannel.java:894)
> at
> org.apache.sshd.client.channel.AbstractClientChannel.handleWindowAdjust(AbstractClientChannel.java:448)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.channelWindowAdjust(AbstractConnectionService.java:614)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:477)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:526)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:452)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1524)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:412)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
> at
> org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:359)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:336)
> at
> org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:333)
> at
>
[jira] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[ https://issues.apache.org/jira/browse/SSHD-1244 ]
Lyor Goldstein deleted comment on SSHD-1244:
--
was (Author: lgoldstein):
{quote}
You can see that SSHD recognizes the new Window size as a negative value.
{quote}
Not really, all I can see is that it seems that the peer has sent a negative
value. I do not see MAX_INTEGER being treated as a negative value. If it is as
you say, then the log is incomplete...
> Client fails window adjust above Integer.MAX_VALUE
> --
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java
>
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
>
> I have attached the client implementation to this issue.
> (Maybe a poor implementation ...)
> The console logs, including the debug logs, were too large to attach.
> The parts that are clearly set for the SSH client are as follows.
> ServerKeyVerifier
> HostConfigEntryResolver
> KeyIdentityProvider
> In the log, the part where the error occurred is as follows.
> You can see that SSHD recognizes the new Window size as a negative value.
> {code:java}
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.sftp.client.impl.DefaultSftpClient$SftpChannelSubsystem -
> handleWindowAdjust(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[kada@/192.168.12.222:18022][sftp])
> SSH_MSG_CHANNEL_WINDOW_ADJUST window=-94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleFailure(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) IllegalArgumentException after 8166700 nanos
> at read cycle=103401: Negative window size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) caught IllegalArgumentException[Negative
> window size: -94217] - calling handler
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl -
> signalAuthFailure(ClientSessionImpl[kada@/192.168.12.222:18022])
> type=IllegalArgumentException, signalled=false, first=false: Negative window
> size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] WARN
> org.apache.sshd.client.session.ClientSessionImpl -
> exceptionCaught(ClientSessionImpl[kada@/192.168.12.222:18022])[state=Opened]
> IllegalArgumentException: Negative window size: -94217
> java.lang.IllegalArgumentException: Negative window size: -94217
> at
> org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
> at
> org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
> at
> org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
> at org.apache.sshd.common.channel.Window.expand(Window.java:123)
> at
> org.apache.sshd.common.channel.AbstractChannel.handleWindowAdjust(AbstractChannel.java:894)
> at
> org.apache.sshd.client.channel.AbstractClientChannel.handleWindowAdjust(AbstractClientChannel.java:448)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.channelWindowAdjust(AbstractConnectionService.java:614)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:477)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:526)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:452)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1524)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:412)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
> at
>
[jira] [Commented] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486816#comment-17486816
]
Lyor Goldstein commented on SSHD-1244:
--
{quote}
You can see that SSHD recognizes the new Window size as a negative value.
{quote}
Not really, all I can see is that it seems that the peer has sent a negative
value. I do not see MAX_INTEGER being treated as a negative value. If it is as
you say, then the log is incomplete...
> Client fails window adjust above Integer.MAX_VALUE
> --
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java
>
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
>
> I have attached the client implementation to this issue.
> (Maybe a poor implementation ...)
> The console logs, including the debug logs, were too large to attach.
> The parts that are clearly set for the SSH client are as follows.
> ServerKeyVerifier
> HostConfigEntryResolver
> KeyIdentityProvider
> In the log, the part where the error occurred is as follows.
> You can see that SSHD recognizes the new Window size as a negative value.
> {code:java}
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.sftp.client.impl.DefaultSftpClient$SftpChannelSubsystem -
> handleWindowAdjust(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[kada@/192.168.12.222:18022][sftp])
> SSH_MSG_CHANNEL_WINDOW_ADJUST window=-94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleFailure(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) IllegalArgumentException after 8166700 nanos
> at read cycle=103401: Negative window size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) caught IllegalArgumentException[Negative
> window size: -94217] - calling handler
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl -
> signalAuthFailure(ClientSessionImpl[kada@/192.168.12.222:18022])
> type=IllegalArgumentException, signalled=false, first=false: Negative window
> size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] WARN
> org.apache.sshd.client.session.ClientSessionImpl -
> exceptionCaught(ClientSessionImpl[kada@/192.168.12.222:18022])[state=Opened]
> IllegalArgumentException: Negative window size: -94217
> java.lang.IllegalArgumentException: Negative window size: -94217
> at
> org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
> at
> org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
> at
> org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
> at org.apache.sshd.common.channel.Window.expand(Window.java:123)
> at
> org.apache.sshd.common.channel.AbstractChannel.handleWindowAdjust(AbstractChannel.java:894)
> at
> org.apache.sshd.client.channel.AbstractClientChannel.handleWindowAdjust(AbstractClientChannel.java:448)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.channelWindowAdjust(AbstractConnectionService.java:614)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:477)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:526)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:452)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1524)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:412)
> at
> org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
>
[jira] [Commented] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486815#comment-17486815
]
Lyor Goldstein commented on SSHD-1244:
--
{quote}
This seems to be a violation of [RFC4254 - section 5.2]...
Why? Don't know what is meant by "INT_MAX", but Integer.MAX_VALUE is 2^31-1.
{quote}
I know that, but the original description said
{quote}
If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
INT_MAX
{quote}
Emphasis on *exceeds*
> Client fails window adjust above Integer.MAX_VALUE
> --
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java
>
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
>
> I have attached the client implementation to this issue.
> (Maybe a poor implementation ...)
> The console logs, including the debug logs, were too large to attach.
> The parts that are clearly set for the SSH client are as follows.
> ServerKeyVerifier
> HostConfigEntryResolver
> KeyIdentityProvider
> In the log, the part where the error occurred is as follows.
> You can see that SSHD recognizes the new Window size as a negative value.
> {code:java}
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.sftp.client.impl.DefaultSftpClient$SftpChannelSubsystem -
> handleWindowAdjust(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[kada@/192.168.12.222:18022][sftp])
> SSH_MSG_CHANNEL_WINDOW_ADJUST window=-94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleFailure(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) IllegalArgumentException after 8166700 nanos
> at read cycle=103401: Negative window size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) caught IllegalArgumentException[Negative
> window size: -94217] - calling handler
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl -
> signalAuthFailure(ClientSessionImpl[kada@/192.168.12.222:18022])
> type=IllegalArgumentException, signalled=false, first=false: Negative window
> size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] WARN
> org.apache.sshd.client.session.ClientSessionImpl -
> exceptionCaught(ClientSessionImpl[kada@/192.168.12.222:18022])[state=Opened]
> IllegalArgumentException: Negative window size: -94217
> java.lang.IllegalArgumentException: Negative window size: -94217
> at
> org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
> at
> org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
> at
> org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
> at org.apache.sshd.common.channel.Window.expand(Window.java:123)
> at
> org.apache.sshd.common.channel.AbstractChannel.handleWindowAdjust(AbstractChannel.java:894)
> at
> org.apache.sshd.client.channel.AbstractClientChannel.handleWindowAdjust(AbstractClientChannel.java:448)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.channelWindowAdjust(AbstractConnectionService.java:614)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:477)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:526)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:452)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1524)
> at
> org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:412)
> at
>
[jira] [Commented] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486774#comment-17486774
]
Ryosuke Kanda commented on SSHD-1244:
-
> Don't know what is meant by "INT_MAX", but Integer.MAX_VALUE is 2^31-1.
Thank you. Update the title.
> This seems to be a violation of [RFC4254 - section 5.2]
As mentioned above, "INT_MAX" refers to 2 ^ 31-1 which is the maximum value of
int type that is not unsigned.
Therefore, I think it is a problem that we cannot receive a value that exceeds
this (and does not exceed 2 ^ 32-1).
> How do you know that this is the reason for the failure ?
As added to the description.
What should I do if I need a complete debug log?
> BTW, what does ProFTPD have to do with SSHD ?
Earlier, there were reports that our product (using SSHD) could not communicate
with ProFTPD.
This product is currently about to switch to the newer SSHD.
As a result of switching, we are checking whether the problems that occurred in
the past will be improved.
> Client fails window adjust above Integer.MAX_VALUE
> --
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
> Attachments: Main.java
>
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
>
> I have attached the client implementation to this issue.
> (Maybe a poor implementation ...)
> The console logs, including the debug logs, were too large to attach.
> The parts that are clearly set for the SSH client are as follows.
> ServerKeyVerifier
> HostConfigEntryResolver
> KeyIdentityProvider
> In the log, the part where the error occurred is as follows.
> You can see that SSHD recognizes the new Window size as a negative value.
> {code:java}
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.sftp.client.impl.DefaultSftpClient$SftpChannelSubsystem -
> handleWindowAdjust(SftpChannelSubsystem[id=0,
> recipient=0]-ClientSessionImpl[kada@/192.168.12.222:18022][sftp])
> SSH_MSG_CHANNEL_WINDOW_ADJUST window=-94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> handleReadCycleFailure(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) IllegalArgumentException after 8166700 nanos
> at read cycle=103401: Negative window size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.common.io.nio2.Nio2Session -
> exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
> remote=/192.168.12.222:18022]) caught IllegalArgumentException[Negative
> window size: -94217] - calling handler
> [sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
> org.apache.sshd.client.session.ClientSessionImpl -
> signalAuthFailure(ClientSessionImpl[kada@/192.168.12.222:18022])
> type=IllegalArgumentException, signalled=false, first=false: Negative window
> size: -94217
> [sshd-SshClient[343f4d3d]-nio2-thread-5] WARN
> org.apache.sshd.client.session.ClientSessionImpl -
> exceptionCaught(ClientSessionImpl[kada@/192.168.12.222:18022])[state=Opened]
> IllegalArgumentException: Negative window size: -94217
> java.lang.IllegalArgumentException: Negative window size: -94217
> at
> org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
> at
> org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
> at
> org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
> at org.apache.sshd.common.channel.Window.expand(Window.java:123)
> at
> org.apache.sshd.common.channel.AbstractChannel.handleWindowAdjust(AbstractChannel.java:894)
> at
> org.apache.sshd.client.channel.AbstractClientChannel.handleWindowAdjust(AbstractClientChannel.java:448)
> at
> org.apache.sshd.common.session.helpers.AbstractConnectionService.channelWindowAdjust(AbstractConnectionService.java:614)
> at
>
[jira] [Updated] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryosuke Kanda updated SSHD-1244:
Description:
If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
INT_MAX, it will not be recognized correctly.
I think the cause is in the following places:
org.apache.sshd.common.channel.Window.expand（int）
I am doing machine translation, so please allow it to be unnatural.
I encountered this issue when I was using ProFTPD as an SFTP server.
The version of ProFTPD is 1.3.5e.
The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window size
by default.
I've confirmed that SSHD can handle this without any problems, so I sent a 4GB
file to see what happens when Window Adjust is done.
As a result, a Window Adjust was done and SSHD was unable to handle this
successfully.
I have attached the client implementation to this issue.
(Maybe a poor implementation ...)
The console logs, including the debug logs, were too large to attach.
The parts that are clearly set for the SSH client are as follows.
ServerKeyVerifier
HostConfigEntryResolver
KeyIdentityProvider
In the log, the part where the error occurred is as follows.
You can see that SSHD recognizes the new Window size as a negative value.
{code:java}
[sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
org.apache.sshd.sftp.client.impl.DefaultSftpClient$SftpChannelSubsystem -
handleWindowAdjust(SftpChannelSubsystem[id=0,
recipient=0]-ClientSessionImpl[kada@/192.168.12.222:18022][sftp])
SSH_MSG_CHANNEL_WINDOW_ADJUST window=-94217
[sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
handleReadCycleFailure(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
remote=/192.168.12.222:18022]) IllegalArgumentException after 8166700 nanos at
read cycle=103401: Negative window size: -94217
[sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
org.apache.sshd.common.io.nio2.Nio2Session -
exceptionCaught(Nio2Session[local=/0:0:0:0:0:0:0:0:51143,
remote=/192.168.12.222:18022]) caught IllegalArgumentException[Negative window
size: -94217] - calling handler
[sshd-SshClient[343f4d3d]-nio2-thread-5] DEBUG
org.apache.sshd.client.session.ClientSessionImpl -
signalAuthFailure(ClientSessionImpl[kada@/192.168.12.222:18022])
type=IllegalArgumentException, signalled=false, first=false: Negative window
size: -94217
[sshd-SshClient[343f4d3d]-nio2-thread-5] WARN
org.apache.sshd.client.session.ClientSessionImpl -
exceptionCaught(ClientSessionImpl[kada@/192.168.12.222:18022])[state=Opened]
IllegalArgumentException: Negative window size: -94217
java.lang.IllegalArgumentException: Negative window size: -94217
at
org.apache.sshd.common.util.ValidateUtils.createFormattedException(ValidateUtils.java:213)
at
org.apache.sshd.common.util.ValidateUtils.throwIllegalArgumentException(ValidateUtils.java:179)
at
org.apache.sshd.common.util.ValidateUtils.checkTrue(ValidateUtils.java:162)
at org.apache.sshd.common.channel.Window.expand(Window.java:123)
at
org.apache.sshd.common.channel.AbstractChannel.handleWindowAdjust(AbstractChannel.java:894)
at
org.apache.sshd.client.channel.AbstractClientChannel.handleWindowAdjust(AbstractClientChannel.java:448)
at
org.apache.sshd.common.session.helpers.AbstractConnectionService.channelWindowAdjust(AbstractConnectionService.java:614)
at
org.apache.sshd.common.session.helpers.AbstractConnectionService.process(AbstractConnectionService.java:477)
at
org.apache.sshd.common.session.helpers.AbstractSession.doHandleMessage(AbstractSession.java:526)
at
org.apache.sshd.common.session.helpers.AbstractSession.handleMessage(AbstractSession.java:452)
at
org.apache.sshd.common.session.helpers.AbstractSession.decode(AbstractSession.java:1524)
at
org.apache.sshd.common.session.helpers.AbstractSession.messageReceived(AbstractSession.java:412)
at
org.apache.sshd.common.session.helpers.AbstractSessionIoHandler.messageReceived(AbstractSessionIoHandler.java:64)
at
org.apache.sshd.common.io.nio2.Nio2Session.handleReadCycleCompletion(Nio2Session.java:359)
at
org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:336)
at
org.apache.sshd.common.io.nio2.Nio2Session$1.onCompleted(Nio2Session.java:333)
at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler.lambda$completed$0(Nio2CompletionHandler.java:38)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:37)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
at sun.nio.ch.Invoker$2.run(Invoker.java:218)
at
sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
[jira] [Updated] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[ https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryosuke Kanda updated SSHD-1244: Attachment: Main.java > Client fails window adjust above Integer.MAX_VALUE > -- > > Key: SSHD-1244 > URL: https://issues.apache.org/jira/browse/SSHD-1244 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Ryosuke Kanda >Assignee: Lyor Goldstein >Priority: Minor > Attachments: Main.java > > > If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds > INT_MAX, it will not be recognized correctly. > I think the cause is in the following places: > org.apache.sshd.common.channel.Window.expand（int） > > I am doing machine translation, so please allow it to be unnatural. > > I encountered this issue when I was using ProFTPD as an SFTP server. > The version of ProFTPD is 1.3.5e. > The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window > size by default. > I've confirmed that SSHD can handle this without any problems, so I sent a > 4GB file to see what happens when Window Adjust is done. > As a result, a Window Adjust was done and SSHD was unable to handle this > successfully. > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[ https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryosuke Kanda updated SSHD-1244: Description: If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds INT_MAX, it will not be recognized correctly. I think the cause is in the following places: org.apache.sshd.common.channel.Window.expand（int） I am doing machine translation, so please allow it to be unnatural. I encountered this issue when I was using ProFTPD as an SFTP server. The version of ProFTPD is 1.3.5e. The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window size by default. I've confirmed that SSHD can handle this without any problems, so I sent a 4GB file to see what happens when Window Adjust is done. As a result, a Window Adjust was done and SSHD was unable to handle this successfully. was: If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds INT_MAX, it will not be recognized correctly. I think the cause is in the following places: org.apache.sshd.common.channel.Window.expand（int） I am doing machine translation, so please allow it to be unnatural. I encountered this issue when I was using ProFTPD as an SFTP server. The version of ProFTPD is 1.3.5e. The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window size by default. I've confirmed that SSHD can handle this without any problems, so I sent a 4GB file to see what happens when Window Adjust is done. As a result, a Window Adjust was done and SSHD was unable to handle this successfully. > Client fails window adjust above Integer.MAX_VALUE > -- > > Key: SSHD-1244 > URL: https://issues.apache.org/jira/browse/SSHD-1244 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Ryosuke Kanda >Assignee: Lyor Goldstein >Priority: Minor > > If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds > INT_MAX, it will not be recognized correctly. > I think the cause is in the following places: > org.apache.sshd.common.channel.Window.expand（int） > > I am doing machine translation, so please allow it to be unnatural. > > I encountered this issue when I was using ProFTPD as an SFTP server. > The version of ProFTPD is 1.3.5e. > The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window > size by default. > I've confirmed that SSHD can handle this without any problems, so I sent a > 4GB file to see what happens when Window Adjust is done. > As a result, a Window Adjust was done and SSHD was unable to handle this > successfully. > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1244) Client fails window adjust above Integer.MAX_VALUE
[ https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryosuke Kanda updated SSHD-1244: Summary: Client fails window adjust above Integer.MAX_VALUE (was: Client fails window adjust above INT_MAX) > Client fails window adjust above Integer.MAX_VALUE > -- > > Key: SSHD-1244 > URL: https://issues.apache.org/jira/browse/SSHD-1244 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Ryosuke Kanda >Assignee: Lyor Goldstein >Priority: Minor > > If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds > INT_MAX, it will not be recognized correctly. > I think the cause is in the following places: > org.apache.sshd.common.channel.Window.expand（int） > > I am doing machine translation, so please allow it to be unnatural. > > I encountered this issue when I was using ProFTPD as an SFTP server. > The version of ProFTPD is 1.3.5e. > The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window > size by default. > I've confirmed that SSHD can handle this without any problems, so I sent a > 4GB file to see what happens when Window Adjust is done. > As a result, a Window Adjust was done and SSHD was unable to handle this > successfully. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1244) Client fails window adjust above INT_MAX
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486702#comment-17486702
]
Thomas Wolf commented on SSHD-1244:
---
{quote}This seems to be a violation of [RFC4254 - section 5.2]...{quote}
Why? Don't know what is meant by "INT_MAX", but Integer.MAX_VALUE is 2^31-1.
> Client fails window adjust above INT_MAX
>
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1244) Client fails window adjust above INT_MAX
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486627#comment-17486627
]
Lyor Goldstein edited comment on SSHD-1244 at 2/3/22, 5:43 PM:
---
BTW, what does ProFTPD have to do with SSHD ? According to its own site
{quote}
Highly configurable GPL-licensed FTP server software
{quote}
It does not seem to mention SFTP which is +nor+ FTP neither a "secure" version
of it, but rather something entirely different - see
http://www.proftpd.org/features.html It does provide an SFTP "module"
(http://www.proftpd.org/docs/contrib/mod_sftp.html) but it seems to be more of
an afterthought + the version you mentioned (1.3.5e) is very old (~5 years).
Perhaps it has a bug that has been fixed since then. In any case, is there any
specific reason +not+ to use OpenSSH or some other more widely used server
(maybe even SSHD itself)
was (Author: lgoldstein):
BTW, what does ProFTPD have to do with SSHD ? According to its own site
{quote}
Highly configurable GPL-licensed FTP server software
{quote}
It does not seem to mention SFTP which is +nor+ FTP neither a "secure" version
of it, but rather something entirely different - see
http://www.proftpd.org/features.html
> Client fails window adjust above INT_MAX
>
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Comment Edited] (SSHD-1244) Client fails window adjust above INT_MAX
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486627#comment-17486627
]
Lyor Goldstein edited comment on SSHD-1244 at 2/3/22, 5:40 PM:
---
BTW, what does ProFTPD have to do with SSHD ? According to its own site
{quote}
Highly configurable GPL-licensed FTP server software
{quote}
It does not seem to mention SFTP which is +nor+ FTP neither a "secure" version
of it, but rather something entirely different - see
http://www.proftpd.org/features.html
was (Author: lgoldstein):
BTW, what does ProFTPD have to do with SSHD ? According to its own site
{quote}
Highly configurable GPL-licensed FTP server software
{quote}
It does not seem to mention SFTP which is +nor+ FTP neither a "secure" version
of it, but rather something entirely different.
> Client fails window adjust above INT_MAX
>
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1244) Client fails window adjust above INT_MAX
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486627#comment-17486627
]
Lyor Goldstein commented on SSHD-1244:
--
BTW, what does ProFTPD have to do with SSHD ? According to its own site
{quote}
Highly configurable GPL-licensed FTP server software
{quote}
It does not seem to mention SFTP which is +nor+ FTP neither a "secure" version
of it, but rather something entirely different.
> Client fails window adjust above INT_MAX
>
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1244) Client fails window adjust above INT_MAX
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486625#comment-17486625
]
Lyor Goldstein commented on SSHD-1244:
--
{quote}
The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window size
by default.
I've confirmed that SSHD can handle this without any problems, so I sent a 4GB
file to see what happens when Window Adjust is done.
{quote}
Good idea
{quote}
As a result, a Window Adjust was done and SSHD was unable to handle this
successfully.
{quote}
* How do you know that this is the reason for the failure ?
* Based on what log messages have you reached the conclusion that "a Window
Adjust was done" ?
* "SSHD was unable to handle this successfully" - I believe you that SSHD
failed, but how can you attribute it to {{SSH_MSG_CHANNEL_WINDOW_ADJUST}} with
such certainty ? Perhaps the failure is unrelated, and we might be chasing a
wrong track.
* Have you looked at the log messages ? Can you attach it and indicate where
the failure occurred and why you believe this is related to
{{SSH_MSG_CHANNEL_WINDOW_ADJUST}} ?
* How have you initialized your SSH client ? Have you used the default
configuration or added some of your own ?
There could be a myriad of reasons for the failure - without more information
about your code and log messages it is very difficult to tell what was the
reason for the failure, As I have said, it might not be
{{SSH_MSG_CHANNEL_WINDOW_ADJUST}} since as you yourself claim
{quote}
I've confirmed that SSHD can handle this without any problems
{quote}
> Client fails window adjust above INT_MAX
>
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1244) Client fails window adjust above INT_MAX
[
https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486620#comment-17486620
]
Lyor Goldstein commented on SSHD-1244:
--
{quote}
If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
INT_MAX
{quote}
This seems to be a violation of [RFC4254 - section
5.2](https://datatracker.ietf.org/doc/html/rfc4254#section-5.2)
{quote}
The window size specifies how many bytes the other party can send
before it must wait for the window to be adjusted. Both parties use
the following message to adjust the window.
byte SSH_MSG_CHANNEL_WINDOW_ADJUST
uint32recipient channel
uint32bytes to add
After receiving this message, the recipient MAY send the given number
of bytes more than it was previously allowed to send; the window size
is incremented. Implementations MUST correctly handle window sizes
of up to 2^32 - 1 bytes. The window MUST NOT be increased above
2^32 - 1 bytes.
{quote}
> Client fails window adjust above INT_MAX
>
>
> Key: SSHD-1244
> URL: https://issues.apache.org/jira/browse/SSHD-1244
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.8.0
>Reporter: Ryosuke Kanda
>Assignee: Lyor Goldstein
>Priority: Minor
>
> If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds
> INT_MAX, it will not be recognized correctly.
> I think the cause is in the following places:
> org.apache.sshd.common.channel.Window.expand（int）
>
> I am doing machine translation, so please allow it to be unnatural.
>
> I encountered this issue when I was using ProFTPD as an SFTP server.
> The version of ProFTPD is 1.3.5e.
> The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window
> size by default.
> I've confirmed that SSHD can handle this without any problems, so I sent a
> 4GB file to see what happens when Window Adjust is done.
> As a result, a Window Adjust was done and SSHD was unable to handle this
> successfully.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1244) Client fails window adjust above INT_MAX
[ https://issues.apache.org/jira/browse/SSHD-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lyor Goldstein reassigned SSHD-1244: Assignee: Lyor Goldstein > Client fails window adjust above INT_MAX > > > Key: SSHD-1244 > URL: https://issues.apache.org/jira/browse/SSHD-1244 > Project: MINA SSHD > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Ryosuke Kanda >Assignee: Lyor Goldstein >Priority: Minor > > If the new window size specified by SSH_MSG_CHANNEL_WINDOW_ADJUST exceeds > INT_MAX, it will not be recognized correctly. > I think the cause is in the following places: > org.apache.sshd.common.channel.Window.expand（int） > > I am doing machine translation, so please allow it to be unnatural. > > I encountered this issue when I was using ProFTPD as an SFTP server. > The version of ProFTPD is 1.3.5e. > The SFTP feature of ProFTPD notifies 2 ^ 32-1 bytes as the initial window > size by default. > I've confirmed that SSHD can handle this without any problems, so I sent a > 4GB file to see what happens when Window Adjust is done. > As a result, a Window Adjust was done and SSHD was unable to handle this > successfully. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1161) Accessing the session buffer of multiple decoders
[
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486562#comment-17486562
]
Pavel Garin commented on DIRMINA-1161:
--
Data compressed in chunks !mina.png!
> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
> Attachments: mina.png
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
> {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1161) Accessing the session buffer of multiple decoders
[
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Garin updated DIRMINA-1161:
-
Attachment: mina.png
> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
> Attachments: mina.png
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
> {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-ftpserver] elecharny commented on issue #8: TLS protocol is not enabled correctly, also only one can be set
elecharny commented on issue #8: URL: https://github.com/apache/mina-ftpserver/issues/8#issuecomment-1029090165 I'm in the last phase, checking if we don't have dependencies to bump up, for MINA 2.1.X. So I may be able to cut the release tonite. MINA 2.0.X will take a bit of time -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1161) Accessing the session buffer of multiple decoders
[
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486480#comment-17486480
]
Jonathan Valliere commented on DIRMINA-1161:
Can't do that either. The AttributeKeys are global for the entire IoSession.
What is the use-case for this?
> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
> {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1161) Accessing the session buffer of multiple decoders
[
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486466#comment-17486466
]
Pavel Garin commented on DIRMINA-1161:
--
Decoders do not work in parallel with one session. They are added one after
another in filterChain.
{code:java}
filterChain.addLast("first" , new ProtocolCodecFilter(firstCodecFactory));
//firstCodecFactory.getDecoder(IoSession session) return instance class A
extends CumulativeProtocolDecoder
filterChain.addLast("second", new ProtocolCodecFilter(secondCodecFactory));
//secondCodecFactory.getDecoder(IoSession session) return instance class B
extends CumulativeProtocolDecoder
{code}
> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
> {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1161) Accessing the session buffer of multiple decoders
[
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486425#comment-17486425
]
Jonathan Valliere commented on DIRMINA-1161:
The ProtocolDecoder system is not concurrent and does not support one
Session operating concurrent via ThreadExecutors.
This has been resolved in an upcoming release.
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
> {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
Re: [jira] [Updated] (DIRMINA-1161) Accessing the session buffer of multiple decoders
The ProtocolDecoder system is not concurrent and does not support one
Session operating concurrent via ThreadExecutors.
This has been resolved in an upcoming release.
On Thu, Feb 3, 2022 at 5:17 AM Pavel Garin (Jira) wrote:
>
> [
> https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Pavel Garin updated DIRMINA-1161:
> -
> Description:
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(),
> "buffer"); {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
>
>
>
> was:
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(),
> "buffer"); {code}
> has been replaced with line
>
>
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
>
>
>
>
> > Accessing the session buffer of multiple decoders
> > -
> >
> > Key: DIRMINA-1161
> > URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> > Project: MINA
> > Issue Type: Bug
> > Components: Core
> >Affects Versions: 2.0.22, 2.1.4
> > Environment: Ubuntu 16.04.7 LTS
> > Open JDK 11.0.10
> > Mina 2.0.22
> >Reporter: Pavel Garin
> >Priority: Major
> > Fix For: 2.0.23, 2.1.5
> >
> >
> > As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
> >
> > {code:java}
> > private final AttributeKey BUFFER = new AttributeKey(getClass(),
> "buffer"); {code}
> > has been replaced with line
> > {code:java}
> > private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> > When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> > {code:java}
> > IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> > has become the same for all decoders.
> >
> >
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.1#820001)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
>
> --
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
[GitHub] [mina-ftpserver] marcelkoopman commented on issue #8: TLS protocol is not enabled correctly, also only one can be set
marcelkoopman commented on issue #8: URL: https://github.com/apache/mina-ftpserver/issues/8#issuecomment-1028901053 @elecharny Sorry to bother you again, can you please make a new MINA release? It would really help my project. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: MINA 2.2 SSLFilterTest failure
Hi,
also notice that the ConnectorTest.testTCPWithSSL() test is failing for
the exact same reason: we open a connection, install TLS over it,
exchange a message, then close the TLS session, and try to reestablish it.
This test will be removed.
On 01/02/2022 06:15, Emmanuel Lécharny wrote:
Hi,
in the past few days - I should rather past few nights actually ;-) - we
were tracking the reason the SslFilterTest was failing in MINA 2.2 in
some specific condition (the client uses TLS 1.2 or lower).
The test is really trying to cover some very corner case:
- we use a Echo Handler, where the messageSent() handler will close the
connection when 2 messages have been sent:
@Override
public void messageSent(IoSession session, Object message)
throws Exception {
sentMessages.add(message.toString());
if (sentMessages.size() >= 2) {
session.closeNow();
}
}
- the client sends a first message:
output.write("test-1\n");
output.flush();
- it reads the response:
assert input.readLine().equals("test-1");
- the client invalidate the SSL session and start a new TLSHandShake:
ss.getSession().invalidate();
ss.startHandshake();
- the client sends a second message:
output.write("test-2\n");
output.flush();
- the server process the handshake, then get the message ("test-2\n"),
then immediately close the connection because it's the second message:
public void messageSent(IoSession session, Object message) throws
Exception {
sentMessages.add(message.toString());
if (sentMessages.size() >= 2) {
session.closeNow();
}
}
- the client tries to read the response:
assert input.readLine().equals("test-2");
At this point, you'll get a failure.
The reason it fails is that when the second message has been sent, the
server has closed the connection brutally (by closing the Channel),
leaving the client with a closed connection. and no data to be read.
There is a kind of race condition where the second response has been
fully encoded, and pushed into the socket, on the server side,
immediately followed by the channel closure. The client might not have
had the time to read anything before the channel has been closed (to be
double checked).
Anyway, the discussion ended on the following concensus:
- This test will no remain as is
- The renegociation is not any more accepted in TLS 1.3, for very good
reason (https://fr.slideshare.net/ThierryZoller/practicaltls1)
- It has also been disabled by default by Oracle
(https://www.oracle.com/java/technologies/javase/tlsreadme.html)
thus the test will be @Ignored with no attempt to fix the SslFilter
implemented logic.
Thanks !
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (DIRMINA-1161) Accessing the session buffer of multiple decoders
[
https://issues.apache.org/jira/browse/DIRMINA-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Garin updated DIRMINA-1161:
-
Description:
As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
{code:java}
private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
{code}
has been replaced with line
{code:java}
private static final AttributeKey BUFFER = new
AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
When using an architecture where multiple decoders inherited from
CumulativeProtocolDecoder are used, the decoders corrupt each other's data. The
key for the attribute in line
{code:java}
IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
has become the same for all decoders.
was:
As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
{code:java}
private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
{code}
has been replaced with line
{code:java}
private static final AttributeKey BUFFER = new
AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
When using an architecture where multiple decoders inherited from
CumulativeProtocolDecoder are used, the decoders corrupt each other's data. The
key for the attribute in line
{code:java}
IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
has become the same for all decoders.
> Accessing the session buffer of multiple decoders
> -
>
> Key: DIRMINA-1161
> URL: https://issues.apache.org/jira/browse/DIRMINA-1161
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.22, 2.1.4
> Environment: Ubuntu 16.04.7 LTS
> Open JDK 11.0.10
> Mina 2.0.22
>Reporter: Pavel Garin
>Priority: Major
> Fix For: 2.0.23, 2.1.5
>
>
> As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
>
> {code:java}
> private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
> {code}
> has been replaced with line
> {code:java}
> private static final AttributeKey BUFFER = new
> AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
> When using an architecture where multiple decoders inherited from
> CumulativeProtocolDecoder are used, the decoders corrupt each other's data.
> The key for the attribute in line
> {code:java}
> IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
> has become the same for all decoders.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Created] (DIRMINA-1161) Accessing the session buffer of multiple decoders
Pavel Garin created DIRMINA-1161:
Summary: Accessing the session buffer of multiple decoders
Key: DIRMINA-1161
URL: https://issues.apache.org/jira/browse/DIRMINA-1161
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.1.4, 2.0.22
Environment: Ubuntu 16.04.7 LTS
Open JDK 11.0.10
Mina 2.0.22
Reporter: Pavel Garin
Fix For: 2.0.23, 2.1.5
As of Mina 2.0.17, the line of code in CumulativeProtocolDecoder
{code:java}
private final AttributeKey BUFFER = new AttributeKey(getClass(), "buffer");
{code}
has been replaced with line
{code:java}
private static final AttributeKey BUFFER = new
AttributeKey(CumulativeProtocolDecoder.class, "buffer");{code}
When using an architecture where multiple decoders inherited from
CumulativeProtocolDecoder are used, the decoders corrupt each other's data. The
key for the attribute in line
{code:java}
IoBuffer buf = (IoBuffer) session.getAttribute(BUFFER);{code}
has become the same for all decoders.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
