Reply to comment:

Yang Yu
Personally I see limited user cases for wifi measurements. In the proposed user case, POE support might be needed. And to monitor the health of a wifi network, I am not sure if ping/traceroute/DNS/SSL is even close to sufficient. All these can be done from the switch (wired). There are alternative solutions for wifi health monitoring better suited for this use case. I am not exactly sure who decides which SSID to connect. This article makes it sound like I could create a measurement for CableWiFi and any wifi-enabled probe can be selected to perform measurements if they have the SSID in range (constant scanning is involved). Sounds really cool. And definitely opt-in, it's simply too invasive to turn on wifi on all probes without permission. Better yet, load a different firmware when users opt in for wifi measurements (give the peace of mind for those that do not want wifi, they can have the non wifi-enabled firmware). If the current platform can measure RSSI, SNR, noise (relative values over time, not trying to compare values from one probe to another), imo it's fine to keep this platform. If only the probe hosts can configure which SSID to connect, then that would be too much configuration for probe hosts (no point for opt-out model, if its not going to get configured, then why have it enabled at all). Very limited use cases as I can see. Features needed: wpa2-enterprise support scheduling: (not) run measurements during certain hours BSSID priority, blacklist/whitelist: very helpful when multiple APs with the same SSID are in range