I recently came across a situation that got me thinking about how I should go about analyzing these traces moving forward; a happy accident led to a new realization.
Here is an I/O graph of a trace taken at a hospital; spoiler alert: this is an instance of low coverage.
The Y axis is signal in percentage, the X axis is time in seconds, so this is about a 60 second trace.
The black line across the top represents the upstream frames from the device to the access point. The device is very close to the test adapters which is why the signal is so good.
(wlan.ta == xx.xx.xx.xx.xx.xx)
The blue dots represent the downstream frames from the access point to the device. As I roam through the area, the blue dots start off good with good signal and fall down the graph as the signal degrades, then it roams and finds another good access point and the dots go back up to the top and start all over again.
(wlan.ra == xx.xx.xx.xx.xx.xx)
The red lines are upstream frame retries.
(wlan.ta == xx.xx.xx.xx.xx.xx) && (wlan.fc.retry ==1)
The green lines that are mostly hidden by the red lines are probe request / responses.
(wlan.addr contains xx.xx.xx.xx.xx.xx) && ((wlan.fc.type_subtype == 0x0004 || wlan.fc.type_subtype == 0x0005))
The device is roaming pretty much as expected until 27 seconds in and the blue dots disappear. This happens again at 37 seconds as well.
These are the two red circles in the I/O graph where the dots disappear. That would indicate that there was an audio gap but no audio gap was heard. Upon further investigation, the reassociation request frame in both instances shows the exact same current AP:
The current AP in both instances was not the BSSID shown before the frame gap, which it should have been. It turns out that the frame gap in downstream frames was caused by associating to a channel I didn't configure an adapter for, because channel 44 was not in the path of where I was walking and testing. This is why I didn't lose audio, but I still had gaps in my trace and I/O graph.
Once I figured out what access point I did associate to, I used Ekahau to find it and found it was installed two floors above my location:
The reason it did that was because of the big coverage hole on my floor:
I knew there was a coverage hole and now I had the data to prove that the device will roam two floors up to stay associated. However, I would have never found that had I not roamed into a channel I didn't have configured in the trace. If those blue dots hadn't of disappeared, I would have never noticed the roam to the floor upstairs!
The lesson learned is to trace each roam with Ekahau and Wireshark and make sure you can see what access points your device roams to so you don't miss a problem like this.
Comments
Post a Comment