Sniff Wi-Fi

It's summer in Los Angeles, which can only mean one thing: Sequels! As movie fans indulge in a third 'Avengers', a fifth 'Jurassic Park', and what feels like a seven hundreth 'Star Wars', this here blog is providing a sequel to a probably-long-forgotten Sniff Wi-Fi post called ' Why Are You Slowing Down My Wi-Fi, Apple? ' Turn down the lights, pop some popcorn, and enjoy the twists and turns of this harrowing look into Wi-Fi Calling on iPhones. Several months ago, this blog highlighted the Wi-Fi behavior of the iPhone X  using OmniPeek.  Truth be told, that post was a little bit like the latest 'Spider-Man' sequel: attention-grabbing title, some interesting content, but ultimately nothing consequential.  And just as movie fans knew that Michael Keaton's flying bird character wasn't going to beat the lead superhero,  a lot of Wi-Fi folks already knew that Apple iOS devices use Protection (called a "TXOP" in the blog po

One of my favorite things to do is teach Wi-Fi, and one of my favorite tools for teaching is Savvius  OmniPeek .  The good folks at Savvius were nice enough to provide OmniPeek for the Wi-Fi classes I oversee at Global Knowledge , and so I want to offer a taste of how OmniPeek can be used to learn about Wi-Fi device behavior, specifically with the iPhone X. Savvius OmniPeek is what I call a hardcore protocol analyzer.  The "hardcore" adjective comes from the fact that OmniPeek encourages the user to view frame (aka "packet") traces.  Non-hardcore protocol analyzers focus on providing statistics and graphs.  I am a big fan of all types of protocol analyzers, but the beauty of OmniPeek is that it offers options for viewing statistics and graphs, while making its frame traces simple to navigate. One of the things I like using OmniPeek for when teaching is illustrating the different ways that Wi-Fi devices and APs use the 802.11 standard.  An example is what happen

Via my YouTube page : *** If you like my blog, you can support it by shopping through my  Amazon  link.  You can also donate via Paypal below, or by sending Bitcoin to  1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU Twitter:  @Ben_SniffWiFi ben at sniffwifi dot com

Voice over WiFi is scary.  Retries, packet errors (due to lots of Retries) and high latency (usually due to packet errors that happen because of lots of Retries) will murder a WiFi network's ability to handle Voice and leave your users screaming (not actually screaming) like they were cast in a horror movie (or, at the very least annoyed like a character from Office Space).  But there's one thing that sometimes scares people, but really shouldn't: Voice Arbitration.  It's not going to kill your WiFi voice calls.  In fact, it will almost certainly help. Arbitration is a process defined in the 802.11 standard .  Every device (client/station and AP) goes through it. The simplest way I can describe 802.11 Arbitration is like so: If your AP or station has heard a quiet channel for 37 microseconds (0.000037 seconds), then your AP or station transmits a frame (what most people call a packet, but I call a frame). If your AP or station has been hearing a busy channel fo

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"

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

You'd think a great company like Apple would care about my privacy BUT NO. Behold, my iPhone: You see what's going on here?  That's my iPhone there.  Apple_57:8d:89.  (Filtered using wlan.sa == f4:f1:5a:57:8d:89 if you're curious.)  And look what it's doing.  IT'S PROBING.  The iPhone of a respected security do-gooder like myself is out there for any hooligan to see. Do I look like the type of person who wants the world to know that I used my phone at the MGM Signature in Las Vegas?  (Well, maybe.  I could've prevented the phone from probing by just tapping on the SSID instead of typing it in.  But typing in SSIDs on iPhones/iPads is a neat trick for keeping stinky captive portal splash pages from coming up over and over again on guest WLANs.)  Or on the VerizonWiFi network at Staples Center?  (Which added a captive portal and lost A TON of guest connections, thus harming overall channel performance for all WiFi users in the arena.)  Why would I wa

Quiet when standing still; active when moving.  That is the way that WiFi devices should treat Probe Requests.  Android devices (at least, Android devices that act like yours truly's Samsung Galaxy Tab 2) probe the right way .  After doing a quick test on the iPhone 5, it appears that Apple has their devices probe based on movement as well. Apple iOS devices have a terrible reputation in some WiFi circles.  The author has heard complaints about mobility, stickiness, throughput capabilities and just about anything else under the sun.  Heck, just today an article was published decrying the throughput ( WHO CARES? ) limitations of of the new MacBook Air (not iOS, but still Apple) was viral'd around the web. To check to see if the iPhone 5 matches the probing behavior of an Andoid device, I associated the iPhone to the office network on channel 36/+1 and started a capture on channel 44/+1.  Then I got up from my chair and started walking around while continuing to use the iPho

No bold type introducing today's post, as I'm going to keep things short. I was doing some work last week looking at Android devices (specifically, a Samsung Galaxy Tab 2) and I noticed some very heavy probing behavior.  We were checking out the device's behavior when it moves from AP to AP, so I set a capture for the target second AP.  I did the test (things went fine, but the WiFi Analyzer app in particular seems to really make Android devices stick to their currently associated BSS) and looked at the capture. Seeing a ton of Probe Requests from the Tablet was expected.  What wasn't expected was the Android tablet probing even while associated to the first AP.  Even when the received signal was strong (in the -50 to -63 dBm range), the Android was going off channel to probe and probe excessively. At this point I'm still trying to figure out if physical motion or an app (or lack thereof) caused the probing.  One thing I am pretty confident in saying already

A year ago yours truly wrote about the importance of device location when capturing Wi-Fi frames in a post titled, " Worthless Capture ".  Well, recently another Wi-Fi sniffing bugaboo has become more prevalent: devices that lack the physical capability to capture a  data frames. This whole problem really stems from 802.11n.  As many people (including the author) found out when the iPad was released in 2010, not all 802.11n devices have the same capabilities .  That is an annoyance to consumers, but it's downright dangerous to Wi-Fi professionals.  Most Wi-Fi networks require sniffing at some point (for surveying, for event preparation, for troubleshooting, etc.), but most Wi-Fi sniffing devices are incapable of sniffing high rate data frames. One more time: Most Wi-Fi sniffing devices are incapable of sniffing high rate data frames. The Linksys WUSB600N, which yours truly uses to sniff with WildPackets OmniPeek?   Only 2 radio chains (a radio chain is a transceive

Oh, those darned iPhones. Can't live with 'em, can't keep your job without 'em. The vagaries of iPhones and other station devices are the most difficult part of managing a WiFi network, but there are some things that can be done on the infrastructure to try to make your stations work better. One of those things is lowering your AP transmit power to a level that more closely matches your client station's transmit power.  My main man G.T. Hill (of Ruckus Wireless ) recently wrote a blog post discussing why this post is bullshit. Now I'm going to tell you why his blog post is bullshit. (sorry, G.T.) G.T.'s primary point is that is is borderline mentally handicapped (politically correct term) to turn your AP's power down. His theory is that even if your client stations transmit at low power levels, having a high AP power level at least allows the from-AP data rates to stay as high as possible. (G.T. goes on to add that most traffic is downstream, th