Home > Wireless LAN > Monitoring and Reporting > 位置分析

位置分析

To view this article in English, click here.

简介

现在,随着企业级 WiFi 联网设备中可用提供的智能分析功能与日俱增,各组织可以利用新数据和现有数据更好地理解客流量的模式和行为。此位置信息可用于吸引用户和优化营销战略。对于零售业,这有助于抵制因在线零售商造成实体店销售量下滑的趋势,那些在线零售商多年来已通过在线工具(例如,在线广告的点击转化率)的分析获得了类似的数据。

 

具有 WiFi 功能的智能手机现在可用作客户在线状态到店的标志,这得益于在所有这类设备探测请求中的常通用的 WiFi 机制。这些 802.11 管理帧会定期从连接 WiFi 的设备传输发送。这些帧中包含可用于识别在线状态、在线时间以及在 WiFi 接入点覆盖范围内重复访问次数的信息。不论这些设备的 WiFi 连接状态如何,它们都可以被 WiFi 无线接入点检测到。也就是说,即使用户的设备并未连接到无线网络,只要设备处于网络范围内且已开启 WiFi 天线,则设备的在线状态仍就可以被检测到1

 

由于智能手机目前在普通人群中的普及率已超过 50%2中的普及率已超过 50%,所以可利用探测请求来构建和探测与给定无线接入点范围内的设备(已启用 WiFi)的在线状态有关的重要统计数据集。思科 Meraki 无线接入点和云基础设施负责收集这些数据,并汇总显示在 Meraki 控制面板上。这可以通过直观且可自定义的图表来完成。商家可通过这些图表了解如捕获率(路人与访客)、用户参与度(花费的总时间)和访客忠诚度(新访客和回头客)等的趋势。思科 Meraki 能够利用业界领先的云架构(所有思科 Meraki 产品均已采用)向所有组织提供这些分析。此外,思科 Meraki 的位置 API 可从观察到的探测请求导出原始数据,而组织可以使用这些原始数据直接与第三方数据仓库或分析平台进行集成。这不仅可以促进与传统客户关系管理 (CRM) 平台进行更深入的集成,而且还因为其实时性,为新一代的客户活动计划敞开了大门。

 

整体来看,思科 Meraki 的内置位置分析视图和实时位置 API 完善了现有流量分析功能,并实现了全面了解对思科 Meraki 网络范围内的设备的全面了解。本白皮书探讨将探索思科 Meraki 的位置功能,并对这些功能背后的技术及其可以使用实现的一些用例发表深刻见解进行深入探讨。这些功能是思科 Meraki 的 MR 系列无线接入点的组成部分。

 

1 据媒体报道报告,位置信息的收集和使用已造成了隐私问题。Meraki 对这些问题高度重视,在设计位置分析功能时已充分考虑到隐私问题。不希望此类系统检测到其设备的在线状态的用户只需关闭设备上的 WiFi 天线,即可避免被检测到。

2 https://www.comscore.com/Insights/Market-Rankings/comScore-Reports-October-2014-US-Smartphone-Subscriber-Market-Share

 

位置数据收集

思科 Meraki 无线接入点可通过检测探测请求和 802.11 数据帧,从任意基于任何启用 WiFi 的设备上生成在线状态签名,无论该设备是否连接到网络。WiFi 设备通常会根据设备的状态(参阅表 1)定期发出探测请求。智能手机发送探测请求以发现周围的无线网络,以便用户可以使用这些网络。

 

设备状态 探测请求时间间隔(智能手机)
休眠(屏幕关闭) ~ 每分钟一次
待机(屏幕开启) 每分钟 10 - 15 次
已连接 不确定,可能需要用户手动搜索网络

表 1

智能手机操作系统供应商(iOS、Android 等)上的探测请求间隔因应用、设备升级及其他因素而大不相同3

 

从所有已连接 WiFi 的设备收到的数据帧和从一定范围内(最大通常最远为 100 英尺或更大远)可见的所有设备检测到的探测请求,会在思科 Meraki 无线接入点上生成“发现设备”事件。三频无线接入点有专用的扫描频率信道,用于全天候侦听所有通信道上的探测请求。当 WiFi 设备探测所有信道时,缺少扫描频率信道的双频信道无线接入点可以侦听到探测请求。已发现的设备信息通过无线接入点和 Meraki 云之间的安全管理隧道上传。

 

