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: McIDAS <address@hidden> >Organization: McIDAS proyect >Keywords: 199908201415.IAA18376 IDD feed requests Karli, Robb Kambic will be responding to this email as well. I just felt that it was prudent to get some more information out to you as soon as possible. >As of last Tuesday we have not been getting any Satellite feeds from any >of our feed servers. I wasn't aware of the problem until yesterday when >I tried connecting to our secondary server, however the ldmd.log file >keeps showing the "Aug 19 05:03:40 3Q:breeze aqua[728]: >FEEDME(aqua.atmos.uah.edu): 7: Access denied by remote server" error >with our old server and "Aug 20 00:00:14 3Q:breeze pluto[3895]: >FEEDME(pluto.met.fsu.edu): 7: Access denied by remote server" from the >backup server you guys recently set up. This sounds like something changed on your end. >To top it all off, today we've >lost out NLDN feeds as well (latest feed dates 99231) and it too is >plagued by the same problem: "Aug 20 00:00:46 3Q:breeze striker[3907]: >FEEDME(striker.atmos.albany.edu): 7: Access denied by remote server" The fact that all of your feed sites have started to refuse connections from you tells me that the problem is almost 100% sure to be on your end. To test this out, I did a forward and reverse name lookup for your ingest machine (breeze.upr.clu.edu): % nslookup breeze.upr.clu.edu Server: laraine.unidata.ucar.edu Address: 128.117.140.62 Name: BREEZE.UPR.CLU.EDU Address: 136.145.165.17 % nslookup 136.145.165.17 Server: laraine.unidata.ucar.edu Address: 128.117.140.62 Name: breeze.uprm.edu Address: 136.145.165.17 You can see from this pair of nlsookups that the machine names on the forward and reverse lookup are different. The LDM does the forward and reverse lookups to verify that a host is valid; its tests will fail given the different names. The question back to you is whether or not you have any control over this situation? >we'd been havign serious connection problems with our T1, which >constantly keeps falling off to the backup gateway. Could this be the cause of the differning names? >I thought that was >the problem originally, but even when the connections are good, we still >don't get anything. All radar images are OK, for the time being. The fact that your radar images are OK is strange IF there has been disconnects and reconnects over the same period of time to the WSI LDM. >Thanks in advance. One of the first things that we need to get you to do is initiate dialogs with your upstream sites when you have problems like this. It is likely that an email by you to the site administrator at the feed sites could resolve your problem a lot quicker than you sending email just to support. Here is the procedure: 1. Find the email addresses of the site administrators at your upstream sites: o start a web browser o go to the Unidata WWW HomePage: http://www.unidata.ucar.edu o go to the Internet Data Delivery (IDD) link: http://www.unidata.ucar.edu/projects/idd/index.html o go to the Current Operational Status link: http://www.unidata.ucar.edu/projects/idd/iddgeneral.html#status o go to the IDD site contact list link: http://www.unidata.ucar.edu/projects/idd/sitelist.html o lookup the email addresses of the site administrators at your upstream feed sites: University of Alabama-Huntsville Scott Podgorny address@hidden 205-922-5819 Florida State University Chris Vandersip (ldm|cvander)@met.fsu.edu 904-644-(1550|2522) State University of New York at Albany (SUNY-Albany) David Knight address@hidden 518-442-4204 2. Send the site administrators your email noting when your service stopped and the errors you are seeing in your LDM log file. 3. Make sure to CC address@hidden. on your message so that we will be aware of your situation. I am sending this email to the contacts at your upstream sites that appear to be refusing your LDM's attempt to connect to try and get you going again. Scott, Chris, and David: The University of Puerto Rico has recurring problems with network connections to their site. It is possible that the name that their name server "assigns" them changes when their networking reverts to their backup gateway causing a mismatch that causes your LDMs to refuse connections. Would it be possible to generalize the ALLOW lines in your ldmd.conf files to allow connections by IP address and by both of the names listed in the nslookup listing below? This would help them out greatly IF it fixes their problem. Thanks in advance, and please keep us informed about what is going on. Tom Yoksas