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.
Wesley, Yes, send the password to 720-579-6286. I'll take a look at your LDM configuration-file. The one from 2004 should be OK, however, providing the ALLOW entries are still applicable (i.e., the host/domain names haven't changed). > Hi Steve, > > Our network folks think there is a problem with our ldmd.conf allow file. > This was the original ldmd.conf from 2004. Since we upgraded LDM, do we need > to change to a different version or maybe we have it in the wrong path or > name? > I can give you the password again to our machine if you have time to log in > and check it...or I can send it to you. I appreciate your help. Wes > > > Here is the e-mail from our network folks: > > > From what I can tell from capturing packets, it looks like multiple servers > from outside the TTU campus are able to reach wnnh002 on port 388 and begin a > conversation. Here's a sample of what I'm seeing repeatedly. Sorry for the > repetitive nature of the description. > > > > 1. An external server connects to wnnh002 on wnnh002's 388 TCP port. > > 2. Once the TCP conversation has been set up, the external server > issues something called a "ChannelData TURN Message" which wnnh002 proceeds > to acknowledge. > > 3. Then, wnnh002 does a successful reverse lookup on the same external > server it is already formed this conversation with (the correct IP is given > to wnnh002 from the DNS server). I find this behavior a little unusual. > > 4. After the successful DNS request by wnnh002, wnnh002 sends a > "ChannelData TURN Message" back to the External server. > > 5. Immediately after sending that ChannelData TURN Message, wnnh002 > sends the external server a "RST, ACK" message. In packet capture parlance, > this is essentially wnnh002 saying it no longer wants to speak to the > external server. I see this mostly when a server (in this case wnnh002) is > denying a connection from a server not in its access list. > > I'm wondering if something could be broken with the LDM access list? I've > attached a capture of some sample traffic from wnnh002 in case you might want > to send it to the vendor. Regards, Steve Emmerson Ticket Details =================== Ticket ID: EGH-413691 Department: Support LDM Priority: Normal Status: Closed