Tech Backpack/Troubleshooting

This is a troubleshooting guide for Safety AI field technician.

Cannot connect to Visor on a remote Visbox

You opened a browser, typed in IP address of the Visbox (and 5000 as port for versions earlier than v28) (such as http://10.1.1.10 or http://10.1.1.10:5000) but page does not load.

Check:

1. You have internet access by loading another external page, such as google.com.
2. Make sure you have network connection to the Visbox by pinging its ip address. If you can ping that means (1) Visbox is up and running, (2) you are on the same network.
3. If you can ping, check the response time. A slow connection may prevent Visor from loading.
4. If you cannot ping, check No connection to remote Visbox.
5. This only works for versions earlier than v28: If you can ping but Visor does not load, check VIS Admin at port 10000. If VIS Admin is accessible, restart VIS service. Check Visor again in 10 seconds. In very rare situations service restart may take up to a minute, so if Visor still doesn't load, check again in a minute.
6. If Visor still doesn't load after service restart, ssh to the Visbox, check VIS service status by systemctl status vis. If it is stopped, start; if it is running, restart. Check Visor when the service starts.
7. If it still doesn't load, escalate to Event Gates Service Desk.

No connection to remote Visbox

You cannot ping a remote Visbox. For that you need to make sure you are on the same network and Visbox is up and running.

Check:

1. Assuming you are connecting over ZeroTier VPN, check you are on the respective ZeroTier network with the device you want to connect to.
2. Check ZeroTier web site for the Visbox and make sure it is connected to ZeroTier as well. If it is not check Visbox not seen on ZeroTier network.
3. Sometimes ZeroTier client service may fail. Restart the service.

Visbox not seen on ZeroTier network

You have a Visbox that is included in a ZeroTier network. ZeroTier management web page on zerotier.com shows when it was last online. This value must be close to zero, otherwise it means that this Visbox is not on that ZeroTier network and won't be accessible remotely, as least not for peer devices on the same remote network. There's slight chance that it can be up and running but not connected to ZeroTier for some reason; in that case it can be available to devices on the same local network, including a GSM gateway you can connect. Try check remotely if you do not have immediate physical access to the device.

Check locally

1. The Visbox is up and running.
2. Check it has internet access by visiting an external site via browser or pinging a server on the internet, such as ping 8.8.8.8, public Google DNS server. If the device does not have internet access, fix it. For completing this item you would most probable need local access to the Visbox.
3. If Visbox is online and still not on ZeroTier, make sure ZeroTier service on the Visbox is running by systemctl status zerotier-one. If it is not, start the service by systemctl start zerotier-one, if it is running, restart the service by systemctl restart zerotier-one.
4. If still not visible on ZeroTier network, escalate to Event Gates Service Desk.

Check remotely

1. Assuming you have a GSM gateway on the network that supports SSH connection such as a Teltonika TRB-140 and it is remotely available.
2. SSH to the gateway. Ping Visbox locally.
3. If it responds to ping, try to open an SSH connection to the Visbox using the local address you pinged. This gives us a live SSH connection as well as makes it clear that Visbox is up and running and has access to the network but not to VPN.

If this checks out, one of these options should be true:

• Visbox is not on that ZeroTier network
• Remote IP you have is not correct
• ZeroTier service on Visbox failed
• Visbox has local network but no access to the internet

Error: Remote host identification has changed

SSH or scp command fails with this exception.

Solution

Delete the known_hosts file in .ssh folder.

Run this command on your Linux PC: rm .ssh/known_hosts

or delete the same file on Windows with: del %USERNAME%/.ssh/known_hosts.

This will remove keys of previous connections and reset the known hosts. Only apply this fix in a secured environment where a man in the middle attack is physically not possible.