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.
Manuel, > I attach the report logged by our Sys Admin. I am afraid I cannot add > anything more to it. > > Cheers, > Manuel > I investigated with Manuel. > > It was not possiuble to ldmping tigge-ldm from tigge-ldm > which implies that the network was not the problem. > > "netstat -an" showed lots of outstanding connections in > a SYN_RECV state from dataportal (NCAR) and tigge-ldm and > tigge-portal. > > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 0.0.0.0:388 0.0.0.0:* LISTEN > tcp 0 0 193.61.196.74:388 128.117.12.2:64900 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64970 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64976 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64908 SYN_RECV > tcp 0 0 193.61.196.74:388 193.61.196.76:55517 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64991 SYN_RECV > tcp 0 0 193.61.196.74:388 193.61.196.76:55531 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64855 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64994 SYN_RECV > tcp 0 0 193.61.196.74:388 193.61.196.76:55520 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64968 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:64955 SYN_RECV > tcp 0 0 193.61.196.74:388 193.61.196.76:55529 SYN_RECV > tcp 0 0 193.61.196.74:388 128.117.12.2:65003 SYN_RECV > tcp 0 0 193.61.196.74:388 193.61.196.76:55537 SYN_RECV The above indicates that the LDM on host tigge-ldm received connection attempts from hosts dataportal.ucar.edu and tigge-portal.ecmwf.int. The connections, apparently, remained in the SYN_RECV state. This is consistent with with the TCP layer on host tigge-ldm never receiving the final ACK from the connecting hosts. Because the TCP layer did receive the initial SYN-s from the connecting hosts, it is likely that something prevented the transmission of the SYN and ACK responses from host tigge-ldm to the connecting hosts. This same barrier might also have prevented the ldmping(1) on host tigge-ldm from connecting to the LDM server on that host. Is it possible that host tigge-ldm was running firewall software and that it was preventing incoming TCP connections? Regards, Steve Emmerson Ticket Details =================== Ticket ID: CUA-629523 Department: Support IDD TIGGE Priority: Normal Status: On Hold