Best Practice - AXON Troubleshooting Guide - Best-Practice-AXON-Troubleshooting-Guide/Best-Practice-AXON-Troubleshooting-Guide

Create a repeatable process to isolate issues and relay issues between Axon installers, end user customer and Cradlepoint Support.

Axon solution for in car video offload.
Cameras connected via WiFi to Cradlepoint.
Tablet/Laptop connected via ethernet.
Wireless AP at agency to provide WiFi as a WAN connection for the Cradlepoint.
LTE public or private connections may be added per agency.

Typical topology example to identify where the issue is.
This flow chart is intended to highlight common issues and solutions.
Use this to identify where to hone in and begin troubleshooting.

Flow chart example of common issues.
From Client, ping router.
- If no response;
  - Verify the device is getting an IP address.
  - Verify Route to router is present in local route table.
  - Verify VPN software (NetMotion) has a route to the router.
  - Test by disabling NetMotion or other VPN software if possible.
- If Yes, Login to local Router UI and test additional layers from a command line on the Cradlepoint.
  - System > System Control > Device Options : Device Console.
From Router, ping Camera 1.
- If no response;
  - Verify in ViewXL that the Camera is connected via bluetooth.
  - Verify the SSID and Passphrase in the Cradlepoint config. (If NCM is in use, verify NCM group vs device level config)
  - Verify the settings in Evidence.com for the SSID and WiFi settings.
  - Confirm the correct camera ID is entered for the vehicle.
  - Set WiFi channel width to 20MHz.
- If a ping is received, move to next step.
From Router, ping Camera 2.
- Repeat all steps for Camera 1.
- Substitute hardware. (If Camera 1 is connected and a second camera will not, it would appear to be isolated to that hardware.)
From Router, ping out to public internet. (If applicable.)
- If no reply;
  - Verify the SIM is activated and connected.
  - Traceroute to internet may help identify a provisioning issue with SIM. (traceroute 8.8.8.8)
    - If the traffic makes a hop or two then times out, that is a great indicator that it is making it to the tower and to the provider.
  - Verify Traffic Steering rules. (Sourcing the traffic from a specific IP can have different results based on the routing rules and policies.)
- If a response is received, Ping a FQDN on the internet. ( A fully qualified Domain Name will use DNS to resolve the IP.)
  - If no reply to FQDN, DNS will need to be resolved at the router. (regardless of the agency needing to route to internal DNS, the Cradlepoint needs to resolve DNS to reach stream.cradlepointecm.com)
  - Resolve DNS accordingly.
From Router, ping the AP (access point). (Some devices have ICMP disabled as a security feature.)
- If no reply, (this may be a security feature and not necessary, but if possible, allow ICMP to verify this hop.)
  - If ping is not allowed or able to verify then continue to the next step.
  - If a response is received, ping the WOS (Wireless offload server).
Ping WOS;
- If no response, the next few steps can validate the connection. (per the topology diagrammed above.
  - Verify Windows Firewall is allowing ICMP traffic to the server.
  - A return route may be needed to be added to the network to return traffic successfully to the Cradlepoint.
  - tcpdump -i any -nv host 10.0.0.101
  - This will show the traffic and that pings are being sent but not received.
- If reply is received but video will not offload;
  - telnet to the WOS on port 8080 and 443.
  - "Telnet evidence.com 443" would indicate that the cradlepoint has a clear path to the offload server over port 443. (in this case, evidence.com)
  - "Telnet evidence.com 8080" in this case could not be reached.
  - This is an indicator that a firewall may be blocking that traffic.

There are many other troubleshooting steps that may need to be engaged.
Traffic steering and other device level configuration items are explained more thoroughly here: Best Practice - Video Offload - Overview