freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] Re: GE rsh problem


From: Anand Babu
Subject: [Freeipmi-devel] Re: GE rsh problem
Date: Mon, 02 Aug 2004 18:31:46 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

,----[ 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>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]