思科 Meraki 的安全管理隧道已针对接收及发送配置统计信息数据和大量信息进行了高度优化,而且已发现的设备数据所增加的开销几乎可以忽略不计,管理隧道占用的总带宽约为 1 kbit/s。

 

思科 Meraki 无线接入点还能检测到数据帧和探测请求的信号强度,可用于判断 WiFi 设备的实际位置。

 

 

图 1:iOS 设备的典型探测请求 - 从 Meraki 接入点捕获的使用 Wireshark 打开 60 秒的数据包捕获(使用 Wireshark 打开)。

3 基于根据 Meraki 自己的实验和以及我们的分析合作伙伴的实验的实验证据。根据操作系统和手机上安装的应用,此行为往往会有很大差异。例如,如果某个应用非常活跃,则可能导致处于休眠状态的设备每分钟进行多次探测。

数据汇聚和显示

一经 Meraki 云接收后,同一个网络中的所有无线接入点的在线状态签名都将汇聚到一起。汇聚之后,来自每个观察到的客户端设备的数据会经过一系列的计算,以进行分类,用于之后显示。例如,零售商需要了解捕获率,即路过店铺的人数与实际进店的人数的比值。Meraki 云会分析每个客户端设备的信号强度以及在该位置花费的时间来确定捕获率(如果行人只是快速经过店面,那么高信号强度本身并不能说明有访客)。

 

 

在思科 Meraki 的数据库中创建和存储了大量不同的客户端状态,这些状态是通过各种技术进行计算出来的,创建和存储了大量不同的客户端状态。表 2 显示了类别列表和基础逻辑。

 

参数 定义 计算
捕获率 变成访客的路人的百分比。路人是指发现的所有设备,访客则是发现超过一定时间的设备,且信号强度高。此图显示发现的所有设备,无论他们被视为路人还是访客。访客与发现的所有客户端的比率表示捕获率百分比。

1.路人分类:发现至少一次的任何设备

2.访客分类:在 20 分钟时间段内,发现时间超过 5 分钟的设备。RSSI 为 15 或更高会打开一个会话,RSSI 为 10 或更高则保留

参与度 该值(以分钟为单位)显示访客在无线网络范围内花费的时间。 查看客户端在线状态签名的时间戳,计算一个人在无线网络范围内所花费的时间。
忠诚度 新访客与回头客的比例。 每个访客的其他数据库条目检测给定时间段内重复访问的次数。例如,如果某个客户端在一个月内被发现 4 次,那么他们可能会被归类为周访客。如果 8 天内被发现至少 5 次,可会被归类为日访客。

4 RSSI - 95 = 信号强度(单位:dBm)

位置分析

当 Meraki 云实时执行上述计算来计算各种客户端状态时,Meraki 控制面板会通过直观的图表形象地显示捕获率、参与度和忠诚度。这些图表有简单和复杂两种视图,可进行切换。通过日历功能,用户可以放大或缩小给定时间段,查看短细至每天的视图(可显示客流量某一天的变化情况和峰值)或长至数月的视图(可显示季节性波动情况)。

 

通过时间日历功能,您可以选择查看特定时间段。这样您就可以调整上述图表的 x 轴来查看特定时间段的数据,例如访客数量在特定的某一天或某一周的变化情况。

 

邻近图

“捕获率”是变成访客的路人的百分比比例。

“访客”是“访问”您的网络的无线设备。当 Meraki 无线接入点检测到 RSSI 为 15 或更高的探测信号时,即认为发起了一次访问。访客是在 20 分钟时间段内持续发送 RSSI 为 10 或更高的探测信号,且时间长达 5 分钟的设备。

“路人”是 Meraki 无线接入点探测到的发送探测信号探针的设备,但其探测信号和停留时间不符合将其视为访客的要求。

参与度图表

“访客”是高信号强度维持时间超过 5 分钟的无线设备。该图表显示访客在 Wi-Fi 网络中范围内花费的时间。

忠诚度图表

该图表根据访客的回访频率显示访客。例如,周访客表示该访客上个月回访的次数介于 2 次到 6 次之间

运行比较

