Re: [Freeipmi-devel] Re: GE rsh problem

[Albert Chu]

> Please run gdb (or at least strace) to figure out
> who (xinetd or in.rshd) opens these new free ports per connection
> and why. Look for open ports both on server and client.

I believe both in.rshd (through rresvport()) and rsh (through rcmd(),
which subsequently calls rresvport()) use sockets with privileged ports.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Monday, August 2, 2004 6:31 pm
Subject: [Freeipmi-devel] Re: GE rsh problem

> ,----[ Ian Zimmerman <address@hidden> ]
> | Hi, I'm trying to understand the problem with rsh and RMCP at GE
> | (Intel Premier issue #258150).
> | 
> | What I still don't understand is how rsh comes to use port 623.  The
> | normal port for rsh is 514 (shell).  There must be a piece of this
> | that I don't know about; like rshd installed in a particular way to
> | listen on a different port, or some kind of NAT or proxy.
> `----
> Ian,
> 
> I don't have sufficient environment to debug right now. By looking at
> the netstat output sent by Pradhap, It appears that upon every rsh
> connection, a free port is opened. And it clearly walks through the
> BMC reserved ports. Please run gdb (or at least strace) to figure out
> who (xinetd or in.rshd) opens these new free ports per connection
> and why. Look for open ports both on server and client.
> 
> --------------------------------------------------------------------
> -
> Another question (not related to IPMI, but RSH behavior) I have is,
> these TCP sessions don't seem to go away even after RSH client is
> done with its job. It stays for about 1 min, which is default
> tcp_fin_timeout value. Does that mean, rsh client is not sending final
> FIN packet? Strange!!  
> 
>  # ipmiserver:/proc/sys/net/ipv4$ cat tcp_fin_timeout
>  60
> --------------------------------------------------------------------
> -
> dpc_proxy problem:
> -----------------
> dpc_proxy is also known to use ports 623 and 664 as its proxy
> ports. This Intel proprietary software is used for proxying BMC UDP
> packets across networks. Typically it is run on the client machine or
> on a router. I guess Anand Manian is running this on the master node,
> while at the same time accessing BMC on the master node. Correct way,
> is to run this proxy outside the cluster and install netfilter rules
> to DNAT into slave nodes. 
> 
> --------------------------------------------------------------------
> -
> THEORY:
> 
> BMC / OS port conflict
> ======================
> aux_bus_shunt 623/tcp Aux Bus Shunt
> aux_bus_shunt 623/udp Aux Bus Shunt
> secure-aux-bus 664/tcp Secure Aux Bus
> secure-aux-bus 664/udp Secure Aux Bus
> 
> BMC uses port 623 and 664, while OS thinks they are free and
> available. When a process attempts to open this 623/664 port, kernel
> lets it freely. This leads to conflict between the BMC and the OS.
> 
> 
> Solution is simple:
> -------------------
> Blocking ports 623 and 664 for kernel/applications use on all nodes
> that has IPMI BMC should solve the problem. There are number of ways
> to do this.  
> 
>  - Write a user space daemon that will simply use these ports and 
> do 
>    nothing.
>  - Give a kernel patch to reserve these ports.
>  - Tuning xinetd configuration ???
> 
> Bala wrote a simple user space daemon to block BMC reserved ports
> usage. He claims that it has solved the problem completely.
> 
> Anand Manian,
> Are you sure you are running this daemon on all of your nodes?. If you
> are running dpc_proxy on any of these nodes (typically master), you
> might still face the problem. Starting port blocker daemon after
> dpc_proxy is of no use. *Do not run dpc_proxy at all* on any of the
> nodes that has IPMI BMC.
> 
> -- 
> Anand Babu
> Free as in Freedom <www.gnu.org>
> 
> 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freeipmi-devel
>