Customer Service Center

Let say the a customer is seeing some clients are being disassociated after 10-12 hours of testing, and they need to figure it out the reason for this, was the AP the one causing the disassociation or was the csutomer?, so, letting a normal sniffer capture running won't help much (You need 802.11 capture set to capture 802.11 messages, otherwise you will capture only ethernet).

The reason we are saying this capture won't work is as follows: Let say they let the test running overnight and it fails after 8 hours testing (while the capture is running), then the customer comes back after 12 hours (4 hours after the client(s) got disconnected), at that time the capture probably would be already overwriten by multiple frames the sniffer port captured, so it would be very difficult to find out the reason for this disconnection.

So, is it possible to set some sort of filter on the capture to try to determine the possible reason for a disassociation in a long term test? Probably after 10-12 of testing?
 

Yes, looks like we managed to set a filter on the Sniffer capture and captur only Authentication / Association Request / Association Response and Deauthentication messages, capturing those messages only will help us to determine whether if it was the AP or the Client the one that started the deauthentication/disassociation.

Be aware this filter seems to work only on 802.11 Sniffer Mode and no in 802.11 Regular mode, that means the customer will need an aditional port to make the sniffer, since you can NOT emulate a client/AP on the same port that has 802.11 sniffer mode capture enabled.

Note: Additionally you can use the IP logs to get more information, find more information at the end of this section.

Steps:
 

1.    Open a new fresh GUI (This will create a new directory under \users\username\Documents\Spirent\TestCenter <version>\Logs)

NOTE: Every time you open a new GUI, a new time-stamped folder is created on this directory, so make sure to write down the time you open this GUI because these logs will be helpful for us at the end of the test

2.    Open the configuration file you are using for this test and bring the ports up

3.    To be able and do an 802.11 sniffer capture we do need an additional radio/port that will act exclusively as a sniffer.

This means, you can not emulate a wifi client on this same port, that is why we do need an additional port, hopefully you have a free/available wifi port we can use for this (crossing fingers)

4.    So, bring that additional port into your configuration and go to Capture > General Tab and enable IEEE 802.11 Sniffer Mode  capture mode

5.    Hit APPLY

6.    On that same Sniffer port capture section, go to the Frame Filters tab.

- Here, we will create a filter to match:

1.    Management type frames, AND

2.    Frames that TA (Transmitting address) is = AP MAC ADDRESS OR STC CLIENT MAC ADDRESS, AND

3.    Frames that RA (Receiving Address) is NOT a broadcast address (This last is to avoid capturing probe response frames that may cause the capture to overwrite the messages we are looking for)

- Here is an example of how the QUERY should look like:

•    In my case:
a.    00:10:94:00:00:02 = AP mac address (this may vary in your environment)
b.    00:10:94:00:00:01 = STC CLIENT mac address (this may vary in your environment)

 

NOTE: You may want to use “Manual Entry” to manually type your AP MAC ADDRESS and/or STC CLIENT MAC ADDRESS, this would be faster, additionally that I got a message when trying to use the “From Device” section, not sure why, but using Manual Entry worked like a charm.
Find attached a very short video (1 minute) with a demonstration about how to easily create this filter on the capture.

7.    After creating the filter, please hit APPLY

8.    Start the capture just on that sniffer port (Capture section -> top left side on that section, just a little bit above “General” tab,  there is a START button)

9.    Start your test

10.    As soon as this issue shows up (STC 6G WiFi Clients are being disassociated after 10-12 hours of testing) please stop the capture and save it

 

Now you can see from the capture who device was the one that started the deauthentication/disassociation (Find a sample capture attached)

Aditionally, go to the session logs (The new directory under \users\username\Documents\Spirent\TestCenter <version>\Logs we mentioned on step 1 above) and open the IP Logs (Ip logs are the logs named starting with your chassis IP address, something like: 10_108_5_16.log), and do a search by "ASSOCIATION"

Below is an example of what you can see, we did a quick test (b2b) emulating STC Client on port 1 and AP on port 2, then doing the following tests:

1.- Test 1: Doing a "Shutdown AP"
2.- Test 2: Doing a "Deauthenticate Client" from STC Client.

Below are the differences on messages under IP logs whether deathentication/diasassociation comes either from Client or AP:

-You can notice that for test 1 ( Doing a "Shutdown AP" ) immediatly shows the Cilent State into "ASSOCIATE FAILED)
- You can notice that for test 2  (Doing a "Deauthenticate Client" from STC Client.) the Client States goes to "IDLE" instead