Whenever I try to upload a file to my FTP (running FileZilla 0.9.14a) it starts uploading at a decent speed but slows down very rapidly, until it's uploading nothing, but maintaining a socket connection, anyway.
So, if I try to replace a 400kb file, I get 16kb of it upload and never upload the rest. Then, the connection times out, and that which was uploaded doesn't get saved.
Any ideas as to what I can do to fix this?
My FTP client is configured to not use PASV mode. When I tried to connect with PASV mode, I couldn't even get a directory listing...
problem with uploads
Moderator: Project members
The problem I'm having and the problem that the original poster in that thread is having seem to me to be quite different. The original poster in that thread actually *is* creating files, it sounds like, while I'm not. The whole file gets uploaded - it just never gets created.
Also, I'm not behind a router. The FTPs static IP address is directly routable to the internet. I am using the Windows Firewall (I'll probably change this at a later date) but TCP traffic on port 21 is allowed.
Also, I'm not behind a router. The FTPs static IP address is directly routable to the internet. I am using the Windows Firewall (I'll probably change this at a later date) but TCP traffic on port 21 is allowed.
The slow down described does happen often with MTU mismatches. The file not getting saved may be the result of not receiving enough/any valid data to save.
You might try to determine your MTU setting and then ping at that same size setting to see if there is any packet loss.
You might try to determine your MTU setting and then ping at that same size setting to see if there is any packet loss.
Microsoft MVP (2004 through 2008)
I decided to look into this some more, today, and...
I started up Wireshark to see what was going on and apparently, after connecting, an FTP Data packet of 1460 bytes is sent and then another one. I then get ICMP packets sent to me, from the FTP, whose description in Wireshark reads "Destination unreachable (Fragmentation needed)". After a few of these, my computer tries to resend it. The Wireshark description now reads "[TCP Retransmission] FTP Data: 1460 bytes".
So basically, it sounds as if all packets, above and beyond the first, are getting dropped, and I have no idea why.
I started up Wireshark to see what was going on and apparently, after connecting, an FTP Data packet of 1460 bytes is sent and then another one. I then get ICMP packets sent to me, from the FTP, whose description in Wireshark reads "Destination unreachable (Fragmentation needed)". After a few of these, my computer tries to resend it. The Wireshark description now reads "[TCP Retransmission] FTP Data: 1460 bytes".
So basically, it sounds as if all packets, above and beyond the first, are getting dropped, and I have no idea why.
How do I do this?You might try to determine your MTU setting and then ping at that same size setting to see if there is any packet loss.
That definitely sounds like an MTU issue.
Does your internet provider supply you with a PPPoE connection for instance? Or do you run any kind of VPN? They eat up a bit of space from the regular 1500 byte ethernet packet.
You can test this by running ping with varying packet sizes from an external machine.
For example: ping -f -l 1500 your.host.here
This would most probably give you the response "Packet needs to be fragmented but DF set." instead of a proper ping response.
The highest possible ping data size would be 1472 in a normal network.
Work on downwards from there until you start seeing responses again.
Read more here: http://www.dslreports.com/faq/695
Once you have figured out the size you can start messing with the windows IP MTU settings in the registry in order to circumvent any possible choke on the way between your server and the clients out there.
An exellent example can be found here: http://support.microsoft.com/default.as ... -us;900926
As usual, typing the wrong stuff into the registry can render your operationg system useless, so be careful. =)
Cheers!
Does your internet provider supply you with a PPPoE connection for instance? Or do you run any kind of VPN? They eat up a bit of space from the regular 1500 byte ethernet packet.
You can test this by running ping with varying packet sizes from an external machine.
For example: ping -f -l 1500 your.host.here
This would most probably give you the response "Packet needs to be fragmented but DF set." instead of a proper ping response.
The highest possible ping data size would be 1472 in a normal network.
Work on downwards from there until you start seeing responses again.
Read more here: http://www.dslreports.com/faq/695
Once you have figured out the size you can start messing with the windows IP MTU settings in the registry in order to circumvent any possible choke on the way between your server and the clients out there.
An exellent example can be found here: http://support.microsoft.com/default.as ... -us;900926
As usual, typing the wrong stuff into the registry can render your operationg system useless, so be careful. =)
Cheers!