FileZilla Forums

We are receiving the following error when attempting to complete a directory listing with Filezilla using SFTP: SFTP Error - Incoming packet was garbled on decryption

Our FTP/SFTP server software is Globalscape EFT Server. In the EFT server logs we are seeing:
2007-11-26 18:24:08 72.243.137.17 - - [81802]ssh_disconnect disconnect_by_application - 511 - - - 22

The error only occurs when utilizing SFTP not traditional FTP. Furthermore I can complete a directory listing successfully both with WinSCP and SSH.Com Tectia SFTP client. Which leads me to think that this may be a bug in Filezilla/Putty not our server software.

I enabled debugging in Filezilla below is two different directory listings done through SFTP. One which WAS successful and one which was NOT successful. The problem seems specific to particular directories. I tried to narrow down the problem to a specific file and was ultimately unable to.

Here is an unsuccessful listing:
Status: Connecting to *MASKED*:22...
Trace: Going to execute "C:\Program Files\FileZilla Client\fzsftp.exe"
Response: fzSftp started
Trace: CSftpControlSocket::ConnectParseResponse(fzSftp started)
Command: open "*MASKED*@*MASKED*" 22
Trace: Looking up host "*MASKED*"
Trace: Connecting to *MASKED* port 22
Trace: Server version: SSH-2.0-1.36_sshlib GlobalSCAPE
Trace: Using SSH protocol version 2
Trace: We claim version: SSH-2.0-PuTTY_Local:_Nov__7_2007_01:50:23
Trace: Using Diffie-Hellman with standard group "group1"
Trace: Doing Diffie-Hellman key exchange with hash SHA-1
Trace: Host key fingerprint is:
Trace: ssh-dss 1024 *MASKED*
Trace: Initialised AES-128 CBC client->server encryption
Trace: Initialised HMAC-SHA1 client->server MAC algorithm
Trace: Initialised AES-128 CBC server->client encryption
Trace: Initialised HMAC-SHA1 server->client MAC algorithm
Command: Pass: ******
Trace: Sent password
Trace: Access granted
Trace: Opened channel for session
Trace: Started a shell/command
Status: Connected to *MASKED*
Trace: CSftpControlSocket::ConnectParseResponse()
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Retrieving directory listing...
Command: pwd
Response: Current directory is: "/"
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CSftpControlSocket::SendNextCommand(0)
Trace: CSftpControlSocket::ListSend(0)
Trace: state = 1
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
Status: Retrieving directory listing...
Command: cd "/store_images/"
Response: New directory is: "/store_images"
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CSftpControlSocket::SendNextCommand(0)
Trace: CSftpControlSocket::ListSend(0)
Trace: state = 1
Command: ls
Status: Listing directory /store_images
Trace: Incoming packet was garbled on decryption
Error: Incoming packet was garbled on decryption
Trace: CSftpControlSocket::ResetOperation(66)
Trace: CControlSocket::ResetOperation(66)
Error: Failed to retrieve directory listing

Here is a successful listing:

Status: Retrieving directory listing...
Command: cd "Includes"
Response: New directory is: "/Includes"
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CSftpControlSocket::SendNextCommand(0)
Trace: CSftpControlSocket::ListSend(0)
Trace: state = 1
Command: ls
Status: Listing directory /Includes
Listing: -rw-rw-rw- 1 user group 12035 Oct 28 13:22 store.css
Listing: -rw-rw-rw- 1 user group 9746 Oct 28 13:22 basket_include.js
Listing: -rw-rw-rw- 1 user group 12522 Oct 28 13:22 estore.css
Trace: CSftpControlSocket::ListParseResponse()
Trace: CSftpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful

For security reasons, I have removed any information which may be sensitive and replaced it with "*MASKED*". I don't believe I have removed anything noteworthy for debugging purposes but I am trying to be somewhat cautious since this is a public forum.

Any assistance or suggestions on how to address this problem would be appreciated. At the moment I seem to be able to reproduce it on demand so can run tests as needed.

Thanks
Brad

