This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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