Ping Viewer Connection Issues Across Sub-Nets


Companion: 1.0.0 Beta4
Ardusub: 4.1.0 beta
GQC: 4.1.4

I have been testing the new companion a bit. I have a few questions.

We are using VPN, the ROV subnet is and the headquarter where we control the ROV from is in subnet

Everything is working fine if I control the ROV from subnet. But the problem is when i move over to 172.60.10.xx subnet.

I can see on the Ping 360 that it has something hardcoded that you need to be in same subnet.

We also have problems with camera dropping in and out in QGC when we are in 172.60.10.xx subnet. The ping is 4-10ms with no loss. Perfect camera when we are on the same subnet.

Mby it is something in the companion that are causing these problems? Old companion is working fine over VPN network.


Hi @almathisen,

Network details like this are outside what I’ve worked on, so I’ve brought this up with the software team. Hopefully they can help explain what’s going on, and/or fix any bugs if this isn’t the expected behaviour :slight_smile:


If there is something I can test or check out, let me know and I can do it tomorrow :grinning:

Does it work if you ignore the message and just try to click on the device like normal?

Also, which Ping Viewer version are you on? v2.3.0 had some network-related changes which may help if you’re not already on that. It may also be helpful to try clicking the cog and manually setting an IP address with the same subnet as your control computer :slight_smile:

I spoke with the software team about this, and given it’s working fine when it’s in the same subnet, any issues that arise from changing the network configuration are likely network-based issues, and outside Companion’s control.

Assuming a VPN is set up correctly it should work fine (at least in theory), but it’s not something we’ve tested with extensively, and we can’t provide guarantees about the functionality of external VPN software/routing.

I think i tryed that, but it dont start. I cant confirm that tomorrow.

We are running PingViewer v2.3.0. I have manually set the IP address with port 9092. It dosent come up automatically.

It is strange that everything is working fine on companion 0.0.30, and we have used VPN all summer with no problem. But when we upgraded to companion 1.0.0 beta it dosent work.

After we found out the issue on 1.0.0 I tried the 0.0.30 companion right after with the same VPN setting, and it is working fine.

Im going to test some more tomorrow :smiley:

