[IDD #GQL-934266]: ldm upstream feed

Murray,

> The lines that contain 'idd.unidata.ucar.edu. is willing to be a primary 
> feeder' indicate
> that the REQUEST was received and honored by idd.unidata.ucar.edu.
> 
> The other lines indicate that the connection that is being made is being 
> interrupted
> by something.  I would suggest that these might be a result of the firewall
> on your side interrupting the connection.  It is definitely not something
> on our side.

I agree with Tom. The following log messages from downstream LDM process 7460

> 20180423T171910.686190Z idd.unidata.ucar.edu.[7460] NOTE 
> requester6.c:588:req6_new() LDM-6 desired product-class: 
> 20180423161910.686090 TS_ENDT {{NEXRAD2, "KA.."},{NONE, 
> "SIG=12b7c3d883511dcf117f085ba231ad9b"}}
...
> 20180423T171911.009346Z idd.unidata.ucar.edu.[7460] NOTE 
> requester6.c:311:make_request() Upstream LDM-6 on idd.unidata.ucar.edu. is 
> willing to be a primary feeder
...
> 20180423T171911.225490Z idd.unidata.ucar.edu.[7460] NOTE 
> svc_tcp.c:358:readtcp() EOF on socket 6

show that the downstream LDM process saw its connection to the upstream LDM 
process disconnect after only about 0.2 seconds. Our upstream LDM processes 
don't do that. The cause is likely due to a third party mimicking the upstream 
LDM process and sending a TCP reset (RST) packet to the downstream LDM process. 
We've seen firewalls and intrusion detection/prevention systems do this.

I suggest you give this information to your network administrator.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: GQL-934266
Department: Support IDD
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.