Check the robot's network connection
From a terminal on the robot, check its local IP address, its gateway, and the flows your IT team has to open.
A robot that reads Offline after two physical reboots, with power and cables in order, most likely has a network problem. These checks run in a terminal on the robot. They tell you whether the blockage is on the robot or on your network.
Haven't rebooted the robot yet? Start with troubleshooting an Offline robot.
What you need on site
- A screen, a keyboard, a mouse, and a video cable, plugged into the robot as in check power and cables.
- The robot credentials, which support@kapptivate.com issues if you don't have them.
- The IP requirements document, which lists the flows the robot needs to work. Ask support@kapptivate.com for it.
- The local IP address, on your LAN, that those flows were opened for. Your IT team holds it.
Check the robot's local IP address
Log in with the robot credentials, then open a terminal from the Linux desktop. One command gives both the robot's local address and its gateway.
ip route get 1.1.1.11.1.1.1 via 192.168.10.1 dev eno1 src 192.168.10.42 uid 1000
cache
Two values matter on that line. src is the robot's own address, 192.168.10.42 above. via is the gateway it goes through to leave the network, 192.168.10.1. The src value has to match the address your IT team wrote into the firewall rules. When the two differ, reconfigure the robot's static IP so it matches what your network expects.
The other possible answer is shorter, and it ends the question here.
RTNETLINK answers: Network is unreachable
No route means no link at all. Check the RJ45 cable and the switch port.
Ping that gateway next. Use the address printed after via.
ping -c 4 192.168.10.164 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=1.12 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=1.18 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=1.09 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=1.15 ms
--- 192.168.10.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
Replies mean the robot sits on its network, so move on to the flows. The other outcome looks like this.
--- 192.168.10.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3007ms
Check the RJ45 cable, which can be faulty or in the wrong socket. Then have your IT team confirm it lands on a live switch port.
Check the flows
Does your robot go straight out to the internet? Then there is nothing to open, and the page ends for you at the gateway. What follows is for a filtered corporate network.
Check that every flow in the IP requirements document is open. The document lists the flows to open, and how to check that each one is. Run those commands on the robot itself. If you don't have the document, ask support@kapptivate.com for it.
Any line that doesn't answer succeeded! goes on the list for your IT team.
Run the test again by domain name
Then take the flows in the document that have a domain name, and run them again with the name in place of the IP address.
nc -zv -w 5 robots.example.com 443The name resolves and the flow goes through:
Connection to robots.example.com (203.0.113.10) 443 port [tcp/https] succeeded!
The other answer is this one:
nc: getaddrinfo for host "robots.example.com" port 443: Name or service not known
The IP address passes but its name fails. The robot most likely has no DNS server configured, which leaves it unable to resolve the domain name. Report it to your IT team. You can set one or more DNS servers on the robot by following configure the robot network.
Check the certificate
One last check. Take the HTTPS destinations of the document, the ones on port 443, and ask for the status code.
curl -sS -o /dev/null -w '%{http_code}\n' https://robots.example.comYou should get 200:
200
Any other answer, and this one in particular, means a device on your network is stepping in and presenting its own certificate.
curl: (60) SSL certificate problem: unable to get local issuer certificate
Report to your IT team that HTTPS traffic to the destinations in the document is being intercepted.
Who to contact
One of the checks in this procedure failed, so the blockage sits on your own network. Send your IT team the full output of every command that failed, the robot's local IP address, and the time you ran them.
Every check in this procedure passed and the robot is still Offline? That one is ours. Write to support@kapptivate.com with the robot's name as the platform shows it, and its local IP address if you noted it: both speed up the investigation.
What's next?
Last updated on