problems with ftp

[Richard Darling]

This morning they were able to ftp the files without a problem from a DOS prompt, which they werent able to do yesterday afternoon. I notice that there are ^M^J at the end of the file name, cvfcusti, in the results (see my first entry on this thread). Could there be extra characters added somehow that are creating a problem, or is this normal?

Sanjay, When the problem occurs they are getting the message that the session was closed by remote host, not the error 451.

Ron, It seems to only be this file and they are sending it from MS boxes so that won;t be using gzip.

Bill,
The files are only 2kb max. There is plenty of space - I setup a separate mount of 100 mb.
They are running the put from a MS box(an NT 4.0 server and an ME PC) using the full path. They are setup as a restricted user so they only put what they see as the root directory. I have a link in their home dir, /incoming, which I use as their target directory. This link is to a separate mount /home/ftpdir.
The command they are running is a simple put. I had set up a local bin dir for them and only put the ls command in there, so that is the only one that they can run.

Vijay,
Based on this data being transferred from a PC or NT boc I don't want to get into any other issues suing rcp. I would rather just use ftp.

Thanks to all... any other ideas?
RD

[Ron Kinner]

Your windows folk can use something like WIN-GZ:

http://download.cnet.com/downloads/0-10097-100-2181397.html

There are several other programs available at www.shareware.com and http://www.winsite.com


^M^J is a carriage return /line feed which the RFC for FTP says has to follow the file name. I'm surprised that your system shows it but I can't say I've ever looked at the ps when doing FTPs.

We had a similar problem with our FTP transfers failing about once a month. The client thought everything was fine but the file was missing the last packet which had the EOF. Turned out to be bad type of NICs. They were sensitive to electromagnetic interference.

landadmin and netstat -s did not show any errors but a long series of pings larger than 1500 bytes would have random failures.

Ron

[Richard Darling]

Hi everyone,
We are still having problems ftp a file from an NT server to our L1000...any other ideas?

I thought I'd bring this back to the top. Thanks.

RD

[Mark Greene_1]

Richard,

are the results the same when you do the ftp from the L server to the NT and get the file? Also, does it change in binary or ascii mode?

Mark

[Richard Darling]

Mark,
They won't let me get the files. I have the same problem with binary or ascii.
RD

[Mark Greene_1]

if they won't let you get, have them ftp to another NT box and look at the files there. If they are having the same issues, it's on their end, not yours (big surprise--NOT, I know).

mark

[Richard Darling]

I'll have them do that. Unfortunately, that doesn't help me get my files.
Thanks.

[Ron Kinner]

Have one of your NT clients run the following ping command:

ping -t -l 5000 a.b.c.d > c:\junk.txt

where a.b.c.d is the address of your server. This ping will continue until they hit ctrl + c. The idea is to look and see if you see any no replies (other than perhaps the first one). Let it run for 5 minutes then ctrl + c it and open junk.txt and search for "request timed out" If you have any then you may have a bad NIC. Run it again with 1400. If no failures at 1400 but failures at 5000 then it's the NIC if you get failures at 1400 too it could be the network.

Ron

[Chris Watson]

Richard,

Did you ever get a solution to this problem, as I am also suffering identical problems.

[Martin Johnson]

Have to checked the file to verify it is not corrupted?

HTH
Marty