tomaswolf commented on issue #509: URL: https://github.com/apache/mina-sshd/issues/509#issuecomment-2133926998
Next time please provide the buffer content as copyable text. A screenshot is extremely cumbersome to work with. What server is this? It appears to be broken. If I parse this buffer content as an SFTP v6 SSH_FXP_ATTR packet, I cannot match it against the [draft RFC](https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-13#section-7). - 0 0 0 69 Length of following data - 105 SSH_FXP_ATTR - 0 0 0 102 Request ID. - 0 0 -1 -1 Flags. hex 0x00_00_FF_FF. Strange that all bits are set. In particular, 0x2 should not occur. - 2 File type; 2 is a directory - 0 0 0 0 0 0 16 0 File size, 0x1000 = 4096 bytes - And now things go wrong: because bit 0x400 is set in the flags, we read the next 8 bytes as "allocation size", but its not present. Instead the buffer continues with - 0 0 0 11 Length of the string following (11 bytes, apparently owner name) - 105 116 101 115 99 111 95 114 111 111 116 = "itesco_root" - 0 0 0 8 String length - 102 116 112 103 114 111 117 112 = "ftpgroup" - ... Because we read an allocation size (due to the wrong flags), we skip 8 bytes and end up reading some of the characters (bytes 99 111 95 114, hex 0x63_6F_5F_72) as a string length, and then the exception occurs. What server is this? It is broken; it sends invalid flags. We cannot do anything about this in the client side. File a bug report against that server, and try to avoid using SFTP v6 for that server: force SFTP v3. -- 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
