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.
Greetings, > > Thanks for the quick response and confirmation your side is OK. This > > started Friday, which I did not realize. I'm sure it's something on our > > end. I'll have to check with our networking folks to see if we got > > firewalled on port 388 or something. > > Below are two traceroutes in case it screams something obvious. From those traceroutes it looks like your traffic is making it to at least our IDD cluster, but ldmping isn't. The theories at this point include the port number like you said, or issues with Reverse DNS, or something much more mysterious... > Here is notifyme output. Can you confirm that my requests are for sure not > making it to idd.unidata.ucar.edu? > > $ notifyme -vl- -f NEXRAD3 -h idd.unidata.ucar.edu > <http://idd.unidata.ucar.edu>20231115T183937.986220Z notifyme[54430] > notifyme.c:main:363 NOTE Starting Up: > idd.unidata.ucar.edu <http://idd.unidata.ucar.edu>: 20231115183937.985719 > TS_ENDT {{NEXRAD3, ".*"}}20231115T183937.986369Z notifyme[54430] > ldm5_clnt.c:forn5:460 NOTE LDM-5 desired product-class: > 20231115183937.985719 TS_ENDT {{NEXRAD3, ".*"}}20231115T183937.989491Z > notifyme[54430] error.c:err_log:236 INFO > Resolving idd.unidata.ucar.edu <http://idd.unidata.ucar.edu> to > 128.117.135.3 took 0.002913 seconds20231115T183955.653683Z notifyme[54430] > ldm5_clnt.c:forn_signon:272 ERROR > NOTIFYME(idd.unidata.ucar.edu <http://idd.unidata.ucar.edu>): 7: Access > denied by remote server* "Access denied by remote server" tells me that our LDM made the "choice" to block you, which would mean your machine _was_ able to make its request via port 388. Hmmm... After doing a little digging, we found entries in our logs which are consistent with the above observations: WARN Denying connection from <IP REDACTED> because not allowed WARN Denying connection from <IP REDACTED> because not allowed WARN Denying connection from <IP REDACTED> because not allowed The IP addresses we found were of the same address space as what your traceroutes showed were the exit point of your institution. After checking, we found that Reverse DNS was not working properly for these IPs. The LDM relies on Reverse DNS for its ALLOW functionality. It would appear that something recently changed to where the IP addresses your requests are coming from do not resolve back to your institution's domain. Is this something your IT department could look into? Best, -Mike Ticket Details =================== Ticket ID: MGQ-321844 Department: Support IDD Priority: Normal Status: Open =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.