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

Re: Getting LDM on plane to receive via UCAR RAS and PPP



Janet,

>Date: Wed, 29 Jun 2005 09:28:30 -0600
>From: Janet Scannell <address@hidden>
>Organization: UCAR/EOL
>To: Steve Emmerson <address@hidden>
>Subject: Re: Getting LDM on plane to receive via UCAR RAS and PPP

The above message contained the following:

> A few more questions about the firewall problems that I am having on 
> linus. 
> rpcinfo -p linus  shows:
>     300029    6   tcp  46579  ldm
>     300029    5   tcp  46579  ldm

The above means that an LDM server (RPC program 300029) is running on
Linus.  It is listening on port 46579 (not what you want) and
supports versions 5 and 6 of the LDM protocol.

Because the LDM server isn't listening on the well-known LDM port, 388,
other LDM-related programs will have to connect first to the
portmapper daemon on Linus (e.g., bind(1)) in order to discover what
port the LDM server is using.

It is likely that the reason that the LDM server isn't listening on the
well-known LDM port, 388, is because the LDM program, $HOME/bin/rpc.ldmd,
is NOT owned by root and has the setuid bit set, i.e., it is not like
the following:

    $ ls -l /local/ldm/bin/rpc.ldmd
    -rwsr-xr-x   1 root     ustaff    515768 Mar 11 11:11 
/local/ldm/bin/rpc.ldmd

Check your LDM program for ownership and setuid.

> If I try rpcinfo -t linus 300029 6 from linus, I get:
> rpcinfo: RPC: Unable to receive; errno = Connection reset by peer
> program 300029 version 6 is not available

The above could mean that the rpcinfo(1) utility was able to connect
to the LDM server on Linus (after getting the LDM port number from the
portmapper) but was not able to receive a reply to the NULLPROC RPC
message that it sent to the LDM server because the LDM server decided to
close the connection rather than reply.  This is likely due to a missing
ALLOW entry in the LDM configuration-file, etc/ldmd.conf, that enables
the LDM to accept connections from the local system.  For example:

    allow ANY ^(localhost|loopback|127\.0\.0\.1)$

Check the LDM configuration-file on Linus for a similar entry.

Execute the command

    nslookup 127.0.0.1

on Linus to ensure that the loopback hostname is either "localhost" or 
"loopback".

> rcpinfo commands from an outside host to linus just hang or timeout.

This likely due to a firewall blocking access to either the portmapper
or port 46579.  Access to the portmapper is necessary in your case
because the LDM server isn't listening on the well-known LDM port, 388.

Try the command

    rpcinfo -n 46579 -t linus 300029 6

from a host other than Linus.  You might get the same behavior as when
executing the rpcinfo(1) command on Linus.

> I can ldmping from linus to cirque when cirque is connected as 
> ras9.ucar.edu, but I can't ldmping from cirque to linus.

The inability to ldmping(1) Linus from Cirque is consistent with a
firewall blocking access to the portmapper on Linus.

> I can receive data from idd.unidata.ucar.edu on linus. Is
> idd.unidata.ucar.edu outside NCAR's firewall?

Yes.

> So linus works as a downstream ldm, but does not work 
> as an upstream ldm.  Do I have to have port 46579 open on linus?

That would only work one time.  The next time the LDM server on Linus
was executed, it would, undoubtably, get a different port number.

> I'm not sure why this port shows in the rcpinfo instead of port 388.

See above.

> I'm not really sure how the internals of ldm work when trying to get through 
> the firewall.  I've had other people looking at this without much 
> success.  If you have any other info that might help me get this figured 
> out, that would be helpful.

Is there any chance we could logon to Linus and Cirque as the LDM user?
We're responsible, good at our jobs, and this would speed-up things
considerably.

> Thanks,
> Janet

Regards,
Steve Emmerson
LDM Developer


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.