[IDD #MGQ-321844]: ldm/idd feed down?

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.