Communication issues with PMUs outside of network

GPA Products openPDC
1

Hello,

I am attempting to have multiple (up to 15) PMUs connected to my OpenPDC system. Some of these PMUs will be within the same network as the PDC and some will be external.

I currently have 6 connected (3 internal to the network and 3 external). Now, the 3 external do not fully communicate back. It seems the begin their connection and terminate immediately. This is showcased by going to the Graph Real-Time Measurements and looking at the connection lights. They flash red and green at about once every two to three seconds. My thought is this is 100% networking issues (firewall etc.) but I wanted to see if anyone could confirm? Thanks!

Tyler

2

Hello Tyler,

Networking issues would be a likely explanation. You can look at the error log to get more information about the type of connection failure. If you see an error message that says “the connected party did not properly respond after a period of time,” that typically indicates there is a firewall that is blocking the packets. If you see one that says “the target machine actively refused,” that typically indicates there is a routing issue or an incorrect IP or port.

Thanks,
Stephen

4

Stephen,

Is there any other possible issues that would cause the “the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond”?

Tyler

5

I just answered a question like this on GitHub so I’ll quote what I said there.

This error typically indicates that there is a firewall blocking packets between the openPDC and the device it is connecting to. In other words, as part of the TCP three-way handshake, openPDC sent a SYN packet to the remote host, but the remote host did not respond with an ACK packet for the duration of the timeout period. The timeout is typically something like 15 or 30 seconds, so while it technically can also occur in cases when the SYN or ACK packets were somehow dropped due to an error on the network or when the network has severe performance issues, these cases are much less common.

6

Thank you very much Stephen.

7

Is there any possibility that the duplex settings would impact this?

8

I’m not sure what you mean by duplex settings. Is there a strong reason to believe this isn’t a firewall issue?

9

Duplex settings on the NIC. Half duplex or Full duplex, I believe this refers to whether the NIC will send and receive messages simultaneously (full) or only one at a time (half).

There isn’t really a strong reason, however the IT and Networking guys at my University feel as though it isn’t the firewall. I am trying to do my due diligence in trouble shooting from the application side.

Thanks,
Tyler

10

Some limited reading suggests that changing the duplex setting may cause the link to operate inefficiently, but it doesn’t seem very likely that it would take more than 15-30 seconds to send a single TCP packet and get a response.

Can I assume that the external PMUs are on a network hosted by the university that is separate from the network the openPDC is connected to? Is it possible that the IP address is resolving to a computer that is on the internal network? If so, the computer on the internal network may have a Windows Firewall or something like it that is blocking the packets. That would turn this into a routing issue rather than a firewall issue.

11

So a couple of things on this.

The 3 devices which are operating as desired are 100% within the university’s network. The server which is running OpenPDC is also within this network, and has been set to half duplex since installation. Or rather the port it is on is set to half and the server is on Auto negotiate.

2 of the 3 devices which are not functioning are technically part of the university network…but the setup is slightly different than the 3 functioning devices. These 2 devices are located on satellite campuses, which have network IPs leased within the main network, however for their traffic to come back to the main campus they must go over the open internet. Therefor I personally consider them to be external devices.

Further support of those two devices being “external” is the following. The final non-functioning device is 100% external to the university’s network (installed at a third party location with an entirely different network.) This final device exhibits exactly the same behavior as the two previously discussed.

My opinion is that a firewall (or perhaps some other in-line security device) is causing this issue based on the following summarized reasons:

  1. I have 3 identical PMUs working properly with my server on the university’s main network (i.e. the duplex setting of the server is not having an impact there.)
  2. The 2 devices which are on my university’s network (kind of) were working properly in my lab for 2+ weeks, and only began not working when moved to the new location.
  3. These 2 devices act exactly the same as the final non-functioning device, which is 100% external.

I really just want to do as much investigation as I can from the application side of things (OpenPDC). It seems as though you have the same view point as I do, that the duplex setting is incredibly unlikely (but not impossible) to impact my setup?

Thanks,
Tyler

12

Yes, I think that’s a good assessment. I agree with the assertion about the duplex setting.

13

I really appreciate your time, Stephen.

Tyler