We are investigating a customer issue involving Enterprise Wi-Fi APs (XV2-22H).
Our devices use a third-party Wi-Fi module. During startup, the module may briefly use its factory MAC address before switching to the final application MAC address used for normal operation.
We are trying to determine whether the AP can detect, track, or retain information about a MAC address that is seen during the early stages of the Wi-Fi connection process but does not ultimately complete the full connection sequence.
We have already collected the following information from the AP:
service show debug-logs rca-agent shows Authentication, Association, EAPOL, and DHCP activity only for the final MAC address.
show wireless clients only shows the final MAC address.
show wireless clients unconnected reports no failed clients.
We do not see evidence that the temporary MAC address completes association or obtains a DHCP lease.
Our questions are:
Does the AP track Probe Requests or other pre-association activity from client MAC addresses that never complete authentication/association?
Are there CLI commands, debug logs, packet captures, or internal tables that can show these events?
Can such MAC addresses remain in any client table, cache, forwarding table, or resource database after the client switches to another MAC address?
Is there any configurable aging timer associated with these entries?
Could these entries affect client capacity, DHCP operation, or IP address assignment in any way?
Can the AP perform an over-the-air packet capture of management frames (Probe Request, Authentication, Association) for a specific client MAC?
Any guidance on the best commands or debug methods to verify this behavior would be appreciated.
The Location API feature monitors client probe requests on the current channel. When a client transmits probe requests using its initial MAC address, there is an opportunity to capture the real/initial MAC address through this method. Enabling the Location API would allow us to leverage this capability effectively.
Configuration:
location-api server
enable-probe-clients
Once configured, please run the following command to review the discovered clients:
show wireless clients discovered
Additionally, packet capture can be used as an alternative approach, as it has the ability to intercept and record all wireless packets, including probe requests.
Please refer to the User Guide for detailed instructions on enabling and configuring both the Location API and packet capture functionality.
Could you please provide the specific User Guide, document link, or section that describes these commands and their configuration?
You also mentioned that packet capture can be used to capture wireless packets, including probe requests. Could you please provide the detailed steps to perform packet capture on the XV2-22H?
A few specific questions:
Can packet capture be started from the AP CLI/SSH, or does it need to be configured from the web UI or cnMaestro?
Can it capture 802.11 management frames such as Probe Request, Authentication, and Association frames?
Which interface/radio should be selected for the capture?
Can we filter the capture by a specific client MAC address?
How do we export the capture file so it can be opened in Wireshark?
Does this feature require any specific firmware version or license?
Our goal is to determine whether a client briefly transmits probe requests using its factory MAC address before switching to its final application MAC address during startup.
Hope you’re doing well! Please find below the recommended steps for configuring the Real-Time Location System (RTLS) / Location API and performing a Packet Capture on your Enterprise Wi-Fi Access Point.
We recommend using CLI (clish) commands to configure the Location API, particularly for probe client support, as it requires an additional parameter that is only available via clish. Please run the following commands:
location-api server server-url
enable-probe-clients
If you prefer to manage this through the cloud (cnMaestro), please apply the equivalent settings under User Overrides.
Packet Capture
For detailed instructions, please refer to the Packet Capture section in the user guide.
To perform a packet capture via clish, please use the following commands:
To start capture on Radio 1, run packet-capture radio 1 start duration 120
To start capture on Radio 2, run packet-capture radio 2 start duration 120
To check the capture status, run show packet-capture status
Once the status shows Completed, export the capture file using the command export packet-capture tftp://<server-ip>/<remote-file-name> <local-file-name>
Both TFTP and FTP are supported for the file export. The local file name can be retrieved from the Filename field in the show packet-capture status output.
no SSH connection attempt is observed on the Windows server.
Questions:
Is there any AP-side restriction or additional configuration required for the AP to initiate ICMP/SCP traffic to a host on the local subnet?
Is there a command to test outbound TCP connectivity from the AP to a specific host/port?
Is there another recommended way to retrieve the packet capture file from the AP?
I typed in “location-api server server-url”, there is no error. But I guess the server-url should be an actual url, right? One additional question regarding the Location API:
The CLI help indicates that:
location-api server
expects an HTTP/HTTPS server to receive the reports. Could you provide an example of the expected server-url format and explain what server/application is required on the receiving side?
For testing purposes, is there a way to view the probe-client data locally on the AP after enabling:
enable-probe-clients
or is an external Location API / RTLS server required?