思科 Meraki 还打造了一款功能强大的比较分析工具,用于深入了解促进洞察网络与给定组织内的各个网络之间的关系。通过运行比较,Meraki 控制面板会将覆盖第二个数据集上的第一个数据集的位置数据叠加在第二个数据集上。可以运行比较来分析不同的数据集,例如:

 

  1. 比较一个站点在单个站点在两个不同时间段(例如本周与上周)的情况比较(如本周与上周)
  2. 两个不同的站点或一组站点之间的多站点比较
  • 比较两个不同的站点之间的比较(站点 A 与站点 B)
  • 比较一个站点与一批站点之间的比较(站点 A 与所有站点,或站点 A 与站点 A 到 D 的平均情况)
  • 比较两批不同站点之间的比较(所有站点与站点 A 到 D 的平均情况)

展开“分析”页面上显示的时间标尺可以轻松执行两个不同时间段的比较分析。

 

利用思科 Meraki 的网络标记功能执行不同批站点之间的比较,该功能允许管理员通过向不同的网络分配一个或多个标记来创建分层网络架构。通过这种方式,可以根据所需报告在多站点组织中执行大量比较,例如“为我显示我的组织内此站点与我的组织内的全国平均水平的比较情况”或者“为我显示组织西区站点与东区站点的比较情况”。

 

 

由于执行新的位置分析,建议部署思科 Meraki 无线网络的方法保持不变。无需变更无线接入点的放置位置、方向或增加更多无线接入点。上一节上面几节讲述的应用试探方法会自动从现有部署中获取数据,以分析并提供有关客流量的数据。

 

在部署已针对位置分析优化的思科 Meraki 网络时,应注意若干一般准则和因素,包括:

  • 按照常用方法像平时一样部署物理访问接入点,来提供无线网络覆盖
  • 在 Meraki 控制面板中,以每个位置一个网络在的组织/网络拓扑中来构建部署,每个位置一个网络。由于位置分析数据是以单个网络为基础计算和显示的,所以您可能需要为每个位置创建一个网络(而不是所有位置处于同一个网络中)。控制面板界面旨在促进简化数百个网络的管理。
  • 在“组织” >“ 概述”页面中上标记不同批的网络组。这样您可以将站点集分组为批次,而且可在比较中根据标记比较过程中进行数据分析。
  • 如果您的网络处于不同的时区,请查看确保“配置” >“ 网络范围”设置页面,上确保每个网络的时区设置都配置正确,从而执行一致的比较。
  • 允许思科 Meraki 的数据库使用您的网络信息进行填充的时间(数天)。

 

营销和业务智能团队的价值

所有的数据分析和图表背后所体现的目标就是:为 IT 和非 IT 部分部门提供一个了解用户在线状态的平台。通过了解一天内客流量的模式和捕获率在不同站点上的变化情况,IT 部门可以更好地了解网络使用情况和趋势,而非 IT 部门(如营销和业务智能团队)可以获得新的见解并回答一些问题,例如“我在站点 A 上的新营销活动是否根据客流量数字展开”或者“我是否需要在高峰时段为站点 B 安排更多员工”。下表突出显示了位置分析可能有用的一些使用案例。

 

使用案例

  • 检测客户端访问总次数
  • 分析和优化窗口对话
  • 优化一天内工作人员的安排情况的人员安排
  • 分析访客的停留时间和回访频率
  • 在站点之间进行比较,或获取一组站点的平均情况,以了解高于或低于平均水平的商店客流量、访客停留时间和回访频率
  • 优化和运行 A/B 测试,了解一个变量发生变化是否会影响可测量参数的结果(例如捕获率)
  • 分析数据并与外部 KPI(如在每个站点上花费的平均时间、每位用户花费的平均时间、每个店铺的平均成本)进行比较
  • 通过优化策略针对每周或季节性波动做好网络准备
  • 通过位置分析数据与流量分析和设备指纹数据的关联,可全方位查看用户在线状态、设备及在线行为

 

位置热图

Meraki 的部分位置功能包括直观显示一天当中人们在特定位置区域内花费时间的具体位置的功能(无论他们的设备是否连接无线网络)。该数据覆盖叠加在建筑平面图或 Google 地图上,并可以为网络管理员和营销/运营团队提供有关某店铺或建筑内特定区域的客流量信息。

 

 

