tomaswolf commented on issue #263: URL: https://github.com/apache/mina-sshd/issues/263#issuecomment-2269568291
@116-7 Looks like your problem is different than SSHD-1204. That TCP packet for the server's KEX_INIT is given as having 992 bytes, which matches the length recorded inside the packet (0x3dc = 988 bytes, + 4 bytes for the length itself). So you're not getting a single TCP message with KEX_INIT and server ident swapped as it happened in SSHD-1204. I do not see anything obvious in Apache MINA sshd that would explain how a server could send the KEX_INIT without having sent its identification first. The identification string is sent in the constructor of the server session. Now "sent" actually means the message is placed into the write queue to be sent by the underlying transport (NIO2, MINA, or Netty). In all three cases I don't see how the server's KEX_INIT could overtake that identification message in that queue; nor do I see any way how the server could put its KEX_INIT message into that queue first (so that the identification message would be the second message by mistake). For NIO2, there is an explicit message queue. For MINA, there is an explicit message queue inside the MINA library. For Netty, message order is ensured by chaining futures and using writeAndFlush always. All three implementations appear correct. Even if I go back to source code revisions from before Apache MINA sshd 2.8.0 the message handling at that transport level appears to be fine in that respect. I've not succeeded writing a unit test that would reproduce the issue you describe. On top of that, I don't know which transport Bitbucket server is using. Could be any of the three we provide, or they might have written their own. We could add code to make sure that the server's KEX_INIT does explicitly wait until that identification message has been sent (as opposed to be queued for sending). It's a bit more complicated to do than I like, but it is doable, and it might perhaps be a good idea in any case. It won't help with your particular problem, though, since apparently you cannot control the server side software. -- 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
