sniffwifi

Just another WordPress.com site

Archive for the ‘Wireshark’ Category

Free Sniffing in Windows! (Kind Of)

with one comment

Nine months ago (bad way to start a blog post, I know) I wrote a blog about the future of WiFi sniffing.  In the comments section (perhaps the only worse thing for a blogger to say), someone mentioned a free, Windows-based application called Acrylic WiFi.   I briefly checked out the app and dismissed it as yet another Discovery utility disguised as a something more. 

Then I actually used Acrylic WiFi and…  it works!  It sniffs WiFi frames (sort of) and it does it for free (outside of the cost of an ordinary 802.11 USB adapter)!  This changes everything (kind of)!

For years, the method for free WiFi sniffing on a Mac has been simple.  Head down to the bottom of this post for a reminder.

Now, we can do similar things in Windows.  It’s not quite as simple and it’s not totally free, but it works (pretty much).

1. Download and install Acrylic WiFi Free, including Monitor Mode support (and, actually, if you can find an old download of Acrylic v1, then you’ll be able to save captured frames in a *.pcap file, just like you can in Mac OS X Wireless Diagnostics.  If you download Acrylic v2 [the current version], then you can’t).

2. Procure (see, I can use corporatey talk sometimes too) a USB adapter that allows monitor mode capture in Acrylic (I use the Netgear A6200, and if you use that link then you’ll be supporting this blog by giving me a kickback from Amazon).

3. Open Wireshark (and if you’re a Mac user running 64-bit Windows in Bootcamp or as a Virtual machine, you’ll have to Run as Administrator).

4. Select the Acrylic NDIS Netgear A6200 (or whichever model of USB adapter you procured) Adapter and click Start.

Bingo!  A real-life 802.11 Monitor Mode capture in Windows (just about), done for free!  (Actually, for the cost of an ordinary WiFi USB adapter, but still…)

And here’s a tip for enabling a channel scan by using Acrylic with Wireshark:

Normally, Wireshark only allows for monitor mode capture on a single channel.

Just look at that screenshot above.  No channel scanning option to be found.  

If you decide that you want to scan channels for whatever reason, all you have to do is let Acrylic control the capture.  Just open Acrylic (while keeping Wireshark open and capturing), click Monitor in the upper right until it says, Monitor: ON, and then click the channel number just to the left to choose which channels you want to scan.  See:

Fantastic.  We can not only do a (nearly) free monitor mode capture with channel scanning in Windows (more or less).

About that, “more or less” (and the “kind of” and “sort of” and all the rest)…

Monitor mode capture with an Acrylic driver is flawed.

Check out this little capture I did of my iPod Touch (the most underrated device in the history of WiFi site surveying, troubleshooting and analysis, by the way) streaming the 2015 Royal Rumble on WWE Network:

Specifically, check out the Rate column in that screen shot.  Every single cotton-pickin’ frame captured by my Netgear A6200 using the Acrylic WiFi driver shows the same rate: 0.0 Mbps.

(And just to show that it’s not a problem with my setup, here’s what it looks like when the Airpcap NX adapter does a monitor mode capture into Wireshark:

Notice that the rate of 58.5 Mbps comes through loud and clear.)

So, there you have it.  You can now do free sniffing in Windows, but there are still kinda/sorta limits to how useful it can be.

***

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

***

Free sniffing in Mac OS X:

1. Open Wireless Diagnostics (in Mac OS X 10.10 [Yosemite], holding down alt/option while clicking the WiFi Settings icon on the top menu bar reveals Wireless Diagnostics).

2. Open the Sniffer window (older versions of Mac OS X have different methods of sniffing, but a monitor mode capture has always been an option in Wireless/WiFi Diagnostics).

3. Choose your Channel and click Start.

4. When finished, click Stop, and then go to the Desktop to open the captured frames (in the form of a *.pcap file) in Wireshark.

***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Advertisements

Written by sniffwifi

January 27, 2015 at 7:33 pm

QoS the Packets of iPad (a poem)

leave a comment »

QoS the packets of iPadand 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”
And thus if your tool is a management GUI
You could end up wondering why WiFi is pooey
But a sniffer will show — be it angst or delight —
Whether your gear plays nice or girds for a fight

***

(iPhone: ‘This is a Video app.”)

 (AP: “You’ll get Best Effort and like it.”)

If you like my blog, you can support it by shopping through my Amazon link.  Same Amazon store and prices, but I get a kickback.  Thank you.

Written by sniffwifi

January 23, 2014 at 9:26 pm

802.11v: Keep Dreamin’ (in iPhones running iOS 7, at least)

