Custom Query (7948 matches)

Needed an FTP server, which support ftps, was in a hurry and tried FZ. Got 0.9.15 and it seemed to do fine except with the only client that really mathered - Thumbleweed's SecureTransport (widely used in big companies, banks, etc.)

So tonight I saw that there's 0.9.16 out there and decided to give it a try. Well, now all the clients (FZ, SmartFTP, SecureTransport, FTPVoyager) don't work at all.

There's the log from FZ client: Status: Connecting to localhost ... Trace: FtpControlSocket.cpp(5083): m_pSslLayer changed state from 0 to 1 caller=0x003aa7bc Trace: FtpControlSocket.cpp(5083): m_pSslLayer changed state from 1 to 2 caller=0x003aa7bc Trace: FtpControlSocket.cpp(5083): m_pSslLayer changed state from 2 to 4 caller=0x003aa7bc Trace: FtpControlSocket.cpp(938): OnConnect(0) OpMode=1 OpState=-8 caller=0x003aa7bc Status: Connected with localhost, negotiating SSL connection... Trace: FtpControlSocket.cpp(761): OnReceive(0) OpMode=1 OpState=-8 caller=0x003aa7bc Response: 220-FileZilla Server version 0.9.16 beta Response: 220-written by Tim Kosse (Tim.Kosse@…) Response: 220 Please visit ​http://sourceforge.net/projects/filezilla/ Command: AUTH SSL Trace: FtpControlSocket.cpp(761): OnReceive(0) OpMode=1 OpState=-9 caller=0x003aa7bc Response: 2 Response: 3 Response: 4 Response: Response: U Response: s Response: i Response: n Response: g Response: Response: a Response: u Response: t Response: h Response: e Response: n Response: t Error: Timeout detected!

I've seen similar bugs opened and closed in this bug tracking system, usually blaming the router, but I think that this is still a problem in the latest version of Filezilla Server 0.9.22. Here's what I did to demonstrate this.

Inside a router firewall, I set up two servers, one WinXP with Filezilla 0.9.22. The other was a CentOS server running vsftpd. The router was set up to pass ports 20,21 as well as ports 1024-1033, with the two FTP servers configured accordingly.

Outside the firewall, I had two Unix servers, one running CentOS, and the other running FreeBSD.

The FTP client on the CentOS system speaks PASV mode only. When the router was set to point to the CentOS system behind my firewall, then things worked -- the 227 response provided my public IP (of the router), and two port numbers, which when multiplied together, provided something in the specified range of 1024-1033. However, when the router was redirected with the same rules to point to the Filezilla server (differen LAN IP only), then I could log in, but I could not execute an 'ls'. Looking at the Filezilla server log, a correct 227 response to the PASV mode command was entered, but apparently never properly received by the CentOS FTP client. So it hung until the connection timed out.

On the other hand, the FTP client of the FreeBSD server outside the firewall speaks EPSV, which seems to work fine with both the CentOS and Filezilla servers behind my firewalls. With EPSV, the port number to use is transmitted premultiplied together.

If the router were to blame, it would not have handled the CentOS system behind the firewall properly either, would it?

A log file of the CentOS client trying to connect to the two server is attached.

I noticed the changelog:

FileZilla Server 0.9.35 released
New features:
   * Administration interface is now Unicode enabled.

After I updated from 0.9.34 to 0.9.35 and 0.9.36, 0.9.35+ cannot show Chinese characters in upper log window of Admin Interface, but correctly in lower connect-threads window, log files and client. And everything works but log window of Admin Interface.

FileZilla Server 0.9.35 & 0.9.36 Windows XP Professional SP3 AMD Athlon 64 X2 4200+ (2.2G)

Here are some screenshots: