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

[Raúl Olías Beltrán]

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ú

[Patrick Wallek]

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.

[Bill Hassell]

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).

[Raúl Olías Beltrán]

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

[Raúl Olías Beltrán]

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

[Mel Burslan]

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

[Raúl Olías Beltrán]

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.

[Abdul Rahiman]

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.

[Raúl Olías Beltrán]

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.

[rick jones · Accepted solution]

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?