with 3 comments

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) amendment was created to (quoting from the 802.11v Abstract), “provide WNM enhancements [blah, blah, blah] to effect a complete and coherent upper layer interface for MANAGING 802.11 DEVICES in wireless networks.”  “Managing 802.11 devices” is the key part there.  The hope was that with 802.11v, a WiFi admin would be able to pause his (or her) game of WoW, slowly turn 15 degrees to the right (so as to avoid rupturing a clavicle from sudden movement) and use his (or her) wireless network management system (WNMS) to manipulate smartphone/tablet/laptop/etc. associations to the various BSSs in his (or h… oh, you get the point) enterprise.  
***
I’ve often been asked the question, “why weren’t 802.11 WLANs designed to allow centralized client control in the first place?” just before a snack sized bag of Doritos gets emptied ass-over-tea-kettle into a network admin’s mouth.  Well, the answer is, “because the AP doesn’t know sh*t.”  APs are mounted above your ceiling (or below your ceiling or, if you’re really doing it right, on your walls).  There ain’t no clients above your ceiling (or below your ceiling or on your walls).  So having an AP that’s above the ceiling (meaning an AP that only really knows RF information about the area above the ceiling) make decisions for a client that’s on a desk or walking down a hallway is poor form.  You want the right RF information so that you (hopefully) get the right decision.  Only the client knows the RF information about its current location.
***
802.11v was supposed to be special because it (optionally) allows APs (or controllers or WNMS) to make decisions about client associations.  802.11v took RF information that the client sends to the AP as part of 802.11k radio resource measurement (RRM) and WiFi information that the client sends as (another optional) part of 802.11v and gives the WLAN infrastructure (APs, controller and WNMS) the ability to paint a picture of the client’s RF environment.  If the AP thinks that the client would be better off on another BSS (which likely would mean another channel), then the AP could use WNM to force the client/station to make that move.
The problem with all of this is that is was never going to happen.  (I use “was” instead of “is” to convey the notion that, not only is it unlikely that infrastructure-based association management will be adopted any time soon, but that it was never prudent to assume that makers of smartphones/tablets/laptops would ever cede control over associations to WLAN infrastructure vendors.)  The authors of 802.11v even ended up making infrastructure control over associations optional because they knew that device vendors wouldn’t adopt WNM otherwise.
Which brings us back to the iOS 7 iPhone.  iOS 7 iPhones do support 802.11v WNM.  You can see it in the Probe Request frames that iPhones send whenever they are unassociated to WiFi.  If you look in the frame body of a Probe Request and scroll down to the Extended Capabilities, you will see WNM information.  It’s tricky, because the WNM information is mixed in with information from other 802.11 amendments.  But if you look at this frame decode (from Wireshark, because I’m lazy and didn’t feel like booting into Windows), you’ll see it:
You see in octet 3 where it shows “Multiple BSSID”?  That’s WNM.  So is “SSID List” in octet 4 and “Geospatial Location” (should’ve been soldered as “America!” in the standard) in octet 2.  
And you know what you see for every single WNM capability seen in that iOS 7 iPhone decode, save one?  0.  “Not supported”.  Apple is giving WiFi admins The Heisman.  They are not allowing your WLAN infrastructure to have any sort of association control.  And what’s more, Apple is not even allowing its precious iOS 7 iPhone to even give the APs/controllers/WNMS any additional information.  (My guess on the reason is battery life, but with Apple who knows?  They’re the kind of company that will foster a pro-gay rights environment for years, champion the cause of gay marriage publicly, and then seemingly go out of their way to keep the fact that their CEO is gay under wraps.  They’re an odd bunch up there in Cupertino.)  In fact, the only part of 802.11v WNM that an iOS 7 iPhone does support is a part that could potentially harm the WLAN infrastructure: directed multicast service (DMS).  (DMS allows client/stations to request than an AP sends multicast traffic as a directed [unicast] frame.  This is probably supported because captive portals featuring web authentication are especially annoying when using Apple devices.  Apparently some guest WiFi services use multicast frames to check whether authenticated clients are still present.  Since many [most? all?] Apple devices sleep through multicast frames if no multicast-based app is running, the end result can be an iPhone/iPad/MacBook user having to re-authenticate to the stinky captive portal dozens of times per day.)
So, at least for now, the dream of centralized management of WiFi clients is dead.  802.11v WNM is approved.  It’s supported.  And all of the parts that would allow network admins to stay at their desks monitoring the fantasy football waiver wire while controlling client associations have been stripped out.  Client/stations continue to control associations and designing the RF environment for your clients’ behavior continues to be the way to get iPhones associated to the right BSS.
If you like my blog, you can support it by shopping through my Amazon link.  Same Amazon store and prices, but I get a kickback.  Thank you.

Written by sniffwifi

January 2, 2014 at 5:54 pm

Posted in 802.11v, iOS 7, iPhone, Wireshark, WNM

iPhone 5 Probes the Right Way, Too

with 2 comments

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 iPhone.

The results were this:

Notice that the Probe Request frames started coming out immediately when my phone began moving, but then stopped less than one second later.  Most likely what happened was that when I got up from the desk, the iPhone sensed movement and began probing for the next highest 40 MHz channel.  Then the phone probably went from channel to channel as it continued to probe.  All the while the phone continued to stay on channel 36/+1 as much as possible in order to keep communication with the network.
Of course it is hard to draw firm conclusions from a few minutes worth of Wireshark captures, but to these eyes it appears that Apple may be taking steps to get iOS devices in the good graces of WiFi admins and other professionals.  

