Opened 20 years ago
Last modified 9 years ago
#416 closed Bug report
Filezilla Server Active Mode is not RFC compliant
|Reported by:||anonymous||Owned by:|
|Keywords:||Cc:||yurivkhan, Tim Kosse|
|Component version:||Operating system type:|
|Operating system version:|
A customer called me because he had problems using
active FTP through his firewall.
I checked a bit and I remarked that many other FTP
servers were doing well with active FTP through his
firewall (checkpoint). The difference is that the server
that are working ok are RFC 959 compliant. It looks like
Filezilla server is not compliant (because of time, I could
only make very few testings) because when the FTP-
DATA connexion is set up from the server to the client,
the source port should be 20 (actually "listening port -
1", according to the RFC). It looks like filezilla sets the a
random source port > 1023. Stateful firewalls (at least
checkpoint) doesnt take in consideration this connexion
as a part of an existing one and the drops the data
Extract of the RFC :
The user-DTP must "listen" on the specified data port;
this may be the default user port (U) or a port specified
in the PORT command. The server shall initiate the data
connection from his own default data port (L-1) using
the specified user data port.
Change History (3)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
This bug report has been closed due to inactivity and has possibly
already been solved.
You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).
comment:3 by , 18 years ago
Oh no you don’t. The problem is still there.
- Start up the server, in normal configuration (listen on
port 21, allow anonymous ftp).
- Connect a client.
- Connect another client.
- Initiate transfers of big enough files in both clients, in
active FTP mode.
- On clients and the server, execute 'netstat -an'.
- On each client: There is one outgoing connection from
client:random_port to server:21, and one incoming connection
from server:20 to client:random_port.
- On server: There is one incoming connection per client,
from client:random_port to server:21; and one outgoing
connection per transfer, from server:20 to client:random_port.
- At least one client will report that its incoming data
connection is from server:port_other_than_20.
- Server will report that at least one of its outgoing data
connections is from server:port_other_than_20.
A quick-and-dirty patch is quoted below. However, I’m not at
all confident this is the proper place to set the
SO_REUSEADDR option. A better design decision would be to
separate socket creation (socket()) and bind()ing, allowing
client code to call SetSockOpt in between them.
--- AsyncSocketEx.cpp.bak Sat Dec 04 05:06:26 2004
+++ AsyncSocketEx.cpp Fri Jan 28 02:33:51 2005
@@ -700,6 +700,12 @@
+ if (0 != nSocketPort && 0 != (FD_CONNECT & lEvent))
+ BOOL value = TRUE;
+ SetSockOpt(SO_REUSEADDR, reinterpret_cast<const