Check a 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, then ask support to deploy a new robot.
You land here at one of two moments. You've just configured a new robot's network and want proof it reaches Kapptivate before you ask for its deployment.
Or a robot in service reads Offline after two physical reboots, with power and cables in order.
Both cases use the same checks, run in a terminal on the robot. They tell you whether the blockage is on the robot or on your network.
An Offline robot you haven't rebooted yet? Start with troubleshooting an Offline robot.
What you need on site
- A screen, a keyboard, a mouse, and a video cable (HDMI or VGA, depending on the robot model), plugged into the back of the robot.
- The robot credentials, which support@kapptivate.com issues if you don't have them.
- On a filtered corporate network, the IP requirements document, which lists the flows the robot needs to work. Ask support@kapptivate.com for it.
- On a filtered network too, 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. An older robot has no desktop: type the commands straight at its console. 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. On a filtered network, 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.
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.1PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 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
rtt min/avg/max/mdev = 1.090/1.135/1.180/0.034 ms
Replies mean the robot sits on its network, so move on to the flows.
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
--- 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.
The IP requirements document lists the flows to open, and the command that tests each one. Run those tests on the robot, not on your computer.
Any line that doesn't answer succeeded! goes on the list for your IT team.
Run the test again by domain name
Next, check 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!
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 in the enter the addresses step of the network configuration.
Check the certificate
One last check: the status code of your Kapptivate platform, at the address you open in your browser.
curl -sS -o /dev/null -w '%{http_code}\n' https://example.kapptivate.comYou get a three-digit code back, 200 or 404 for example:
200
Any code will do. It proves the encrypted connection went through and the certificate checked out.
The command returns a curl: (60) error, then 000.
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
000
A device on your network sits between the robot and Kapptivate and presents its own certificate. Report to your IT team that HTTPS traffic to Kapptivate is being intercepted.
Request the deployment of a new robot
Every check passed on a new robot? All that's left is asking support to deploy it, which puts it to work on Kapptivate. Read the robot's serial number in a terminal:
sudo krobot serialSend the output of that command to support@kapptivate.com, and add the static IP if you set one. Support does the rest. The robot turns Online in your list of robots with nothing more from you, and that is when you rack it.
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 passed and a robot in service is still Offline? 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