Client not listening on port in active mode

[crizo]

I believe my case is simple. Filezilla sends my server a PORT command, which tells my server what port to connect back to(on the client). After the PORT command, I do not see a process listening on the port specified. For example, if the PORT command specifies port 12345, I would think that I could do a "netstat -an | grep 12345" (using cygwin) and see a process listening for port 12345. Am I correct in this assumption? The result is that any following LIST or STOR command fails because the server cannot connect back on port 12345.

I'm testing this on windows 7. I have disabled any firewall to ensure that it is not blocking the opening of port "12345".

Thanks for any help.

[botg]

The port is only left open as long as needed. If the transfer has completed, either successfully or in error, the port is closed again. Are you sure you do netstat in that brief period of time the port is open?

[crizo]

I'm running netstat between when the PORT command and STOR commands are sent. The port should be open in this window, correct? Either way, when my server tries to connect back on port 12345, the connection fails. I'm running the Filezilla client and FTP server (homegrown) locally.

If I try to send the same file using either the Windows build-in ftp or a standard unix ftp client, the PORT command is sent, which opens a port, followed by the STOR command. My FTP server can connect back to either of these clients. I can also see the process listening in netstat after the PORT command is sent.

[botg]

Seems weird. Can you please post a log from FileZilla?

[crizo]

Sorry for the late reply. Here is my log. Filezilla sends a USR, PASS, PORT, LIST (in that order). When the PORT command is sent, my server tries to connect to it, but as I said above, the port is not open, as confirmed by netstat

2012-04-13 14:41:35 3760 3 Status: Connecting to 10.6.33.103:2121...
2012-04-13 14:41:35 3760 3 Status: Connection established, waiting for welcome message...
2012-04-13 14:41:35 3760 3 Response: 220 TransCore FTP server v1.0
2012-04-13 14:41:35 3760 3 Command: USER netuser1
2012-04-13 14:41:35 3760 3 Response: 331 Password required for netuser1.
2012-04-13 14:41:35 3760 3 Command: PASS ********
2012-04-13 14:41:35 3760 3 Response: 230 User logged in.
2012-04-13 14:41:35 3760 3 Status: Connected
2012-04-13 14:41:35 3760 3 Status: Retrieving directory listing...
2012-04-13 14:41:35 3760 3 Command: PWD
2012-04-13 14:41:38 3760 3 Response: 257 "/" is current directory.
2012-04-13 14:41:38 3760 3 Command: TYPE I
2012-04-13 14:41:38 3760 3 Response: 200 Type set to I.
2012-04-13 14:41:38 3760 3 Command: PORT 10,6,33,103,202,246
2012-04-13 14:41:38 3760 3 Response: 331
2012-04-13 14:41:38 3760 3 Command: LIST
2012-04-13 14:41:38 3760 3 Response: 200 PORT command successful.
2012-04-13 14:41:38 3760 3 Error: Failed to retrieve directory listing
2012-04-13 14:41:38 3760 3 Response: 150 Opening ASCII mode data connection.
2012-04-13 14:41:38 3760 3 Response: 226 Transfer complete.

[crizo]

It looks like Filezillia sends multiple PORT commands, but doesn't really intend to listen on them. For example, during login, I'm seeing Filezilla send the USR/PASS, followed by a PORT and a LIST. Filezilla isn't listening on the port specified in PORT, so the LIST fails. When I try a transfer file, I see the same PORT/LIST behavior. Towards the end of the activity, the PORT/STOR finally succeeds as Filezilla is actually listening on the port. Ultimately, file transfer is working. I was just concerned about all the failed connections.

[botg]

2012-04-13 14:41:38 3760 3 Command: PORT 10,6,33,103,202,246
2012-04-13 14:41:38 3760 3 Response: 331
2012-04-13 14:41:38 3760 3 Command: LIST
2012-04-13 14:41:38 3760 3 Response: 200 PORT command successful.

Either a horribly broken server or some firewall and/or NAT router is injecting additional replies into the connection.