;)
802.11 Packet Capture Skillz To Pay The Bills
Tuesday, February 16, 2016 at 5:13PM Digging deep into the Stefanick archives of real world 802.11 issues. I challenge YOU with 4 real world examples. Keep in mind sometimes the obvious is not so obvious. While frames don’t lie understanding 802.11 is important to see the truth.
These are real customer issues on real networks with real problems.
PROBLEM #1:
Customer complained of slow WiFi performance in a specific part of the warehouse. It's always been slow said one worker. It's never really preformed right since it was installed.
During my packet capture I observed a lot of frames with a similar “bit" being marked. What “bit" could be a clue that might contribute to a slow network ?
ANSWER #1
If you answered retry bit you would be right. The retry counter was above 30% for channel 6. While the noise reference on channel was within reason the packet capture was a "bit" misleading displaying a -92. No pun intended. I turned on WiSpy, low and behold layer 1 interference. There were old security cameras operating on 2.4 no longer in use but still powered. The cameras were causing interference across channels 1 - 6, causing high retry rates.
WiSpy
PROBLEM #2:
After a recent firmware update a number of Cisco 7925 phones exhibited an odd behavior. They would connect to the wifi network and then disconnect and display Locating Network Services. This happen repeatable.
I open my sniffer and see frames much like this one.
ANSWER #2
If you answered duration timer you would be correct. The duration value caught my attention during troubleshooting. In the end it was a firmware bug on the handset due to an interoperability with a specific configuration and 802.11n access points. Note when a client sends a duration value, clients who can demodulate this frame will use this value and reset their clocks to busy. This was impacting the entire cell and not just the phones.
Reader Comments