[LDM #AVX-447373]: What we're seeing...

Donna & Gerry,

> Steve, we can't seem to get LDM products flowing from us (ldm.tamu.edu) to
> the AT&T Weather Operations department - where they have downloaded
> Unidata's EDEX server software.
> 
> ?Our allow (just like for many other downstream users) is:
> allow ANY-LIGHTNING-PCWS-WSI ^((zlp17983\.vci\.att\.com)|(1
> 35\.40\.68\.210))$ .*
> 
> And, yes, I have restarted LDM on all three of our "cluster nodes". You may
> recall that we have an IP Virtual server for ldm.tamu.edu (and our ldm1,
> ldm2, ldm3 "cluster nodes").
> 
> The ldmd.conf at AT&T Weather operations looks like:
> EXEC    "pqact -e"
> EXEC    "edexBridge -s localhost"
> EXEC    "rtstats -h rtstats.unidata.ucar.edu"
> REQUEST ANY     ".*"    ldm.tamu.edu
...
> ALLOW   ANY-LIGHTNING-PCWS      ^((localhost|loopback)|(127\.0\.0\.1\.?$))
> .*

The "-LIGHTNING-PCWS" isn't necessary (because they not getting those feeds)
but won't hurt.

> Gerry has requested contact with their network/firewall person.

Good idea. Read on.

> We also have questions about their ALLOW statement.? On our EDEX server (
> awips2.tamu.edu), the ldmd.conf provided had these entries:
> 
> ALLOW ANY ^((localhost|loopback)|(127\.0\.0\.1\.?$)) .*
> ALLOW ANY ^[a-z].*\.unidata\.ucar\.edu\.?$ .*
> 
> ?We have changed ours to match our other LDM configs:
> 
> ?allow ANY
> ^((localhost|loopback)|(127\.0\.0\.1\.?$)|([a-z].*\.unidata\
> .ucar\.edu\.?$))
> 
> ?Gerry is questioning the "\.?$" at the end of the ucar entry. I have often
> wondered myself. But saying "include a possible period after "edu" sounds
> like overkill".?

Yeah. That entry was created in the dim early days of the Internet when a
reverse DNS lookup just might return a trailing period. Not a problem now.

> ?Again, any ideas??

The downstream LDM process at AT&T is seeing an ECONNRESET error when it
attempts to connect to TAMU's LDM. This means that 1) TAMU's LDM never sees
the connection attempt; and 2) somebody in the chain from AT&T to TAMU is
responding with a TCP RST (reset) packet, which kills the connection attempt.

Not good and very antisocial.

> I now think this is a hostname/Address problem on their end. Let's see what
> I can get out of their firewall and network folks.

Gerry, I'm afraid I don't see how a hostname/Address problem could lead to
a TCP reset. I can see a firewall rule causing that, however.

Please keep us apprised.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: AVX-447373
Department: Support LDM
Priority: Normal
Status: Closed
===================
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.