topic Re: ftp between HP-UX and Solaris/Windows stop with one file in Operating System - HP-UX

ftp between HP-UX and Solaris/Windows stop with one file

Raúl Olías Beltrán — Wed, 16 Jun 2004 13:00:19 GMT

I have just one file that causes an error of ftp transfer from Solaris/Windows to HP-UX. Any others files can be transferred without problems, and it does not matter if they have more or less size or same name or any other thing.

The ftp transfer of this file start and depending on the final HP server, it is send more or less bytes, but always the same for the same server and never the transference is finished.

I have tested with HP-UX pepe B.10.20 E 9000/899 and HP-UX juan B.11.00 U 9000/800 with the same behaviour. Between Sun and HP there is a wan network that does not have problems with othes files.

Does someone have any idea?

Thanks, RaÃº

Re: ftp between HP-UX and Solaris/Windows stop with one file

Patrick Wallek — Wed, 16 Jun 2004 13:03:38 GMT

What type of file is it? Can you try compressing it? If you use zip on the windows machine you can download and install unzip for HP-UX or if you use gzip on SUN then you should be able to gunzip on HP.

Re: ftp between HP-UX and Solaris/Windows stop with one file

Bill Hassell — Wed, 16 Jun 2004 13:07:45 GMT

What is the error message from ftp? Does the file even get created on HP-UX (even a zero-length file)? Since it is a specific file, I would first suspect permissions (error message will help) and then transmission mode (ASCII is very special, BINARY should be used unless the file is a simple ASCII file).

Re: ftp between HP-UX and Solaris/Windows stop with one file

Raúl Olías Beltrán — Wed, 16 Jun 2004 13:11:35 GMT

It is a tar file of several other files, and as I have written it is not a size problem.

Re: ftp between HP-UX and Solaris/Windows stop with one file

Raúl Olías Beltrán — Wed, 16 Jun 2004 13:14:48 GMT

The error message from ftp is broken pipe after a timeout expiration. Original size is 6Mb and depending on the HP server final size is 3Mb

Re: ftp between HP-UX and Solaris/Windows stop with one file

Mel Burslan — Wed, 16 Jun 2004 13:23:19 GMT

seeing the non-english characters in your name, I have a feeling that you are using a different character set on your systems or your file name has one or more unrecognizable characters in it including but not limited to whitespace.

try renaming your file at the source to a simple, english word like temporary or something and try again. When you say one file having this problem, this is the only thing that I personally have encountered in a similar situation. Especially windows having the new file names with spaces in the allowed, make my feelings stronger.

Please let us know the result.

HTH

Re: ftp between HP-UX and Solaris/Windows stop with one file

Raúl Olías Beltrán — Wed, 16 Jun 2004 13:30:57 GMT

Thank to everybody but I almost sure that it is a bug.
I have try also renaming the file and it does not mater which name do I use, I always have same result. I have try to send a very similar in size file with the same name without problems, so no name neither size problem.

Re: ftp between HP-UX and Solaris/Windows stop with one file

Abdul Rahiman — Wed, 16 Jun 2004 13:36:20 GMT

Have you encountered any block level corruption on the disk where the file is located ?
Does this problem happen if you recreate the tar ball with a different name ?

regds,
Abdul.

Re: ftp between HP-UX and Solaris/Windows stop with one file

Raúl Olías Beltrán — Thu, 17 Jun 2004 01:29:44 GMT

There is no error on file or at least one of then must be ok (Solaris/Windows). From Solaris you can transfer it to Windows or reverse and not to HP-UX, so it seams that it is not a file problem.
I almost 99% sure that it is a protocol error because in the attached text file you can find several messages repeated from HP to Sun that are not normal.

Re: ftp between HP-UX and Solaris/Windows stop with one file

rick jones — Thu, 17 Jun 2004 12:44:26 GMT

While that packet trace is interesting, it is lacking in some rather interesting/important things - like timstamps on the packets, indication of the validity of the TCP checksum (if the trace is full size segements), the window size... what type and model number of NICs are being used...

All those sorts of things. If you can get a tcpdump trace instead that would probably be much better. An indication of _where_ the trace happened would be good too (assuming I've not simply missed it).

The repeats of ACK 2059883114 could simply be triggered by receipt of other segments. The retransmissions of that sequence number could simply be the one side trying to get the data through.

I would guess that the data pattern in the file is triggering the problem. If that is the case, there should be checksum errors reported in TCP statistics (netstat on UX) That is probably why someone suggested trying to compress the file - not so much to change its size, but to change the data pattern.

It would be good to know some idea of the network topology - that the problem happens when both 10.20 and 11.0 systems are involved may suggest something outside the OS because those two OSes have _completely_ different transport implementations.

For example do the 10.20 and 11.0 systems reach the WAN through the same switch port (not that they are connected to the same switch port, the port where the data then leaves the switch for the WAN) and is that the same as any of the "working" situations?