FTP not returning after file transfer has completed

[Tim Havenhand]

I'm trying to FTP some files ranging in size from 800Mb to 4.5Gb from an Itanium rx2800 i2 running TCP/IP V5.7 ECO 2 on VMS 8.4 Update 600 to an Itanium rx2660 running TCP/IP V5.6 ECO2 on VMS 8.3-1H1.

Using either COPY/FTP or the ftp utility, the file transfers after a suitably long period (say 4 hours) and is closed by the destination machine, but the FTP does not then return to a prompt.

There are routers and tunnels and things between the machines.

Has anyone any idea what might be stopping the process asking for more?

[Hoff]

Maybe things are taking a long time because the local networking team has caused you to fear, loathe or avoid them?  (It's more common to work these networking cases directly with the local networking team than with random folks in a forum.  The folks on-site can see and can monitor the network.  We can't.)

Beyond knowing the commands and sequences involved and details of the network, these cases are usually worked at the packet level, looking to see what's going on with the ftp traffic.  Either a trace or maybe a dump.

ftp is older than IP, and its design is largely incompatible with modern network security, so there's a decent bet that the network infrastructure is faulty.  Could be a firewall, could be a NAT device, a connection between VLANs, could be a faulty switch port, could be a misconfigured network or misconfigured NIC.  Could be a bad cable or switchport, too.

Check your FTP logs for clues.

Check your network devices for errors.

Confirm the network path is functional.

Look to switch to sftp, too.  That offers far better compatibility with modern networks, and (unlike ftp) sftp doesn't display the user and password authentication credentials in cleartext to anyone that cares to know them.

[abrsvc]

Since the transfer actually completes, the connection works.  I would attempt to use FTP in the reverse directio to see if that works completely.  You are currently going from an newer version (5.7) to a older one (5.6).  While compatability with older versions is always a goal, sometimes there are problems.  Please try puling from the 5.7 system rather than pushing from it.  Post here the results.

Thanks,

Dan

[Hoff]

Compatibility with older versions is the goal?  

The FTP protocol is older than the Internet Protocol (IP) network.  This is not a new tool.

Unless we're looking at backward compatibility with some package from, say, the 1990s, this FTP stuff works.

If a connection from an FTP client to an FTP server doesn't work (and there's no firewall gateway, NAT, VLAN or network-level hardware or cable or configuration error that's derailing the connection), then there's something seriously wrong with one or both ends of the FTP connection.  With the FTP client, or the FTP server.

Security concerns aside, the VMS-to-VMS FTP connections are among the most commonly used, too.

Definitely check previous discussions around FTP disconnections, as controller settings, matching speed and duplex settings, the switch port configuration and operations, VLANs, cabling, errors, etc.

[John Gillings]

4 hours seems a very long time for that size transfer. I'd be checking for a duplex mismatch somewhere in the network chain. Make sure all ports are set to AUTONEGOTIATE.

In particular make sure you don't have one end of a cable in an AUTO port and the other end set to 100 FDX.

[Rodney Kimber]

We actually experience this problem a lot with one of our customers.  What we get is a COPY/FTP command within a DCL command procedure that stays open indefinitely.    We have never been able to figure out what the cause is, whether it is a local host problem (VMS V8.3 + TCP/IP V5.6  ECO 2), the network or the destination host (which is something that is external with an unknown OS).

As a work-around.  The command procedure now estimates how long the transfer should take based on the file size, it then spawns the transfer and if it isn't complete within the estimated time (plus some leeway) then the process is terminated and the transfer is tried again later.   Eventually it gets through but our files are much smaller than yours.

Regards,

Rodney