热图页面上的功能

可以切换建筑平面图可以以查看不同楼层的视图,还可以从显示器上中移除无线接入点或显示无线接入点的不同指标(例如型号、当前客户端计数、历史客户端计数等)。热图页面包含“播放”功能,按下“播放”按钮后,可能会看到客户端密度在一天中的变化情况。还可以切换日期,以查看过去某一天的客户端密度。

 

基础指标

热图使用两个指标进行计算:(a) 在具体时间段内检测到的设备的数量,和 (b) 这些设备在区域内停留的时间。地图上的颜色代表“在线”人数最多的区域。强度由特定时间段内检测到的设备数量和这些设备在区域内停留的时间决定。区域颜色可能是暗红色,表示检测到了很多设备或有一些设备在一整个小时内一直停留在该区域内。

 

客户端指示灯

热图上还将绘制通过计算得出的无线网络中的客户端所在的位置图。灰色圆圈代表仅探测但没有连接无线网络的客户端。蓝色圆圈代表已连接到其中一个由无线网络提供服务的 SSID 的客户端。

 

位置 API

Introduction

Thanks to widely available 'smart devices equipped with WiFi and BLE, Cisco Meraki's wireless access points can detect and provide location analytics to report on user foot traffic behavior. This can be especially useful in multi-site retail or enterprise deployments where admins or departments beyond IT wish to learn more about trends and user engagement. Coupled with traditional reporting from the WiFi network on client devices, applications and websites, Cisco Meraki provides a holistic view of online and offline user traffic.

Leveraging our globally distributed datacenter architecture, Cisco Meraki has built an end-to-end system that can aggregate data from thousands of endpoints for effective collection, analysis, and presentation of this data on the Meraki Dashboard. Comparisons can be run between different sites and time periods, and Cisco Meraki's network tagging functionality allows for an unlimited variation of comparisons by creating batches of networks that can be grouped together based on district, region, or any other preference. In addition to the built-in location analytics view, the Location API enables Cisco Meraki customers to detect and aggregate real-time data for custom applications.

The location API delivers data in real-time from the Meraki cloud and can be used to detect WiFi (associated and non-associated) and Bluetooth Low Energy (BLE) devices in real-time. The elements are exported via an HTTP POST of JSON data to a specified destination server. The raw data is aggregated from all access points within a network on the Meraki cloud, and sent directly from the cloud to an organization's data warehouse or business intelligence center. The JSON posts occur frequently, typically batched every minute for each AP.

Using the physical placement of the access points from the Map & Floorplan on the Dashboard, the Meraki cloud estimates the location of the client. The geo-location coordinates (latitude, longitude) and X,Y location data accuracy can vary based on a number of factors and should be considered a best effort estimate. AP placement, environmental conditions, and client device orientation can influence X,Y estimation; experimentation can help improve the accuracy of results or determine a maximum acceptable uncertainty for data points.

Scanning Data Elements

The Scanning API version 2.0 data architecture device classification and location information. Using the physical placement of the access points from the Map & Floorplan on the Dashboard, the cloud estimates the location of the client.

 

Data Elements

Name
Format
Description
apMac string MAC address of the observing AP
apTags [string] JSON array of all tags applied to the AP in dashboard
apFloors [string] JSON array of all floorplan names on which this AP appears
clientMac string Device MAC
ipv4 string Client IPv4 address and hostname, in "hostname/address" format; only "/address" if no hostname, null if not available
ipv6 string Client IPv6 address and hostname, in "hostname/address" format; only "/address" if no hostname, null if not available
seenTime ISO 8601 date string Observation time in UTC; example: "1970-01-01T00:00:00Z"
seenEpoch integer Observation time in seconds since the UNIX epoch
ssid string Client SSID name; null if the device is not connected
rssi integer Device RSSI as seen by AP
manufacturer string Device manufacturer; null if manufacturer could not be determined
os string Device operating system; null if the OS could not be determined
location location Device geolocation; null if location could not be determined
lat decimal Device latitude in degrees N of the equator
lng decimal Device longitude in degrees E of the prime meridian
unc decimal Uncertainty in meters
x [decimal] JSON array of x offsets (in meters) from lower-left corner of each floorplan
y [decimal] JSON array of y offsets (in meteres) from lower-left corner of each floorplan

