20031016: LDM 6.0.14 connection to portmap on RedHat 9

Rita,

>Date: Fri, 17 Oct 2003 14:44:59 -0500
>From: Rita Edwards <address@hidden>
>Organization: NASA/Marshal Space Flight Center
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20031016: LDM 6.0.14 connection to portmap on RedHat 9

The above message contained the following:

> I really don't think this is a setup issue with branch.
> The machine has been an downstream node for three NWS radars,
> and an upstream node for Carl's systems.  The
> current configuration for branch has been in place since
> June 12 of this year.  All of my systems running
> ldm are at version 6.0.13 and run either Red Hat 7.2 or
> Red Hat 8.0.
> 
> Please note that Branch has not changed in 
> configuration.  Carl's machines have, but not 
> branch.  The three systems we are testing with are 
> the following:
> branch        upstream node           Red Hat 8.0     ldm 6.0.13
> tarzan        downstream node         Red Hat 7.2     ldm 6.0.14
> flash         downstream node         Red Hat 9.0     ldm 6.0.14
> 
> Of the three, only branch has remained stable in operating
> system and ldm version.  Are you trying to say that new 
> ldm version is not backward compatible with 6.0.13?

LDM 6.0.14 is completely backward compatible with version 6.0.13.

> Do I need to look at upgrading all my systems ASAP?

Well, version 6.0.14 does have some improvements over 6.0.13.  See
the attached list.

> Branch is not responding to Carl's system, 
> because the system flash does not get through the firewall.  
> Thus, an rpcinfo will not provide any information on
> the connection issues between branch and flash.
> 
> In addition, the new ldm version (6.0.14) on
> tarzan (Carl's system that has not been upgraded
> and is still at Red Hat 7.2) does force a higher level 
> port negotiation with branch.

Tarzan's LDM shouldn't be able to "force a higher level port negotiation
with branch".  See below.

> Thus, the netstat -a
> shows both branch (upstream node) and tarzan
> (downstream node) working from the higher
> level port:
> tcp 0      0 branch.nsstc.nasa:43298 tarzan.caps.ou.edu:3179 ESTABLISHED 
> tcp 0  18668 branch.nsstc.nasa:43298 tarzan.caps.ou.edu:3181 ESTABLISHED 
> tcp 0      0 branch.nsstc.nasa:43298 tarzan.caps.ou.edu:3175 ESTABLISHED

Something's wrong if Branch's port isn't 388.  Branch, as the upstream
LDM with setuid-root privileges, should be listening for connections 
on port 388.  Once a connection is established to a downstream LDM, the
same port 388 should be used by Branch for that connection.

Here's an example:
    Active Internet connections
    Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
    tcp4       0      0  shemp.3652             usgodae3.fnoc.navy.mil.ldm  
ESTABLISHED
    tcp4       0     28  shemp.3385             thelma.ucar.edu.ldm    
ESTABLISHED
    tcp4       0      0  shemp.ldm              emo.1660               
ESTABLISHED

Here, Shemp is receiving data on ports 3652 and 3385 from the upstream
LDM-s on Usgodae3 and Thelma, respectively.  Those LDM-s are using port
388 (i.e., "ldm") for the individual connections at their end.  Shemp is
also sending data to Emo's LDM using Emo's port 1660 -- but note that
Shemp's port for this connection is 388 (ldm).

There's no mechanism in LDM 6.0.14 (or 6.0.13, for that matter) for a
downstream LDM to "force" the use of a high-number port by an upstream
LDM.  The decision on the upstream port number is made by the upstream
LDM in conjuction with its host's operating system.  If the LDM program
is setuid-root, then it will request port 388.

> The rpcinfo should reflect the higher level port
> that tarzan's connection forced on branch (for this
> connection, it is 43298):
> [root@branch /etc]# rpcinfo -p |grep ldm
>     300029    6   tcp  43298  ldmd
>     300029    5   tcp  43298  ldmd

The above shows that Branch's operating system didn't allow Branch's
LDM to use port 388 -- contrary to expected behavior.  If the operating
system would, then I believe your problems would disappear.

Why isn't Branch allowing its LDM to use the LDM's well-known port
number?

> The firewall guys confirmed the high level port
> negotiation.  Tarzan connects to branch through 
> port 388, does an rpc, and then negotiates the high
> level port.  It is tarzan that is dictating
> what port ldmd is working out of.

There's no mechanism for this in the LDM.  Also, how could Tarzan's LDM
connect "to branch through port 388" if the above rpcinfo(1) indicates
that Branch's LDM isn't listening on port 388?

There's something fundamentally wrong with the way Branch is treating
it's LDM.

Regards,
Steve Emmerson
LDM Developer