Hello list!
My situation is that I am using jsch-0.1.36 to connect to a Global Scape
SFTP server (version 3.6).
When using a ChannelSftp object to do a ls on a directory that has >240
files in where each file had a name that was 30 characters or more in
length, I was finding that I get an unexpected exception because the io
object goes null during the attempt to get the list. It was pretty
obvious that the damage was being done while the read thread was dealing
with data from the server. The crash was soon after the sendREADDIR() is
called within the ls() function.
After replicating the problem on a test environment, I was able to
determined that this server is returning packets that were bigger than
expected by the code in Session.read()
Since the buffer to accommodate the data returned is allocated according
to the size of the returned data I felt it safe to change the code as
follows:
In the code for "public Buffer read(Buffer buf) throws Exception{" :
...
// RFC 4253 6.1. Maximum Packet Length
if(j<5){ // JMS || j>(32768-4)){
throw new IOException("invalid data");
}
j=j+4-s2ccipher_size;
...
You can see that I removed the test j>(32768-4) from the if statement.
This was the only change I needed to make to fix my problem.
I admit that this is probably something to do with Globalscape's
implementation (the packet size returned was around 70k) and for large
directories there were many of these size packets, but I was wondering
if someone more knoweledgable about the RFC can comment on the relevance
of this constraint in the code. Can we perhaps set the threshold higher,
say to 128k and have a more meaningful exception raised when things go
wrong? Right now I was finding that the exception returned to the client
was pretty meaningless.
Note: No other SFTP client that I tried ran into this problem, they all
handled directories with files up to 20,000 files in on the same
Globalscape SFTP server (version 3.6)
John..
____________________________________
This e-mail may be privileged and/or confidential, and the sender does not
waive any related rights and obligations. Any distribution, use or copying of
this e-mail or the information it contains by other than an intended
recipient(s) is unauthorized. If you received this e-mail in error, please
advise me (by return e-mail or otherwise) immediately and delete this e-mail.
The contents of any attachment to this e-mail may contain software
viruses or other defect which might affect your own computer system once
received or opened. While companies under RBC Dexia Investor Services Trust and
its affiliates take reasonable precautions to minimize that risk, we cannot
accept liability or responsibility for any damage or loss which may occur or be
sustained as a result of a software virus or other defect. You are responsible
for virus checks before opening any attachment.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
JSch-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jsch-users