HTTP POST body format

{
   "version":"2.0",
   "secret":<string>,
   "type":<event type>,
   "data":<event-specific data>
}

 

Event Specific Data Format

{
  "apMac": <string>,
  "apTags": [<string, ...],
  "apFloors": [<string>, ...],
  "observations": [
    {
      "clientMac": <string>,
      "ipv4": <string>,
      "ipv6": <string>,
      "seenTime": <string>,
      "seenEpoch": <integer>,
      "ssid": <string>,
      "rssi": <integer>,
      "manufacturer": <string>,
      "os": <string>,
      "location": {
        "lat": <decimal>,
        "lng": <decimal>,
        "unc": <decimal>,
        "x": [<decimal>, ...],
        "y": [<decimal>, ...]
      },
    },...
  ]
}

 

Enable Scanning API

The Location API is configured in the Meraki Dashboard on the Network Wide > General settings page in a few simple steps:

  1. Turn on the API by selecting Scanning API enabled in the dropdown box.

  2. Specify a post URL and the authentication secret (the secret is used by your HTTP server to validate that the JSON posts are coming from the Meraki cloud)
  3. Specify which Scanning API version your HTTP server is prepared to receive and process.
  4. Configure and host your HTTP server to receive JSON objects.
  5. Upon the first connection, the Meraki cloud will perform a single HTTP GET; the server must return the organization-specific validator string as a response, which will verify the organization's identity as the Cisco Meraki customer. The Meraki cloud will then begin performing JSON posts. 

 

 

 

Protocol flow between Meraki cloud and third-party server:

 

Bluetooth Scanning API

Meraki APs with an integrated Bluetooth Low Energy (BLE) radio can detect and locate nearby Bluetooth Low Energy devices. This data is then provided via API to third party applications. Examples of such devices include battery based beacons, Apple iBeacons, fitness monitors, and remote sensors. 

Using the physical placement of the access points from the Map & Floorplan on the Dashboard, the Meraki cloud estimates the location of the client. The geo-location coordinates (latitude, longitude) and X,Y location data accuracy can vary based on a number of factors and should be considered a best effort estimate. AP placement, environmental conditions, and client device orientation can influence X,Y estimation; experimentation can help improve the accuracy of results or determine a maximum acceptable uncertainty for data points.

 

To enable BLE devices to be located, enable the BLE scanning radio on the access points. BLE Scanning is enabled in the Wireless >  Bluetooth Settings > Scanning settings page by selecting "Scanning enabled" in the Scanning section, as shown in Figure 3 below:

Figure 3: Enabling BLE scanningBLE Scanning API

 

Bluetooth API Data Elements

Name
Format
Description
apMac string MAC address of the observing AP
apTags [string] JSON array of all tags applied to the AP in dashboard
apFloors [string] JSON array of all floorplan names on which this AP appears
clientMac string Device MAC
seenTime ISO 8601 date string Observation time in UTC; example: "1970-01-01T00:00:00Z"
seenEpoch integer Observation time in seconds since the UNIX epoch
rssi integer Device RSSI as seen by AP
location location Device geolocation; null if location could not be determined
lat decimal Device latitude in degrees N of the equator
lng decimal Device longitude in degrees E of the prime meridian
unc decimal Uncertainty in meters
x [decimal] JSON array of x offsets (in meters) from lower-left corner of each floorplan
y [decimal] JSON array of y offsets (in meteres) from lower-left corner of each floorplan

Enable the Scanning API with BLE Scanning, and the Location API will include both WiFi and Bluetooth devices seen by the access points in a single data feed. The event type BluetoothDevicesSeen is used to identify the observations from the Bluetooth radio. Below are the JSON formats used by the Location API for Bluetooth devices.

 

HTTP POST body format

{
   "version":"2.0",
   "secret":<string>,
   "type":"BluetoothDevicesSeen",
   "data":<event-specific data>
}

 

Bluetooth API Data Format

{
  "apMac": <string>,
  "apFloors": [<string>, ...],
  "apTags": [<string, ...],
  "observations": [
    {
      "location": {
        "lat": <decimal>,
        "lng": <decimal>,
        "unc": <decimal>,
        "x": [<decimal>, ...],
        "y": [<decimal>, ...]
      },
      "seenTime": <string>,
      "clientMac": <string>,
      "seenEpoch": <integer>,
      "rssi": <integer>,
    },...
  ]
}

