Using Filezilla under Windows under the same network as our Linux servers is working. Using FTP command-line client under any of our Linux debian servers is not working ! I tried with different FTP servers -> same problem !
All commands are working (login, cd, and so on) but as soon as a copy starts, the file is created on server with 0 size and sometimes some 2'880 bytes are copied but almost all time it's stuck !
And the worst is that it's difficult to give you technical details, I'm just doing
Assuming you don't find a firewall blocking the ftp data channel, it is likely to be a network negotiation issue.
Try setting this parameter as low as 1024 bytes rather than allowing negotiation. If it works, then try increasing the figure in multiples of 1024.
trans_chunk_size
Consider asking your network administrator to check that every network connection involved is not set to auto-negotiate and that all are set to Full Duplex. That includes switches and hubs connecting to each other. Commonly they will drop to Half-Duplex if not set correctly or have been re-patched with the power on.
I have no access to vsftpd.conf it is not managed by us...
And even if I had I couldn't change anything
Denis
---------- Post updated at 09:11 PM ---------- Previous update was at 09:01 PM ----------
Dear methyl,
Thanks a lot for your reply, it looks very interesting...
Where in the ftp command-line client could I change this option ?
Or do you mean change it in the network config ?
Another idea I had was the following :
When connecting with active FTP, some ports are used to send the files to the server...
And ftp was more in the 59000 ports while Filezilla in the 27000, but I don't see why it should be a problem...
---------- Post updated at 09:15 PM ---------- Previous update was at 09:11 PM ----------
Ok now I was able to do some more testing from another linux server to the same servers but from another place and it worked...
Therefore the problem seems either to be :
with ftp on this version of linux ?
Linux 2.6.26-2-amd64 #1 SMP Mon Oct 19 02:34:17 UTC 2009 x86_64 GNU/Linux
with the network (but in this case filezilla wouldn't work ?)
it's a vsftpd option so not relevant unfortunately.
Firewalls might differentiate between port numbers, but that'd usually be incoming ports, not outgoing ones...
Telling me the version of linux doesn't tell me what ftp you're using. Try 'man ftp' and see what version it says it is there.
Try pinging the server with various byte sizes and see if you start losing packets once you go over 1000-1200 bytes a packet. This could be MTU problems, maybe. They can act like that sometimes, things work well until you start transferring bulk data then it freezes and dies.
And now even more strange, I tried to connect with another ftp client and this is what happens :
ncftp> open host -u (user) -p (pass)
Connecting to (ip)...
(vsFTPd 2.0.1)
Logging in...
Login successful.
Logged in to (host).
ncftp / > dir
connect failed: No path to destination host.
Falling back to PORT instead of PASV mode.
drwxr-xr-x 2 3002 3000 4096 déc 7 10:40 tmp
---------- Post updated at 09:33 PM ---------- Previous update was at 09:27 PM ----------
[/COLOR]For the version, man ftp only shows this at the end :
Linux NetKit (0.17)
August 15, 1999
I also found this :
file /usr/bin/netkit-ftp
/usr/bin/netkit-ftp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
---------- Post updated at 09:37 PM ---------- Previous update was at 09:33 PM ----------
I followed your advice about ping and it pings with
ping (host) -s 548 (and less)
But not with -s 549 (or more)
---------- Post updated at 09:45 PM ---------- Previous update was at 09:37 PM ----------
Ok I was able to test with a new command line ftp "lftp" and I was able to launch the copy but it is stuck at 0% like "ftp"... A network problem on this linux host as you suggested seems to be an interesting possibility...
---------- Post updated 23rd Apr 2010 at 01:28 PM ---------- Previous update was 22nd Apr 2010 at 09:45 PM ----------
That is a very odd size for it to quit at and a definite sign of an MTU problem! Most connections will work up to 1400, and some things demand an MTU of at least that.
I've occasionally seen Linux pick up bizarre MTU values along with a DHCP address. Most things seem to ignore MTU settings from DHCP, but linux honors them, even when they're crazy. It's easy to set it saner with
/sbin/ifconfig eth0 mtu 1488
but that's just a temporary fix, it'll get set to something strange again next time DHCP picks up an address. You'll need to configure your DHCP client daemon to force a sane MTU. Assuming, that is, that it's your MTU that's the problem...
Wow, I'm glad that worked -- and surprised, since your MTU of 1500 was fairly sane in the first place. Maybe you can configure your DHCP server to send 1488 instead of 1500.
MTU problems usually don't exist since when things receive too-large packets they can yell at the sender to fragment their packets with ICMP. But some very draconian firewalls go beyond blocking pings to blocking all ICMP and therein break the internet. Wouldn't have occurred to me if I hadn't run into the same thing on some odd high-latency links.
