remsh hang after first run

[jerry1]

We are still looking at the problem but
everyone responding to this forum question
is not ready it correctly.

It works the first time you issue remsh
from Sun to HP. It does not work on the
second try of the same command and will
not work until the connection is torn
down.

We are not going from host 1 to host 2 to
host 3 from a single host. Just the same
host to the same host. Always from Sun to
HP.

We are suspecting the WAS we have on both
ends of the WAN, but will have to
corrdiante a turnoff to verify if that is
causing the problem.

It does matter. I can issue the same
commands from Sun to Sun and it works
everytime. Just not from Sun to HP
everytime.


Just saying use -n as a fix all is not an
option for us. The code is FAA controlled
and it is a long drawn out process to get
changes done.

Would still would like to find out what is
causing the problem by just moving it from
LAN to WAN. We think there is a latence
causing a problem with the teardown of the
initial connection. Perhaps due to the WAS.

[OldSchool]

Jerry1 said:

"remsh host1 -l user1

or

rsh host1 -l user1


They all hang after the first successful
remsh or rsh."

I take it this was from the command line (Since you didn't say so).
If that is correct, then what happens when the "-n" switch is used?

====================================================================================

"Just saying use -n as a fix all is not an
option for us. The code is FAA controlled
and it is a long drawn out process to get
changes done."


That may be, but doesn't mean anything as far as identifying and resolving the problem.

You seem to be able to reproduce the problem at will (see the first quote). If so, it can be readily tested as well...

the "-n" switch *may* be your only option. discarding without testing is, well,......

[jerry1]

Of course it does not solve the problem.
Come on.

We are looking at the wireshark output
and the connection is trying to use the
same port again and it is busy until it
times out.

[Dennis Handly]

>We are looking at the wireshark output and the connection is trying to use the same port again and it is busy until it times out.

If you think there is something wrong with networking, you should be talking to the Response Center.

[Peter Nikitka]

Hi jerry1,

one last try:

- do you execute the rsh commands as commands at a shell prompt?
- which shell?
- what is the time difference between the execution of the two commands?
- does the hang show for different from-hosts or the same to-host or vice versa?
- what, if you use a HP as the from-host as well?
- what is the difference in the wireshark output when you supply '-n'?

mfG Peter

[jerry1]

- do you execute the rsh commands as commands at a shell prompt?
- which shell?
- what is the time difference between the execution of the two commands?
- does the hang show for different from-hosts or the same to-host or vice versa?
- what, if you use a HP as the from-host as well?
- what is the difference in the wireshark output when you supply '-n'?

1. The commands are executed from command
line and from within a binary program.
Both fail the same way.
2. Fails in any shell.
3. 1 sec via shell script or program.
1-5 sec manually.
4. Sun to Sun okay over wan.
HP to Sun okay over wan.
Sun to HP not okay over wan.

HP10.20 to HP11i from remote wan not okay.
HP11i to HP10.20 on remote wan okay. ???

Any system is okay on the LAN.


I also get this in syslog:

Apr 28 16:00:22 dbsvr1 remshd[10055]: connect second port: Connection timed out

And this in netstat on a good connection:

tcp 0 1 dbsvr1.1020 ictp4.1022 SYN_SENT
tcp 5 0 dbsvr1.shell ictp4.1023 ESTABLISHED
tcp 0 0 dbsvr1.1020 ictp4.1022 TIME_WAIT
tcp 0 0 dbsvr1.shell ictp4.1023 TIME_WAIT
tcp 0 0 dbsvr1.1020 ictp4.1022 TIME_WAIT
tcp 0 0 dbsvr1.shell ictp4.1023 TIME_WAIT


I get this on a hung session:

cp 0 0 dbsvr1.shell ictp4.1023 ESTABLISHED
tcp 0 1 dbsvr1.1020 ictp4.1022 SYN_SENT
tcp 0 0 dbsvr1.shell ictp4.1023 ESTABLISHED
tcp 0 1 dbsvr1.1020 ictp4.1022 SYN_SENT
tcp 0 0 dbsvr1.shell ictp4.1023 ESTABLISHED
tcp 0 1 dbsvr1.1020 ictp4.1022 SYN_SENT
tcp 0 0 dbsvr1.shell ictp4.1023 ESTABLISHED
tcp 0 1 dbsvr1.1020 ictp4.1022 SYN_SENT
tcp 0 0 dbsvr1.shell ictp4.1023 ESTABLISHED
tcp 0 1 dbsvr1.1020 ictp4.1022 SYN_SENT
tcp 0 0 dbsvr1.shell ictp4.1023 ESTABLISHED




Have not really done a wireshark on both
ends yet. Did one here. Each host is waiting
for a response from the other.
Which is why there is a SYN_SENT repeating
for about a minute.

[jerry1]

See docid NR0503KBRC00012549 that describes
this problem.

[jerry1]

From all the testing I have done. It
is narrowed down to a problem with
the HP-UX 11.x TCP stack I believe.
I tried three other servers running 11.0
and 11i. HP 10.20 to HP 10.20 with remsh
works fine over the WAN without the -n
option.

For now, so production can do work, The
program jumps over to a linux box with
remsh and executes the command which runs
an sql script there that connects to remote
oracle server(HP-UX11i)to get the data.

Corp has decided to go with Sun as their
global platform. They are not going to
recompile their code to fix HP's bug.
And getting HP to fix or even look at this
problem would be impossible. Wish the
developers had not used remsh when they
developed this custom program.
Wish I could find the diffs between hp10.20
and hp11i that is broke.

[Dennis Handly]

>See docid NR0503KBRC00012549 that describes this problem.

This mentions the -m option of remshd. Did this help you? If not, it may not be related.

[OldSchool]

"Wish the developers had not used remsh when they developed this custom program."

especially if you're subject to IT audits. Auditor usually usually remote services to be disabled. in your case, sounds like that would also break the app.