Weird ftp problem

[Q4you]

Folks,

I am facing this problem ->

When we invoke a huge ftp file transfer appx 1.7G file from system A (which is a K Class, HPUX 11.0 server) to an IBM Mainframe, the tranmit takes too longs, almost 5 times as much, compared to receive from IBM MainFrame to system A. Tested with both Get/Put in either direction with BIN modes, the problem remains the same.

Observation so far :

- Binary mode or Ascii mode does, same problem
-Lan Interface is set to 100FDX on Sys A and MainFrame
- System A to another system B (Hpux) works great both get/put of the same file
- No disk full conditions on System A or MainFrame
- Latest ftp/ftpd patch PHNE_23949 was already installed

Any clues ?? IBM MainFrame uses EBCDIC ( instead of ASCII) Any pointer to solve this will be greatly appreciated.

TIA

-Q4U

[Stefan Farrelly]

Weve seen this problem before, some sort of timeout ocurring. We found the answer was to leave a ping running the whole time of the ftp and this seemed to keep the ftp transfer 'alive' and it didnt timeout. Try it.

[John Poff]

Hello Q,

We had a similar problem here last year. We have some K-class boxes in remote sites that our IBM mainframe sends large files to daily via ftp. We had a couple of sites that were really slow. We suffered through packet traces and analyzed patches on our end, and our mainframe guys tried a couple of different versions of the TCP/IP stack. Finally, our network guys made a change somewhere and everything was fine after that.

Have you tried doing a packet dump on your K box while you are doing the ftp? It might give you some clue about what is happening. I'd look for the size of the packets and also to see if you are having lots of retransmissions. The ftp program on the mainframe should handle your ASCII to EBCDIC conversions, which is nice. I'd hate to have to be the five billionth person to write one of those translators. :)

JP

[Steven E. Protter]

Might want to check your network switch.

If its produced by Cisco, and set to auto negotiate it can cause this problem.

Are you setting your lan speed settings in /etc/rc.config.d/hpbtlanconf ?

Here are mine.


HP_BTLAN_INTERFACE_NAME[0]=lan0
HP_BTLAN_STATION_ADDRESS[0]=
HP_BTLAN_SPEED[0]=10HD
HP_BTLAN_INTERFACE_NAME[1]=lan1
HP_BTLAN_STATION_ADDRESS[1]=
HP_BTLAN_SPEED[1]=100FD


Have the swith admin chedk the speed of the port you are plugged into. If it differs from your lanadmin -x readings, ask the administrator to hard code the settings and turn off auto negotiate.

reboot server, try it again. It might work bettter this time.

If you need details, post further details/questions.

Hope I helped.

Note: I have had this issue though it was messing with Ignite transfers, it would have made ftp a nightmare had I not resovled it.

SEP

[Q4you]

Thanks Stephan, JP and steve for your response.

Stephan : Is that true ? Can't believe it, will try first thing tomorrow !!!

JP : How do you packet trace on the HPUX ?

Steve : Yes, we have locked our LAN interfaces to 100FDX on lan card as well as on switch.

Some more tests were done..After starting ftp..it ramps up, avgs appx 2mb/sec for sometime and all of a sudden..BOOM..it dies down to 0 B/sec..it stays like that for 2 to 5 minutes and ramps up again...and slows down..we get appx 500KB/sec ( which is very slow compared to other servers which avgs appx 3 to 6 MB/sec) and ultimately the files gets transfered.

To eliminate and disk bottleneck, sending file from host A to "NULL" on the Mainframe. Did not help, though.

[Systeemingenieurs Infoc]

We had exactly the same problem. Our mainframe collegues did 'something' on their box (patch, config ... dunno), but the problem was fixed.

[John Poff]

Hi,

Take a look at the 'nettl' and the 'netfmt' commands. They will do the tracing and reporting for you. Also, you can get some third party products such as Ethereal.

JP

[Q4you]

It may sound illogical, but after, many many test iterations not pointing to any firm conclusion, decided to give a shot by changing the Lan interface card.

And that fixed it !!

Thanks to all.