Written by sniffwifi

June 24, 2013 at 11:13 pm

Mighty iPhone Power Ranges

with one comment

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, thus making it all the more important to maintain high from-AP data rates. I have found this to be incorrect, so double-sorry, G.T.)

I wanted to check out an example using my iPhone (which, from what I gather, transmits at 10 dBm) connecting to an AP in a small office (which probably transmits at 17 dBm or 18 dBm). I ran a Skype test call so that I would make sure that both the AP and the iPhone would transmit plenty of frames.

Just as G.T. hypothesized, the higher transmit power of the AP allows the AP to transmit at a high rate.  The small office AP was acting as an 802.11g AP (even though it’s probably an 802.11n AP configured to use TKIP encryption) and, sure enough, the small office AP used the highest possible rate (54 Mbps) for just about every transmitted frame:

Also as G.T. hypothesized, the rate for frames transmitted by the small office AP would likely have been lower if the AP’s power level were reduced to match the iPhone’s power level. We can deduce that from the fact that the iPhone was routinely transmitting frames at a lower rate (48 Mbps) than the AP:

As expected, G.T. is correct about the rates. If your primary goal is to have the highest possible rate for all frame transmissions on your WiFi network, chances are that setting your AP and station transmit power levels to the highest possible value will help you achieve that goal. 
The problem with this whole discussion about rates is that having high rates really should not be your primary goal. High rates are attractive because it’s fun to see a big number when you mouse over your system tray (or, for us Mac OS X users, when he hold the Alt key and click on the WiFi icon in the top menu bar), but for most enterprise WLANs high rates fall somewhere around fifth on the list of things to look for when evaluating whether the WLAN sucks or not. 
My criteria for not sucking:
  1. Drops/re-authentications are rare (meaning that every captive portal sucks)
  2. Roaming works for mobile devices
  3. Discovery traffic is minimal
  4. Retrys are low (indicating that whenever the wireless gets busy, it’ll still probably work)
  5. Rates are high
(Please notice that throughput/goodput, packet sizes and single station usage are absent from this list. One could write an entire blog post about how much time is wasted analyzing those numbers.)

High percentages of Retrys are more damaging than low rates (in most cases) because Retrys waste channel time. There is a finite amount of time available for data to get across each channel. When a Retry happens, the time for the failed frame was wasted because all stations and APs must stay quiet during each frame transmission. Low rates for data frames also waste time, but for most enterprises the budget is there to install plenty of APs so that a decent signal can be had anywhere.

Now take a look at the Retry numbers for the communication between my 10 dBm iPhone and the 17/18 dBm office AP (while also taking a look at how much extra time it takes to do menial tasks when you go cheap and use Wireshark instead of WildPackets OmniPeek or Fluke AirMagnet WiFi Analyzer):

Frames sent by the AP to the iPhone: 1650

Retry frames sent by the AP to the iPhone: 155 (9.4%)

Frames sent by the iPhone to the AP: 1973

Retry frames sent by the iPhone to the AP: 329 (16.7%)

Both 9.4% and 16.7% Retrys are bad numbers (though this was for a small office, where bad numbers are expected because of neighboring WiFi networks), but 16.7% is a helluva lot worse. About 1.77 times worse.

And why is it worse? Most likely because the AP transmit power is set too high. The iPhone has no idea what the AP transmit power level is, so when the iPhone receives a frame at a good signal strength, the iPhone assumes that a high rate can be used when the iPhone transmits. The iPhone doesn’t realize that its transmitted frames go out about 7 or 8 dB lower than the AP’s frames. The end result is the iPhone using rates that are too high (and if I were able to show you the entire capture of the iPhone’s transmitted frames, you would see many failed attempts at 54 Mbps), causing lots of Retrys on the channel and thus, SLOWING THE ENTIRE CHANNEL DOWN.

(I cannot make the point strongly enough that RETRYS SLOW THE ENTIRE CHANNEL DOWN. A massive Retry percentage like 16.7% makes my iPhone slower, every other device on my iPhone’s network slower, every other device on any other network the AP is offering slower and every other device on any network that any AP on my channel slower. Retrys are a bad, people. And the only way to get an accurate gauge of Retrys is by sniffing WiFi. It’s why I cared enough about sniffing to start a free, advertising-bereft blog.)

The bottom line here is that even though my friend G.T. has phenomenal taste in fast food, a lovely wife/kids/family and a solid history of only spending money on things that will help his career or increase in value (sorry, G.T., I couldn’t resist), I believe he is wrong here. I have found that designing a WiFi network with AP power levels lower to match station power levels works best, and my experience gathering statistics from real-world WiFi sniffing supports that.

Written by sniffwifi

June 27, 2012 at 5:07 pm