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.
Hi Kip- This is Don. > > I thought I read in some documentation or web board that it was random. I > > remember reading that outgoing communication from the client was on port > > 112 and that port was unblocked by the security people. IDV was able get > > real time data for months and then it all stopped right before the end of > > the year on both linux and windows xp computers. Could the return > > communications from the server on port 112 have been stopped by the > > security people or altered in some way that prevented downloading of data? Here's what happens. The IDV opens a connection on a random port on your system and connects to the server's port 112. The server sends back data from port 112. So, your firewall needs to allow outgoing to port 112 and incoming from port 112. This is a well known port. You would also need to do the same for port 8080 for connections to model data on the THREDDS Data Server (TDS). The Unidata approach to setting up IPTABLES firewalls on Linux has a line in /etc/sysconfig/iptables like: -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT This says to allow traffic on a connection that is already established. The ADDE request initiated by the client is just such a connection. Given your earlier messages, it looks like outgoing to port 112 is open, but incoming from port 112 is blocked. Don Murray Ticket Details =================== Ticket ID: GKH-525804 Department: Support IDV Priority: Emergency Status: Closed