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.
PROBLEM #3:
Customer complained of poor WiFi performance. In fact they said they couldn't connect to WiFi at times.
I open my packet sniffer and capture this.
ANSWER #3
If you answered this is a CRC you would be correct. This simply means my sniffer could not properly read the frame. Getting closer to the transmitting radios will often lower your CRC rate. It is not uncommon to see CRC frames with odd bits flipped.
Trick question. :)
PROBLEM #4:
Customer stated their new medical cart that transmit high resolution images is crawling. Last month during a presales demo it worked fine with no issues.
I conducted a packet capture. I see this in the capture window playing over and over and over again. The cart isn't moving. Its sitting still, directly under an access point. What do you think ?
ANSWER #4:
One thing is clear and something important to drive home. A device off channel scanning or in doze state ISN’T passing user data. We know NULL frames use the power management bit to inform the access point to buffer frames. This happens for two reasons. To save power and enter doze state or to build a neighbor list for a potential roam by conducting off channel scanning.
In this situation we know the client is trying to build a neighbor list. The NULL power managment bit set to 1 indicating to buffer at the access point and then we see off channel probes (see channels 1,6,11) to build a neighbor list. This is an indication the client is likely trying to find a better access point.
- This could be a faulty driver
- Misconfigured client with high roaming set
- Poor radio with no reception
- Antenna broken or not attached properly
- Interference
It can be a number of things and in fact was most of the above!
It was a USB soho NIC installed inside the monitor surround by metal on most sides. When enclosed due to the poor USB performance the client could barley keep a connection and was ALWAYS roaming for new access points due to its poor performance and placement. This is why we see the NULLs and the probes.
I hope you enjoy my ramblings .. Till next time!