FileZilla's SFTP support is based on PuTTY. Please try the psftp program from the PuTTY homepage with your server: http://www.chiark.greenend.org.uk/~sgtatham/putty/

Putty PSFTP version 0.60.0.0 can successfully connect and complete a file listing without an error. Any other suggestions?


Update:
I tested Filezilla 2.3.2 and that CAN successfully list the files in the directory mentioned above. Whereas Filezilla 3.0.3 and 3.0.4.1 can NOT list them.

Did something change from an SFTP standpoint between these versions? I noted the following bugfix in putty .59:

- 0.59 could emit malformed SSH-2 packets that upset some servers
(such as Foundry routers). Fixed.

Is filezilla 3.0.3 and 3.0.4.1 using a version of putty based build .59?


Update:
I found and downloaded PSFTP .58 and .59 and attempted to connect and do a file listing with those. They both work fine. I did note that when running fzsftp -V I get psftp: Unidentified build, Nov 7 2007 01:50:23. So it would seem filezilla may be running a customized build of putty anyway.

I'm running low on ideas. Its looking more and more like a Filezilla problem.


Update:
I have setup a test SFTP site which demonstrates this problem. I'd be more than happy to provide the login details to a Filezilla developer. Obviously for security reasons I won't publish them here. If you are a filezilla developer - please PM me for details.

*bump*

I have managed to reproduce the problem with the latest development version of psftp (http://www.tartarus.org/~simon/putty-sn ... /psftp.exe), indicating that this is indeed a regression in PuTTY. Please contact the PuTTY developers.

Wow ok - It seemed to work fine with putty .60 - I didn't even think to try the development build! Thank you for the help. I'll contact putty developers.

I started getting this problem last night and have looked into it. There are two possible causes, in my case:

(1) OpenSSH bug / solution: use AES 128-bit encryption

PuTTy bug report referencing FileZilla:
http://www.chiark.greenend.org.uk/~sgta ... axpkt.html

PuTTy FAQ entry about OpenSSH bug:
http://the.earth.li/~sgtatham/putty/0.5 ... tml#A.6.18

Third party details a fix:
http://fixunix.com/ssh/74200-putty-0-60 ... oblem.html

(2) Comcast blocking or interrupting SSH traffic / solution: switch ISP

http://www.slugsite.com/archives/690

The connection I'm using now is (I think) Comcast-based, although why they'd block or disrupt SSH is beyond me, unless there's some darknet which transfers bazillions of gigabytes of encrypted illegality.

I believe this: http://www.chiark.greenend.org.uk/~sgta ... axpkt.html was actually the bug we reported to putty last November.

Supposedly a work around has been incorporated into newer builds of putty but I'm not sure if Filezilla is using the newer builds yet as we still have many of our users complaining about this bug.

In any case, Globalscape (our SFTP server software vendor) has committed to releasing a version of their software (EFT) with newer versions of SSH libraries - which will supposedly address this problem. Their anticipated release date is sometime in late May/early June.

At the moment we are suggesting one of two workarounds to our users:

Downgrade to the last 2.x version of Filezilla (which use older builds of putty)
Use an alternate SFTP client such as WinSCP

Brad

Third option: Get a better server

My interpretation of the problem is that its not really a bug with the server (Globalscape Enhanced File Transfer Server - EFT) but rather with the older SSH libraries that the server software happens to be using. (Much the same way that Filezilla relies on Putty for SFTP functionality.)

In any case, I recognize this isn't a Filezilla bug or even a Putty bug, but it would be nice if the Filezilla folks would release a newer version of Filezilla which includes the version of putty with a work around built in. (Perhaps they already have - although judging by the regular complaints we've been getting I'm guessing they haven't)

Baring that we're just in a holding pattern waiting for a new version of Globalscape EFT with updated SSH libraries. Using the workarounds I previously mentioned as a stop gap.

Brad

http://the.earth.li/~sgtatham/putty/0.5 ... ad-openssl

This is what I'm trying now.

I get this error, but only on 3 specific folders. Would there be any other cause for this? i've got a directory of 15 or so folders and an equal number of subfolders per folder, and the one i'm having the issue with is 3 layers down. the other folders are fine.