ftp to mainframe

[David Bellamy]

hi

my user is ftping to our mainframe thru a firewall and when he ftps large files he never gets his ftp prompt back. has anybody ever
come across such an issue

tnx in advance

[David Pittman]

Sveral things come to mind . . .

1) Check for a timeout on the firewall for sessions.

2) Make sure the script you are using to FTP to the mainframe doesn't have a timeout built into it. Expect scripts have this setting.

3) We have a proprietary FTP server at this location and it has several timeouts built into it. (Not our code.) When a user connects it spawns a child process. If that child process takes too long, then for some reason it drops the control-port. The client then never gets a good send ack back from the server.

Is this only on large files or any file?

[David Bellamy]

only larger files

[James A. Donovan]

I just fixed a similar problem. Turned out there must be a router somewhere between my 11.0 server and the remote FTP server that was dropping packets. I couldn't send anything larger than 1406 bytes.

If you have an 11.x server check the value of the ip_pmtu_strategy setting using the ndd command.

#ndd -get /dev/ip ip_pmtu_strategy

If it's set to 1, try setting the value to either 0 (disabling PMTU) or 2. I fixed my problem by setting it to 2.

You can get more info on this parameter by

#ndd -h ip_pmtu_strategy

[Paula J Frazer-Campbell]

Hi David
Try ftping from the server a large file to the users machine and see what occurs.

Just an idea.

Paula

[David Bellamy]

thx for all ur answers.
i checked that ndd and it is set to 1,
if i change it will it affect anything else?

also, i tried an experiment, i found an hp box
that is near the mainframe and has to go thru the same firewall. when i send the same file from there, it doesnt drop but completes.
must be the mainframe, right?

[James A. Donovan]

I think it's unlikely that you'd notice a performance difference when changing the ip_pmtu_strategy setting. However, if you set it to 0, you open yourself up to a potential DOS attack. HP issued a Security advisory about it.

http://us-support3.external.hp.com/cki/bin/doc.pl/sid=243a2e051820d6cfbd/screen=ckiDisplayDocument?docId=400000000266718