HP-UX 11.23 remsh remsh_af() errors

[William R. Jacqmein]

I have been having a problem with HP-UX 11.23 where any application (SAP in this case) using remsh to access another machine (Windows server running rshd from rshd.sourceforge.net) will fail. The following message is outputed when I run "remsh 192.168.0.1 c:\\windows\\notepad.exe": "rcmd_af: socket: Protocol failure in circuit setup". While the HPUX 11.23 Itanium server has this problem a Linux i386 server, HPUX 10.20 and 11.00 PA-RISC servers can access rshd perfectly. If the rshd service is restarted on windows then the problem is corrected but will comeback in about a weeks time (possibly number of connections?).

Most of the information I have found about rcmd_af() is that it is used for IPv6.

The thought process in my head is that I'm running up against of the security features of 11.23.

Any pointers or thoughts would be most appreciated.

Thanks,

Bill

[Andre Braganca]

No pointers. I'm having a similar problem with HP-UX 11.23 (both machines). A script for shutting down the SAP Application severs when the DB server does an offline backup uses remsh. It stopped working a few days ago. On the source system the script log has "remshd: Host address mismatch". On the destination syslog the message "remshd[]: Host addr ::ffff:120.120.1.5 not listed for host". It works manually (the few times I tried).

The thought: the "::ffff:" makes me think that IPv6 may have something to do with this.

I don't think this will help you a lot but as you have no answers yet ...

Regards,
AndrÃ

[Dave Olker]

Hi William,

I haven't heard of your problem before.

When the problem starts happening, does this 11.23 system have any problems using remsh to systems other than this Windows system or can you successfully remsh to other systems from this 11.23 system?

The error you're seeing is listed in the rcmd(3N) man page:

socket: Protocol failure in circuit setup

Socket connection not established on a reserved port or socket address not of the Internet family type.


The man page indicates this is either a problem involving reserved ports or establishing a non AF_INET socket. The fact that if you stop/restart the rshd service on the Windows box allows the program to work properly for a week leads me to believe that this could be a case where the Windows system is running out of reserved ports, possibly because of the number of simultaneous connections on the Windows system or because of a bug in the rshd daemon on the Windows system not properly returning the reserved ports back to the available pool.

I have a hard time believing that stoping and restarting the rshd daemon will influence the type of protocol family it uses for a connection (i.e. AF_INET). Are there any patches available for the rshd drop at sorceforge?

Regards,

Dave

[William R. Jacqmein]

Andre and Dave,

Thank you both for your replies.

Dave,

The only thing I dont understand is from a linux box, HP-UX 10.20, and HP-UX 11.00, I can open a remsh to the windows box when the 11.23 system is in a failed state. If it was a general, relating to the OS or rshd, I wouldnt think I could access the service at all. When I figure it out I will post a summary. Any thoughts or suggests would be most appreciated.

Thanks,

Bill

[Andre Braganca]

Found a solution for my problem, which really looks like it has nothing to do with yours ! The HP-UXs have 2 NICs with 2 different networks. In the source system each NIC has 2 IPs due to a Cluster configuration. I had to substitute in the script a hostname by an explicit IP.

Good luck,
Andre

[Dave Olker]

Hi Bill,

The fact that the error is complaining about rcmd_af() means this has something to do with IPV6, as you pointed out in your initial post. I don't believe 10.20, 11.0 and most Linux systems support IPV6.

Do you know if any of the systems that work when the 11.23 system fails have IPV6 enabled? Perhaps there is something going on in the setup of the IPV6 portion of the rcmd that is failing where the IPV4 portion is working, which would explain the IPV6-enabled system showing the symptom and the IPV4 systems not showing it.

Are you using IPV6 networking in your environment or would you be fine disabling it on your 11.23 system if there were a way to do this?

Regards,

Dave

[William R. Jacqmein]

Dave,

Much thanks. The local port suggestion sent me down the right path.

It appears as if the rshd starts handing out return ports (rshd debug lists it as Local stderr port: 1023) and when it reaches the end of the privileged port range the error occurs on HP-UX 11.23. On HP-UX 11.00 it just starts using 65535 and works its way back down (still have to tested this but I'm sure it will crash when it cycle back around to 1023). My theory is remsh on 11.23 will not use unprivileged ports as a security measure (Maybe a guardian moderator from HP can confirm?).

Why rshd isnt recovering ports is still a mystery. It leaves them in a TimeWait state on windows for both 11.00 and 11.23. I still feel good about finding out at least what is happening.

Thank you all for your help,

Bill

[William R. Jacqmein]

Another piece of the puzzle.

Some rsh clients open an additional connection for the stderr output. There is a
known problem/feature in Microsoft's implementation of TCP/IP that causes closed
connections to linger on for 2 maximum segment lives (4 minutes). Within the timeout
period, the local port is unusable. For this reason, rshd has a mechanism for port
resolution that tries to assign local ports in a round-robin fashion.
It is not a clean solution, but it works for the time being (there is still a problem
if rshd is restarted, since it begins assigning ports from 1023; if those ports are
taken by TIME_WAIT connections, they'll be unusable).

It doesnt appear to go back and reuse the ports once they are freed.

[Dave Olker]

Hi Bill,

You asked about whether remsh uses priv ports as a security mechanism. The answer is yes. It is obviously not the greatest security mechanism, but the assumption is that only a priv user can request a priv port. This is why the remsh binary is a setuid-root binary:

# ll /usr/bin/remsh
-r-sr-xr-x 1 root bin 96156 Sep 3 2003 /usr/bin/remsh

This is explained in a little more detail in the remshd man page:
_________________________________________

remshd allows two kinds of authentication methods:

1. Authentication based on privileged port numbers where the client's source port must be in the range 512 through 1023. In this case remshd assumes it is operating in normal or non-secure environment.

2. Authentication based on Kerberos V5. In this case remshd assumes that it is operating in a Kerberos V5 Network Authentication, i.e., secure environment.
_________________________________________


The rcmd man page also discusses the reserved port range requirement, and the fact that any command calling rcmd (like remsh) must run as root, as this is required to get a priv port.

Hope this helps. Glad my reserved port hint pointed you in the right direction.

Dave