The Cisco Meraki Scanning API is a powerful resource. For example, when combined with floorplan syncing, the Location API can report client locations as devices traverse a given floorplan. This article covers common issues and troubleshooting steps for the Scanning API.
In this article, “endpoint” will refer to the server receiving the Scanning API POSTs. Depending on configuration, this may include a web engine such as Apache or Nginx in addition to a backend application such as a rails service.
Scanning API Data is not received
Issues with Scanning API data not arriving can be separated into two types. Either the endpoint sees incoming TCP connections from Dashboard, or it does not.
No Connections from Dashboard
In the event that the endpoint sees no communication from Dashboard, the first step is to ensure that there is basic network connectivity between the endpoint and Dashboard. Ensure that there is no filtering occurring by investigating logs from any and all firewalls that exist upstream of the endpoint. If there are no firewalls present, or the firewalls are relatively permissive, you should be able to telnet to the endpoint from an arbitrary external address.
A lack of data can also occur over short periods (15 to 20 minutes) if an endpoint’s responses are slow, as outlined below. If endpoint logs do not indicate long responses, errors, connectivity to the endpoint can be confirmed from other sources, and no traffic filtering is occurring, please contact Cisco Meraki support for further assistance.
Connections from Dashboard
If TCP connections are seen from Dashboard but no Scanning API data is received, consider the following possible causes:
- Considerations with HTTPS When using HTTPS, the endpoint must have a valid certificate signed by a valid public Certificate Authority. If a certificate is not signed by a recognized CA, is expired, revoked or otherwise invalid, a session cannot be established to allow the incoming POST.
In some circumstances, a signed certificate can be valid but still unrecognized if signed by an intermediary CA unknown to Dashboard. For this reason, we recommend including the full CA chain when using HTTPS.
Endpoint is taking too long to respond If an endpoint is taking an exceptionally long time – 500ms or longer – to respond to a POST, that endpoint’s information will be dropped without being sent. It is recommended that applications separate processing of incoming Scanning API data from data routing for this reason.
Endpoint is returning an error Check the application and service logs to ensure that the endpoint application is not reporting errors. Please refer to your endpoint application/service vendor for documentation and troubleshooting assistance.
URL fails to validate During URL validation, the endpoint MUST return a 200 OK response with a body containing only the validator string. If the response is something other than a 200 OK, or the body is not an exact match to the validator string, validation will fail and the endpoint URI cannot be saved as an entry. Accessing the POST URL directly using a browser such as Google Chrome or Firefox, or generating a GET request with curl, are ways to check if the endpoint is responding correctly.
Malformed Data
Certain information is included if and only if a client associates to the network. This includes manufacturer, OS, SSID and IP addressing. Certain information, such as location values or AP tags, are included only if available. Other information should always be included and always have a value. If it does not, please contact Meraki Support.