Thomas Wolf

AFAIK dropbear does not have SFTP, so some external SFTP is used. Either OpenSSH, or some other implementation. Do you have more information on that server? Since it occurs apparently...

I need the log with log level TRACE. Only that will log precise offsets and lengths of data received. I also will need byte offsets. Line numbers won't help me....

Something strange is going on at the end; the last request (id=6346) should be sent for offset 204423955 + 1842, not +32755. That looks like a bug, but it doesn't...

Why did I miss that? Anyway: no need for further logs. You found the reason. That's exactly what I wrote above: from code inspection, this can happen if the server...

I cannot answer your questions. I don't know what other buffer sizes these other SFTP clients used, or why it occurs every 640 requests. Perhaps the other clients might have...

41084 - 32764 = 8320 204500679 - 204425799 = 74880 74880 / 8320 = 9 The offset_ko.txt log seems to contain the result of three consecutive downloads? The first two...

Can you please verify the locations (byte offsets) of the duplications. From your log, I would expect the first such duplication to be at offset 20995955: 8320 bytes duplicated, i.e.,...

I've been wondering about -13 myself. The -13 aligns the SFTP buffer size such that the whole SSH_FXP_DATA SFTP message fits a channel packet exactly. (There's 13 bytes of overhead...

At least their server logs confirm that the server _did_ send too much data overall. I wonder if the server logs also show the 9 SSH_FXP_DATA replies of 41075 bytes...

I've merged a change that tightens SFTP read requests. If a server sends back more data than requested, an exception is thrown. If you set `SftpModuleProperties.TOLERATE_EXCESS_DATA` to `true`, we only...