Sniff Wi-Fi

People who do WLAN analysis agree that filtering is a part of sniffing WiFi frames/packets.  More information can be extracted from captures when the focus is on one AP or station or protocol (or a combination of same).  Where people disagree is on which type of filtering is best: capture filters or display filters?  Yours truly is a capture filter man, and some iPhone analysis was a reminder why. Filtering 802.11 captures is covered pretty well in the CWAP Study Guide (of which I am a co-author).  A capture filter extracts frames before  they are captured.  The only frames captured are the ones that match the filter.  A display filter extracts frames after  they are captured.  Every frame is captured.  Then the filter is applied so that only frames matching the filter are shown in the protocol analyzer.  To use the example of a filter on my iPhone, if a capture filter were used then all of the frames from all of the other stations on my iPhone's channel would be lost.  Usin

QoS the packets of iPad ,  and all through the air  not a station was Probing, not even a hair When suddenly on to my Wireshark screen Appeared Video, Voice and Background, it seemed "But alas", I exclaimed, as I looked at the MACs This is only one tablet, not a bushel or stack To the standard I looked, to decipher the meaning And to you, dear reader, I offer this gleaning The standard in question is dot11e and the goal of its authors was to keep the air free from clutter like YouTube and Facebook or Twitter that might cause your voice conference to lag and/or jitter But remember, dear sniffers, we're still talking WiFi A world where each access point, smartphone and MiFi makes its own way to the channel or not deciding on rates, QoS and the lot So take heed if your WiFI must work for those apps that users just love but treat admins like saps a smartphone may say, "this packet is Voice" but the AP may reply, "Best Effort; no choice"

About a year and a half ago, yours truly wrote about WiFi transmit power levels in iPhones .  Things have changed since then.  And possibly the biggest change (to iPhones, at least) is how aggressive iPhones are in modifying transmit power levels.   In the "Mighty iPhone Power Ranges" blog post, I wrote about the value of setting AP transmit power levels to approximately the same level as client/station device power levels.  Over the past year or so, more and more client/station devices have started using adaptive power levels.  A typical implementation would force a device to lower its transmit power when receiving a strong signal from the AP and raise its transmit power when the AP's signal is weak. The unanswered question is, "just how vast are these ranges of transmit power levels?"  Can a smartphone or tablet go as low as half power?  10% power?  0.0001% power?  Those differences could have a major effect on a WLAN infrastructure's ability to handl

I’ve seen a lot of 802.11 amendments in my day.  From speed (ac) to security (i) to voice (e), a lot of those amendments have done great things.  But 802.11v isn’t going to be one of them.  One look at an iPhone’s (iOS 7 iPhone, that is) 802.11v capabilities shows that the dream of Wireless Network Management delivering client control is still just that: a dream. It has long (well, for a dozen years or so) been a desire of WiFi admins to have more control of client/stations.  Control over which AP the client will connect to.  Control over what signal strength (or signal-to-noise ratio [SNR] or error % or BSS density) will trigger client roaming.  Control over which Final Fantasy character they will assume at that weekend’s LAN party.  (I know virtually nothing about video games, so feel free to make dumb jock jokes at yours truly’s expense.) For about half as long, WiFi admins have had hope for client control on the horizon: 802.11v.  The wireless network management (WNM) amen