Need Help: Customize FZ Client to Ignore Fake TCP RST Packet

[tateu]

My FTP client upload and download transfers via FTPES (explicit encrypted FTP) receive a TCP RST (reset) packet "supposedly" from the server after having been connected for exactly 10 minutes. This causes FileZilla client to close and restart the file transfer. For the most part, this is not a big deal, the transfer connection successfully reconnects and resumes the upload/download. However, one of my NAT routers (NetVanta 1224STR) does "something" to block the automatic reconnect...whereas my Sonicwall TZ170 and Netgear routers do not.

The TCP RST packets are received no matter which FTP client I use and no matter which FTP server I connect to. Some clients ignore them and do not reset the transfer. One of the servers I connect to is a co-located server (CentOS 5.0 with vsftpd v2.21) that I manage so I was able to install Wireshark and capture TCP packets. I ran Wireshark on my local Windows XP box and on the remote server and connected via FTPES using FileZilla to download a 1GB file. After 10 minutes, Wireshark running on my local Windows XP box showed that it received a TCP RST packet from the server on port 21. I looked through the packet capture from the server and that RST packet did not exist. My only conclusions are that it is either my routers (it happens on 3 different ones, though) or my ISP (Time Warner Business Cable and Time Warner Home Cable) crafting this fake RST packet. Searching Google, it looks like Time Warner might be running a system called Sandvine which is meant to throttle P2P traffic by sending fake RST packets, but maybe they also use it for other types of data???

I installed wipfw firewall v0.2.8 on my Windows XP box and set it to log and deny TCP packets coming from port 21 containing the RST flag. After 10 minutes of downloading a file via FileZilla, the wipfw log showed that it received and denied a TCP RST packet "supposedly" from the server and, since the packet was denied, FileZilla continued downloading without interruption until the file was complete, 1 hour later. After that first RST packet at the 10 minute mark, I never received another one.

None of my routers have the ability to drop packets based on TCP flags. I could go around and install the wipfw firewall on all of my Windows XP boxes (20 or so) but that seems like too much of a pain and setting the machines to always deny RST packets seems like a bad idea anyway.

What I am hoping (I already run a custom compiled version of FileZilla anyway) is that I can add code to FileZilla so that it ignores the RST packet sent at the 10 minute mark. Is this something that might be possible to do? Does anyone have any suggestions as to where to look in the FileZilla source code? I assume somewhere in the "engine" code but most (if not all) of my custom changes have been cosmetic and I am unsure of how to go about making Filezilla drop a TCP packet.

Thanks,

Josh

Edit 2009-11-05 4:36pm GMT
It only times out when using encrypted connections and it actually is the routers sending the RST packets.

[botg]

Normal programs don't have access to raw sockets. They couldn't ignore RST even if they wanted to, RST is handled by the operating system. Furthermore, ignoring RST is a violation to the TCP standards. I'm most definitely not implementing such violation.

If your router sends RST then it's broken and needs to be replaced.

[tateu]

It's not the router...it's my ISP, Time Warner, probably through Sandvine. At least I am currently about 70% sure of that. It happens identically with all three of my routers: Sonicwall TZ170, NetVanta 1224STR and a Netgear WGT624. Sometime, in the next few days, I plan to bypass the routers and connect directly to my cable modem and see if the problem persists.

I believe WinSCP ignored the RST packet. I wasn't testing for it at the time, so I can't be 100% sure. Perl, via Net::FTP and Net::FTPSSL, definitely ignores the RST packet. I tested it several times. When I have more time, I am also going to try a few other FTP clients.

I certainly don't expect, nor do I want you to add code to FileZilla to handle this. I maintain a custom version of FileZilla, for my use only, and I am just asking for help so that I can modify my custom version.

[botg]

It's not the router...it's my ISP, Time Warner, probably through Sandvine. At least I am currently about 70% sure of that. It happens identically with all three of my routers: Sonicwall TZ170, NetVanta 1224STR and a Netgear WGT624. Sometime, in the next few days, I plan to bypass the routers and connect directly to my cable modem and see if the problem persists.

Sorry, didn't know. In that case, please replace router with ISP in my previous statement.

You should contact the FCC about this. They already ordered Comcast to cease similar disruptive behavior.

Also, consider writing your representative, senator or whatever other politician is responsible for it and tell them how highly you value Network Neutrality, how important it is and how the very lack of it is hurting you.

I believe WinSCP ignored the RST packet. I wasn't testing for it at the time, so I can't be 100% sure. Perl, via Net::FTP and Net::FTPSSL, definitely ignores the RST packet. I tested it several times. When I have more time, I am also going to try a few other FTP clients.

I'm not aware of any method for an unprivileged userspace program to ignore such packets. From what I know it's impossible.

[tateu]

I spent a lot more time looking into this. It actually is the routers sending the RST packets , but...they only send the RST packets when I connect via an encrypted connection. I thought I got a RST packet, once, when connected via plain FTP but that must have been a mistake, on my part.

All three of my routers send a RST packet when a connection sits idle for, what the router thinks is, too long. On the Netgear WGT624, the idle timeout is 10 minutes and there is no option to change it. On the Sonicwall TZ170 and NetVanta 1224STR, the default idle timeout is 10 minutes but I can change it globally or per connection type.

I am connecting in PASV mode and for each FTP connection, there are are actually two connections made to the server, one for the ftp control connection and one for the ftp data connection. What is happening is that on file transfers, the ftp control connection sits idle while the ftp data connection sends/receives file data. With plain FTP, the routers seem to recognize the FTP data connection and associated control connection and do not send a RST packet, even though the control connection is idle for longer than the timeout period.

With an encrypted FTPES connection, the routers do not seem to recognize any of the FTP data and when the control connection is idle for too long, they all send a RST packet. They only send a RST packet to the control connection, not to the data connection. It is this RST packet that causes FileZilla to close the control and data connections and restart the file transfer. I have found some software that does not restart the file transfer when it receives this RST packet and I believe that is because they only close the control connection, not the data connection (which seems like they probably don't adhere to strict protocol compliance, in that case).

And I thought that maybe the FileZilla keep-alive setting could help but it only sends keep-alive commands when the data connection is idle, not when just the control connection is idle.

[botg]

Contact your router manufactures. Tell them their routers are broken. Show them RFC 5382 which clearly mentions this:

If a NAT cannot determine whether the endpoints of a TCP
connection are active, it MAY abandon the session if it has been
idle for some time. In such cases, the value of the "established
connection idle-timeout" MUST NOT be less than 2 hours 4 minutes.
The value of the "transitory connection idle-timeout" MUST NOT be
less than 4 minutes.

Unbelievable what shit the router vendors sell nowadays.