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.
>From: "Anderson, Alan C. " <address@hidden> >Organization: St. Cloud State >Keywords: 200310071420.h97EK2k1007135 LDM IDD Alan, >Thanks; No worries. >I talked with our network control person and he is >checking it out. Good. I talked with Mike Schmidt as soon as I got in to see if there was a good way to ascertain if the problem is on your side or at papagayo. The only good way is to be able to get onto waldo and do things like traceroute, and ldmping to other hosts. >I am puzzled by seeing the lightning data >from striker be able to come in, but not allowing access from >papagayo at unl. Evidently these restrictions can be specific >to a single host. Firewalls are semi-infinitely configurable. With tighter and tighter controls being implemented on campuses, we are seeing more and more problems like the one you are reporting. The typical cause is application of a new firewall rule that does not allow for bidrectional data flow through port 388. Since you are getting data via the LDM from SUNY Albany, St. Cloud does not have this port locked down completely. This does not mean, however, that papagayo is not locked out somehow. Something you can try in the meantime is changing your data requests from papagayo to emo.unidata.ucar.edu. We _know_ that this machine is open and has allows from waldo. >I will also check on why you do not have access via ssh and get >back to you I just tried again, and get nowhere with either ssh or telnet. Tom