Today I got the video stream an all that working, don`t know what the cause of the problem.

Connect the ping360 to PingViewer are still a problem.

Is the docker0 interface correct?

pi@companion:~ $ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::42:7dff:fe91:391c  prefixlen 64  scopeid 0x20<link>
        ether 02:42:7d:91:39:1c  txqueuelen 0  (Ethernet)
        RX packets 11  bytes 1708 (1.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 31  bytes 6105 (5.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::d256:b9f7:c587:5600  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:ac:57:18  txqueuelen 1000  (Ethernet)
        RX packets 24081  bytes 2862293 (2.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 860204  bytes 1129849190 (1.0 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

That unknown subnet for me.

Generally, one subnet cannot communicate with another subnet without having a router in between. An unmanaged network switch, for instance, cannot route packets between subnets. Whatever port is established as the uplink controls the subnet for the switch. The router, however, is designed to allow one subnet to communicate with the other through the use of a route. Often, if there is a perimeter router in the picture, then a firewall may also block the traffic, but most firewalls are configured to allow traffic outbound (particularly on port 80/443) so that the connection to the ROV should work, but not the reverse. Note that the connection is bidirectional, but it needs to be started from the “internal” or “protected” side of the firewall.

Your home computer can get to other subnets on the internet because your gateway device has routing capability (and almost certainly uses Network Address Translation (NAT) which is impossible without routing capability).

The VPN shouldn’t really factor in to your issue in my thinking because VPNs are encrypted point to point tunnels where all traffic to the destination network is effectively ignored by any network equipment in between. There is no routing involved with the VPN, though, so different subnets still won’t talk without being routed at one or the other ends.

One thing to note is that you can check for connectivity using ping. If you can’t ping the ROV, then it’s unlikely that you’ll be able to connect to it.

To test the port, you can use a telnet client or ftp. For telnet, you would do this:
If the screen clears and goes black then you have a connection. In fact, iof you know the protocol, you could type in commands.
For instance:
telnet 80
[the screen will turn black]
GET / HTTP/1.1
[hit enter twice]

That’s for HTTP protocol, which is what our ROV uses. The point being that you can check a host using ping and check a service on a port using telnet. If you don’t have a telnet client, you can use an FTP client, but all you’ll be able to establish is a connection. You’d be looking for the message “Connected to”

A network diagram would be helpful

We are using ping daily to check if we have connection. We also uses cisco meraki cloud, so we can check the connectivity and VPN connection

Is it possible to check other ports? ex. 9093 (ping360) port. Useful to know about, thanks.

The VPN connectivity is great, we have been controlled the ROV using 4G and VPN all summer. With no connectivity problem. (Companion 0.0.30-DVL on the ROV) We have a network company for support on this.

We are changing the static IP setting to DHCP client on the ROV, this is the only thing we are changing as network setting.

On friday the camera issue was gone, DVL working fine and I controlled the ROV over 4G VPN connection. We had around 50ms ping. But the PingViewer was not able to connect to the Ping360, I got the error described in the first post. I can try another version of PingViewer.

I can maybe narrow the issue down to PingViewer and not the new companion 1 beta. But I have not been testing the PingViewer when the ROV is running on the latest stable companion.

Yes, you can test any port that way. All TCP applications are just IP Socket apps that do a handshake and then pass data. You may not know the protocol, but if you get a connect, then you know the connectivity works.

UDP is a little different because there is no handshake, but usually UDP apps connect TCP first.


We have installed the Ping360 on our new ROV. We hoped to use in our work, but it seems to be a network problem. First we thought the problem was in the new Companion 1.0.0 BETA but we have install back to the old version with same result. I also tried an earlier version of PingViewer but the same result.

Our setup
PingViewer 2.3.0 (also tested the version before)
Companion 0.0.28-DVL
Ardusub 4.1.0 BETA
QGC 4.1.4

We have change the network setting from “static IP” to “DHCP client” on the ROV.

We control our ROV over an VPN solution (site-to-site vpn). We have been testing this VPN solution all summer over 4G, with no connectivity problems or programs failing.

QGC and PingViewer is on one subnet (Main site)
The ROV, DVL and Ping360 are on another subnet (4G site) (The ROV and Ping360 share the same IP. Connected through USB)

This is the error we get. If I click on it I get in, but it dont start to scan.The ROV and the computer are on different subnet, but they are reachable.

I have a good video stream and a connected to the ROV. DVL is working fine, and the ping 360 is showing in PingViewer with a yellow flag.

I have tested the Sonar on the same subnet, and it working fine that way.

Im a bit lost what to do, any suggestions? It seems like it not accepting that the program and the sonar are on two different subnets.

Hi @almathisen, sorry about the delay getting back to you on this.

Would you be able to provide a GUI Log during which you open Ping Viewer and try to connect to the device? We’re not sure what exactly is going wrong that’s preventing the connection from working, and a log should at least help us find out what Ping Viewer is sending and expecting, and what it’s getting back from the sonar.

By the way, I’ve merged this with your original post since they’re on the same topic. I’ve adjusted the post title and category to better reflect the actual issue :slight_smile:

1 Like

Hi @EliotBR, no problem :slight_smile:

Yes, I found the last one, and the error.

[14:08:48:083] ping.devicemanager[Debug]: Add connection configuration for: "None" "LinkConfiguration{Name: , Sensor: Ping360, LinkType: UDP, Arguments: (}"
[14:08:48:083] ping.devicemanager[Debug]: Stop protocol detector service.
[14:08:48:084] ping.devicemanager[Debug]: Connecting with sensor: "Ping360" "LinkConfiguration{Name: , Sensor: Ping360, LinkType: UDP, Arguments: (}"
[14:08:48:084] ping.mavlinkmanager[Debug]: Connecting to "LinkConfiguration{Name: MAVLinkManager, Sensor: UNKNOWN, LinkType: UDP, Arguments: (}"
[14:08:48:098] ping.protocol.protocoldetector[Debug]: ""
[14:08:48:098] ping.protocol.protocoldetector[Debug]: UDP socket disconnected.
[14:08:48:111] ping.mavlinkmanager[Warning]: "IP is not in a reachable subnet. Configure your computer network settings."

20211112-140811734.txt (276.8 KB)

1 Like

Hi @almathisen,

Can you confirm that this log is correct and is from the problem that you are talking about ?
Looking at it it appears to be working fine and ping-viewer should be displaying data.
Do you see a white bar spinning when you connect to the sensor ?

If you take a look in the log file, you can see that:

  • You are connecting to a ping360 via UDP with the address
  • And you are receiving profile messages from it: Handling Message: DEVICE_DATA [2300]
1 Like

Hi @patrickelectric

Sorry, it was wrong log file. But here is a new one.

  1. I open “PingViewer 2.3.0”
  2. Ping 360 with the yellow circle came up.
  3. I clicked on it, and I saw the scanning circle, but no scan.
  4. Closed “PingViewer”

Her is the log;
20211208-075550521.txt (32.8 KB)

Hi @almathisen,

Can you test with this version of ping-viewer ?
It will provide more debug messages for us to test.

Hi @patrickelectric,

Here is the new log, did the same thing as last time.

20211210-105209242.txt (48.9 KB)

Hi @almathisen,

From the log you can see that no network interface that you have on your machine has a reachable subnet:

[10:52:18:341] ping.networkmanager[Debug]: "Checking host address fe80::9da1:7df7:715f:29cc%ethernet_32769 against"
[10:52:18:341] ping.networkmanager[Debug]: "Checking host address against"
[10:52:18:341] ping.networkmanager[Debug]: "Checking host address ::1 against"
[10:52:18:341] ping.networkmanager[Debug]: "Checking host address against"

Do you have a network interface that provides access to subnet ?

Hi @patrickelectric

The topside machine where we control the ROV is on 172.60.10 subnet. The ROV is on 172.70.1. (Using 4G) But this two subnets are on a site-to-site vpn using cisco meraki. I can see the connection is established in the cisco interface. The only problem we have is ping360 and PingViewer.

But why is the PingViewer checking if the IP is on the same subnet? The connection is established.