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.
Carl, I'm afraid that I'm confused about your setup and what is happening. >Date: Thu, 16 Oct 2003 14:46:08 -0500 >From: Carl Sinclair <address@hidden> >Organization: CAPS >To: Steve Emmerson <address@hidden> >Subject: Re: 20031015: LDM 6.0.14 connection to portmap on RedHat 9 The above message contained the following: > Let me try to clarify a few things that we've tested. Tarzan is running > RedHat 7.2 and is working with LDM 6.0.10. I installed 6.0.14 on Tarzan > (without setuid root) and it still worked. By "worked" do you mean that Tarzan's LDM was able to receive data from Branch's LDM? The main LDM program, rpc.ldmd, doesn't need to be set-uid-root in order to receive from an upstream LDM. Other LDM-s might have a problem requesting data from it, however, especially if they are on the other side of a firewall. > I also tried 6.0.10 on Flash > (running RedHat 9) and it produced the same problem = no data. I don't > believe that the higher port or the setuid is the problem. To what host's LDM was Flash's LDM trying to connect? What are the relevant entries in the LDM logfile on Flash? What are the corresponding entries (if any) in the logfile of whatever LDM was upstream of Flash's LDM (Tarzan?)? Forgive me, but there are too many LDM versions and hosts for me to keep straight (e.g., 6.0.10, 6.0.13, 6.0.14, Zeus, Aqua, Branch, Tarzan, Flash). Please, can we concentrate on a single version of the LDM (preferably 6.0.14) and a single pair of hosts that illustrate the problem? Also, as you'll see from my questions below, can we please be extremely precise in our language about who is doing what with whom and when. > Here is what we found when looking at the packet sequence of each > machine side-by-side: Tarzan (working) connects to Portmap via UDP. Do you mean the portmapper on Tarzan? > Flash (not working) connects to Portmap via TCP. Do you mean the portmapper on Tarzan? > While this should not make a difference, the firewall gets tripped up. > We think that a few things are happening here: 1) When connecting to > Portmap via UDP the TCP connection does not close allowing the higher > port connection By "When connecting to Portmap via UDP", do you mean when Tarzan's LDM connects to Tarzan's portmapper using UDP? By "the TCP connection does not close", do you mean the TCP connection from Flash's LDM to Tarzan's portmapper? Do you believe that the UDP connection from Tarzan's LDM to Tarzan's portmapper CAUSES that portmaper to return a high-numbered port to Flash's LDM over that TCP connection? > 2) When connecting to Portmap via TCP, the previous TCP connection > is closed causing a new TCP connection to an unauthorized (by the > firewall) port. By "the previous TCP connection", do you mean a TCP connection to the portmapper or to the LDM? By "new TCP connection to an unauthorized port", do you mean an unauthorized port of the portmapper or of the LDM? 3) It's possible that the firewall (although we're not sure > because all firewalls are different) can read the returning packet (from > portmap) with the high port number and expect a connection to that port > from that IP - and if so works for UDP but not TCP. I'll need answers to the above questions before I can even begin to work on this item. Regards, Steve Emmerson LDM Developer