Location and Privacy

Meraki understands that some end users may be concerned about the collection and use of location information. In an effort to address these concerns, Meraki developed location services with privacy in mind, including a number of security mechanisms to eliminate uniquely identifiable elements from the data that it collects. Meraki also recommends that its customers and partners implement a number of privacy-friendly features. 

 

Meraki uses probe requests, data frames, and bluetooth beacon frames to locate and store client location. Because the location data contain raw MAC addresses, Meraki implemented a number of security mechanisms to anonymize the data in an irreversible fashion. Once uploaded, the Meraki cloud anonymizes or produces a hash of MAC addresses so that they are not identifiable. The Meraki cloud only stores the hashed version of the MAC address.

 

The hash function is as follows:

hash(mac bytes, org secret) =

SHA1(mac bytes ++ org secret).takeRight(4)

 

where:

++ indicates concatenation;

takeRight(4) returns the least significant 4 bytes of the SHA1; and

org secret is a per-customer salt.

 

Example:

client MAC is 11:22:33:44:55:66

org secret is t3lrdd

 

least significant 4 bytes of SHA1(112233445566t3Irdd) = 0x0e456406

 

SHA1 is a widely known one-way cryptographic function. Using SHA1 hashes in this manner is the current industry standard. In order to provide an additional layer of security beyond SHA1 hashing, Meraki's hash function truncates the hash to 4 bytes. This produces an information theoretic loss, as the domain of the function is larger than the range: a 6-byte MAC allows (2^48) possibilities whereas a 4-byte hash allows (2^32) possibilities. This results in 65,000 possible (org + MAC) combinations for each one 4-byte hashed MAC address. Therefore, given a MAC that has been salted, hashed, and truncated with the unique Meraki algorithm, it would be mathematically impossible to know with a reasonable degree of certainty what the original client MAC address was.

 

The hash function leads to information theoretic loss, and the original MAC address of client can never be recovered.

 

Cisco Meraki includes a customer-specific org-secret in the hash function. As a result, Cisco Meraki does not have any visibility into client behavior across our customers networks worldwide. And, of course, no Cisco Meraki customer can see the analytics of another customer's organization or where foot traffic goes after leaving the presence of its own WiFi / BLE network.

 

Finally, Cisco Meraki's website offers a global opt-out feature that allows users to submit the MAC addresses of their devices, after which the Meraki cloud will no longer detect their MAC addresses either for its built-in Location Analytics views or for real-time export via the Location API. Cisco Meraki also recommends that retailers and others using the Location API post notices on the availability of this global opt-out in prominent locations, preferably in the storefront or at building entrances where location detection is taking place. 

 

Privacy for Location API

Cisco Meraki's Location API, outlined above, exports raw MAC addresses to a specified third-party server. There are a number of privacy protection mechanisms that we have implemented, including:

 

No customer identity tie-in mechanisms

Cisco Meraki does not directly provide any way of tying MAC addresses to customer identity. These systems must be separately built and hosted by a customer, partner or service provider.

 

No customer contact mechanisms

Cisco Meraki does not provide any mechanism by which the location API data can be used to contact customers in any way. For real-time user engagement, Cisco Meraki customers must build and maintain their own platform for contacting customers.

 

Recommended best practices

Cisco Meraki recommends a number of best practices for users of its API, including:

  • Opt-in Cisco Meraki customers should make it explicitly clear at the time of identity tie-in (e.g., via a splash page or through a mobile app) that user-provided information may be linked to a device's MAC address for more extensive engagement.
  • On-premise notification As with the use of the built-in Location Analytics, notice should be prominently displayed in areas using of the Location API data.
  • Opt-out In addition to providing an opt-in policy, Cisco Meraki customers should make their own customers aware of Cisco Meraki's global opt-out policy (allowing an opt-out by MAC address) and provide an intuitive means of accessing Cisco Meraki's opt-out page. Cisco Meraki's global opt-out is available at https://account.meraki.com/optout.

Troubleshooting

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.

You must to post a comment.
Last modified
17:56, 19 Jul 2017

Tags

Classifications

This page has no classifications.

Article ID

ID: 6031

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case