UCX 4.1 - RCP Problems

[Stanley F Quayle]

> Tell me please, is there a way to use FTP and not hardcode the password?

I've done this before:

- In AUTHORIZE, create a rights identifier (FTP_PASSWORD, for example)
- Grant that rights identifier to the username that will do the FTP
- Put the username and password in a file (FTP_PASSWORD.DAT, for example)
- Establish an ACL so that only processes with the FTP_PASSWORD rights identifier can access the file
- When it's time to transfer a file, open FTP_PASSWORD.DAT and fetch the username and password

Ugly, but effective...

[Willem Grooters]

On FTP preventing a password:
I remember I had a similar problem between two TRU64 machines, but am uncertain how it was solved exactly. Anyway, there involved a hidden file on either side (sender of receiver, that I canot remember) and by that it was possible to start a FTP session without specifying a password.

The fact that your other machiens seem to have no trouble, makes me think of yet another issue: Some VMS machines do have trouble where NICs are set to "auto-negotiate". You'd better avoid that. We did have severe problems using FTP (VERY slow) where TELNET was no trouble at all, and it was solved by explicilty setting NIC and switch-port to 100Mb, secondly try half-duplex. It _may_ work with RPS as well.

[Surya Rao]

Hi all,

Thanks for the replies. Keep 'em coming.

Just to make a slight correction to one of my earlier posts (not the very first post)

QUOTE
Also we have 2 other VMS 7.1 TCPIP 5.0a systems which also have file transfer operations with the same SUN box and they don't have any problems whatsover. These 2 other VMX boxes are located closer to the SUN box and have a bandwidth of 256kbps.
END QUOTE

The correction is that these 2 other boxes are VMS 7.2-1 and TCPIP 5.0a. So the 2 variables between the ones that work and the one that has problems are as follows

1. lower bandwidth
2. physically located much farther than the other 2 VMS boxes (and the SUN box) that don't have a problem
3. earlier versions of vms and ucx on the box that has problems

I have noted the suggestion of setting the NIC to 100M/full and not to use AUTODETECT and will test this out to see if this helps. I am now working on producing a reproducible test case - one that can help us figure out which "variable" actually is the culprit.

planning to upgrade to vms 7.2-1 (from 7.1) and to TCPIP 5.0a (from ucx 4.1 eco-9) and test that first. if it works, we wont touch the bandwidth. if that doesn't work then we will try increasing the bandwidth - but somehow I've got a gut feeling that bandwidth congestion will not cause the type of ERRORS. it may only have an impact on performance.

Does anyone agree with my suggested approach or does the whole exercise of VMS upgrade etc seem a waste of time and are there any other parameter tuning that can be attempted before we embark on the VMS upgrade exercise?

tia

surya
=====

[Wim Van den Wyngaert]

Is there any firewall in place ? Which one (version) ? Some firewalls impersonate one site and add packages that were not sent. I had a firewall that added RST (ask for a reset of the connection). The RST was added because the firewall was convinced that there was a security breach.

The RST can be checked with TCPTRACE.

[Surya Rao]

Hi,

There is no firewall anywhere between these boxes

rgds
surya
=====

[Wim Van den Wyngaert]

Reread the story. The problem only occurs when making the connection ?

On VMS :
$ ucx sho comm
and check if peak column reaches maximum
if number of routes peaks are high (e.g. 100), I could be small buffers that must be increased (I had the problem once).
$ ucx sho servi rsh/fu
and check if limit was reached by peak value.
Are quotas low ? Did the line had to be opened and did it take longer than the connection timeout ?

On the Sun :
$ netstat -a | wc
If high, the limit could be reached (which is at 10.000 connection as far as I know, it could be dangling connections).
Check the same things as on VMS.

Try to capture a tcptrace (tcptrace/fu/prot=tcp/pack=1000000). The reason may be readable.

[Willem Grooters]

1. lower bandwidth
2. physically located much farther than the other 2 VMS boxes (and the SUN box) that don't have a problem

Combined this _could_ lead to time-out problems. Normally, distance should NOT be a problem, nor would low bandswith alone. BOTH may introduce timeouts, causing the connection to be dropped.
Also, line quality is a matter of concern. A 'bad' line requires more retransmission requests - causing more traffic - causing more collisions - causing more delay - causing retransmissions and so on. At a certian point, the connection may be dropped due to "too much errros".
It may be worthwhile to check the counters. Which ones, check http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=276091

[Wim Van den Wyngaert]

Please post a TCPIP trace. This shows if any retransmissions are done.

[Stanley F Quayle]

How about assigning some points to the responses?

Pointer to help on points:
http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Thanks in advance.

[Ian Miller.]

FTSO is now free
http://h71000.www7.hp.com/freeware/freeware70/ftso/http://h71000.www7.hp.com/freeware/freeware70/ftso/