This is a discussion on Kermit FTP site problems - Protocols ; As many of you have reported, downloads from the Kermit FTP site are hanging and rarely complete successfully. This started happening about 7 Dec 2006 when a new release (or a patch to) Columbia's Cisco Content Switching Modules (CSMs) was ...
As many of you have reported, downloads from the Kermit FTP site are hanging
and rarely complete successfully. This started happening about 7 Dec 2006
when a new release (or a patch to) Columbia's Cisco Content Switching
Modules (CSMs) was installed.
Connections to the FTP server seem normal (except that sometimes you reach
an empty file system, but that's a different problem). But then a GET or an
MGET, in either passive or active mode, generally results in a hung session
after downloading all or most of the file. My theory is that the TCP RST
packet that is sent when the FTP server closes the data connection is not
being forwarded by the CSM because it's a "runt", but who knows. The server
believes the transfer was successful and sends "226 Transfer complete." on
the control connection. So depending on how your FTP client is coded, it
might accept an incomplete file as if it was complete.
Anyway the problem has been reported to Cisco, and our sysadmins (I'm not
one any more) are looking into a workaround. In the meantime, I've enabled
HTTP (Web) access to all the files in the FTP archive:
Any files downloaded with FTP from Columbia since Thursday are likely to
be corrupt, and that includes files in any and all sites that mirror the
Columbia's FTP site.
Watch this space for further news, and/or the Kermit Project home page:
Meanwhile, I took advantage of the situation to add a crude but effective
timeout mechanism to C-Kermit's FTP client:
So far it works only for GET and MGET, not for PUT or MPUT, and not for
operations on the control connection like DIR, but at least now you can
time out of hung GETs:
set ftp timeout 20
The timeout value is in seconds. It applies not to the whole tranfer, but
to each attempt to read from the data connection, kind of like Kermit
protocol per-packet timeouts.
This feature works in consort with SET FTP ERROR-ACTION and SET FILE
INCOMPLETE, so you can decide what should happen if there is a timeout --
keep the incomplete file or delete it; go on to the next one (if MGET'ing)
or stop dead. Remember, you are downloading in binary mode and the file
is incomplete, in most cases (depending on the server) you can REGET it
rather than starting over.