Skip to main content

Proving "It's not the Wi-Fi network"

 

We’ve all been there – or at least most of us have, anyway.  The Wi-Fi network appears to be misbehaving and users are frustrated.

 

Your users will be working for several hours, and then, it looks to them as if someone shut the entire WLAN off.  Their workstation’s Wi-Fi icon, when hovered, states “no Wi-Fi connections are available”.

 

Now comes the fun part – well, to me it’s fun, anyway.  Let’s start out with what the normal operation of the WLAN client looks like.  This particular client is stationary.  It’s a laptop that is used like a stationary desktop, and is cabled to the desk via lock and key.  I wanted to clarify that because you won’t see any roaming in this packet capture, and you shouldn’t see any.

 

Since the client is associated to an AP on channel 36, I set my protocol analyzer to only look at that channel, and then set a filter to only look at the client adapter.  This makes is a lot easier to what’s going on.  I will use this as my baseline, since I want to know what it looks like when everything is working normally.  Here’s normal for this client:

 

Encrypted data from AP to client

Client Request to Send to the AP

AP responds with Clear to Send

Client sends data

AP acknowledges data with ACK packet

 

 

Now we will fast forward a few hours.  The user called you and told you “The Wi-Fi is down”.  Or is it?  To them, it is!

 

We start our same packet capture as before – same filter, same channel.

 

Now the picture is very clear.  The Client doesn’t see the beacon of the AP’s BSSID because it is sending probe request to ff:ff:ff:ff:ff:ff and we are seeing the unicast probe responses from the APs (only on channel 36 because of the filter) to the client.  I believe the client should send unicast probe request to the AP.

 

The c lient does not appear to see the beacon of the APs, and starts sending out probe requests.  The APs respond, but the client does not appear to see the probe response.  Almost as if they WLAN client has gone deaf.

 

  

Thankfully, the “quick fix” is to turn the WLAN adapter off and then back on.  Long-term fix will most likely entail downloading and installing new WLAN client drivers.

 

 

 

 

Comments

Popular posts from this blog

Aligning a P2P Wi-Fi bridge link

I was recently called out to investigate a Wi-Fi bridge link that was being accused of being the culprit of a myriad of network problems. Upon arrival on site, I noticed that the main site’s Wi-Fi bridge was sitting on channel 161, and that channel was overpopulated since there were two access points in the building, both on channel 161.  I moved the building’s access points to the UNII-1 band, and changed the bridge’s channel  to help alleviate some of the congestion since there was another access point on that channel across the street.  These three screenshots are  before I made any changes: Note that the bridge is capable of achieving a 54 mb/s data rate, however only 3% of all the packets are traveling at that rate – and 92% of them are data packets.  The busiest data rate is the lowest data rate – with 72% of the traffic at that rate.  Hmmm…. Also, a quick screenshot as a baseline..   After coming up with a cha...

Using your autonomous AP as a Spectrum Analyzer

  Most of us have all done an APoS (AP on a stick) survey, either active or passive, for a customer by now.  Many of us also take a snapshot of the spectrum while doing our WLAN surveys.  We either use an integrated Spectrum Analyzer, such as the DBx adapter coupled with Ekahau’s ESS software, or we use a spectrum analyzer adapter(hardware) and software to collect data for off-site analysis.   If you own the DBx adapter and use it with Ekahau, that doesn’t mean you own Chanalzyer, which is Metageeks Spectrum Analyzer software.  Which leads me to this post, as I do not own a copy of the software mentioned previously.   If you are on-site, using a Cisco 3602i series autonomous AP for your APoS active/passive survey, did you know that with just a little bit of effort you can use it to grab your Spectrum Analysis file?   I usually have my old Dell D630 workhorse with me, which has a PCM/CIA  slot, an old Cognio card, and Cisco Spectrum Exp...

Is there a need for a Spectrum Policy within the Enterprise?

I recently came across this some equipment that interfered with Wi-Fi in the worst way – well, that’s my opinion, and I will let you be the judge.   We’ll first start out with stating the obvious.  The 5GHz UNII bands are license free, which means it is a free-for-all when it comes to who is doing what.  Most of us (the folks reading our blogs) all understand that.  However, when an Enterprise environment has millions and millions of square feet of office, retail, healthcare or manufacturing space, I think the Company’s Enterprise IT department owes it to their internal customers to have a Spectrum Policy to keep the spectrum in check.  Letting the company buy whatever they want, whenever they want, and deploying it randomly as they see fit, doesn’t work well, as you will see if you continue reading.   I recently came across a surgery center consisting of 8+ operating rooms, and the Wi-Fi was at the core of the complaints....