Hi, I posted this to the cygwin list but I'm thinking this is probably the better place to ask this. Let me preface this by saying that I have done some research and sniffing of this issue from both sides on a few machines (all windows 32 or 64 bit) and have seen the same thing on them all. I have also done a little reading in the RFC's on FTP. I can't find an explanation for this and that is why I'm posting this question.
Synopsis: Active FTP data connections are NOT being sourced from port 20 as stated in the RFC. I saw a post for a fix in 1.5-4 that stated this: * fixed bug in ftpd that prevented large file transfers with recent 1.5.x cygwin kernels. Reported by antony baxter. (worked around by disabling MMAP and limiting buffer sizes to 4k). I don't know if the issue I'm seeing is related and I don't know if 1.6 fixes this issue since cygwin hasn't ported 1.6 yet. Here's what I'm seeing. When I make an active FTP connection to a server running inetutils ftpd (in cygwin) it does the usual port 21 control channel without an issue. This allows small amounts of data across it without the need for a separate data connection. However when I do a large file transfer or a large ls -al command the clients sends the port command and the server opens a data connection back to the client. When I sniff this I can see that the client sends the PORT command to the server and I see the server create the data connection back to the client. This is all normal for an active FTP session. Normally the server opens a connection back to the client at the IP and PORT specified by the PORT command in the data portion of the packet from the client. The connection that the server makes back to the client, according to the RFC, is suppose to be sourced at port 20. However the issue I'm seeing is that the server sources the connection at the next high order port back to the client. Most firewalls seem to allow this however some firewalls/access lists/proxies don't allow this. I can't find any documentation to support an FTP server being able to source the data connection on active FTP at any other port besides 20. This is easy to test. Use an FTP client that can make an active FTP connection. Do a packet capture and watch to see what port the remote side (i.e server) uses when connecting back to you. Keep in mind if you're going through a proxy/firewall it may change the port, especially if you're NAT'ing. It's best to do this test with no firewall in the way. If the source port is not 20 then that is the issue I'm seeing. If it is port 20 then please let me know what version of inetutils and cygwin you are running. This behavior changed between inetutils 1.3-2 and 1.5-4. We've been using 1.3-2 for years which has worked fine and sources the data connection at port 20 like you would expect. The new 1.5-4 causes issues for us and our customers. I'm sorry I haven't tested this with the latest version outside of cygwin (inetutils 1.6). Maybe this is an easy answer however if someone knows for sure I would love to be able to get some feedback on this issue. As a small aside I did an internet search looking to see if I could find other people that have found this issue in other places. We can see that Sonic Firewalls seem to "proxy" FTP connections and have the same result where you see an FTP data connection sourced from a port other than 20. I also found an article written about FTP that was interesting and brought up the topic of coders not using port 20 as the source port because it's a privileged port and it requires root access to open a connection on it. Linky: http://everything2.com/index.pl?node_id=1942928&displaytype=linkview&lastnode_id=1942928 Quote: "Now, this inbound connection should, according to the RFC, come from TCP port 20 - but lazy programmers being what they are, combined with the fact that using a privileged port like that requires root access, means that very few FTP servers actually do that." Now I can't find anywhere in RFC959 for FTP where it says the source port has to be 20 however RFC 1700 states that the ftp-data port is port 20. Can anyone shed some light on this? Are we headed down a path where access-lists will now start blocking ftp data connections because they are being sourced from port 20 like in the past? Has anyone else seen this and considered it an issue? Is this a bug? Is this a new feature with no RFC? Thanks, Curt
