Sniff Wi-Fi

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

802.11ac: A Survival Guide  is a recently published handbook about 802.11ac.  The author is Matthew Gast, a very knowledgeable WiFi guy who follows the  IEEE 802.11 Working Group closely.  I recommend the book if you work in WiFi.  It is informative.  There is great attention to detail.  All areas of the subject are covered.  But  I was left uninspired.  And my uninspiration (is that a word?) was the result of the book being short on something that I always hope to find in any technical writing: the Why. In some ways yours truly is the target audience for the book and in some ways I'm not.  I need to know the intricate details of how WiFi works.  (Point)  I already knew most of the tweaks that 802.11ac is making to 802.11n.  (Counterpoint) The physical layer is the most important part of 802.11ac, and that is where this book wins.  For example, before I read the book I was unaware that 802.11ac allows devices with different channel bonding capabilities can access a wider chann

In my last (real) post, I detailed how I used WildPackets OmniPeek to solve an iPhone 5 QoS problem.  But what about AirMagnet WiFi Analyzer?  I am a fan of both of those fine WiFi sniffers, so I figure it's a good idea to show you how QoS can be analyzed with Fluke Networks' signature WiFi protocol analyzer. WildPackets OmniPeek is more of a hardcore protocol analyzer than AirMagnet WiFi Analyzer is.  If you're going to be doing the type of sniffing I detailed in the last blog post , you will have an easier go of it with WildPackets' product.  But AirMagnet is popular and both tools are expensive.  So if you happen to be a gal (or guy) who needs to troubleshoot WiFi voice or video and you have AirMagnet, this brief tutorial should help. To begin analyzing QoS, one must first capture on the VoFi devices channel.  In my case I associated my iPhone 5 to a network with the SSID of "R&T".  Then I looked at the Start screen in AirMagnet: The "R&a

My love for WildPackets OmniPeek may be one of the few things in technology that exceeds my love for the iPhone... Now that I've run off 20% of my audience, let's talk about how the former can be used to figure out if the latter is causing a problem. I have a lot of enemies in life, and I'm proud of that.  In my opinion, part of being an adult is recognizing who your enemies are.  UCLA football players are my enemy when they play college football.  Drivers who text while stopped at green lights are my enemy when I am running late.  (No comments from the peanut gallery on that one, GT Hill .)  And deductive reasoning is often my enemy when troubleshooting. Deductive reasoning is oh so tantalizing.  It's simple math; A + B = C.  The WLAN works (C) when VoFi handsets (B) connect to my APs (A).  If I switch out the VoFi handsets for SIP-based iPhones (thus changing the value of B) and the WLAN stops working, then the iPhones must be at fault.  Right?  Wrong.

I am working on an online video project, so I want to test out some videos.  Here's a two minute video on capturing WiFi in Mac OS X.

I am going to try a Reddit AMA. http://www.reddit.com/r/IAmA/comments/1oguh2/im_a_wifi_expert_ask_me_anything/

It's Columbus Day!  A holiday that many of us heard of, a few of us object to and some of us don't get the day off for.  Let's call it a half-holiday. Yours truly is going to celebrate the day by celebrating one of my favorite sniffers, Fluke AirMagnet WiFi Analyzer.  Due to it being half-holiday, this will be a half-efforted blog post.  So no links and no graphics.  Just a little talk about my favorite part of that fine sniffer. AirMagnet WiFi Analyzer from Fluke Networks has been around for a long, long time (at least in WiFi years) and it continues to be one of the top WiFi sniffing options available.  I probably like WildPackets OmniPeek a little bit more because of its ease in manipulating frame traces, but AirMagnet (as I'll call Fluke AirMagnet WiFi Analyzer from here on out) has long been the best option for solving the vast majority of in-the-field WiFi problems. Last week I got to introduce AirMagnet to a few folks and it struck me that even though it i

It's a rough world out there, folks.  The economy stinks (or, is great if you live in western North Dakota), finding love is harder than ever (or, easier than ever if you use online dating) and WiFi bandwidth is scarce (or, plentiful if you use the 5 GHz band).  Into this quagmire wades the Google Chromecast.  A cheap ($35 USD), little (about the size of an e-cigarette case) gadget that allows you to mirror your smartphone/tablet/computer screen to your television.  If you want to feel like a member of the 1% (at least, the top 1% of WiFi spectrum consumers), this is the gadget for you. Reviews, tutorials and takes on Google's Chromecast are plentiful, so let's skip that.  On this blog we don't care whether people like the gadget.  We care about what the gadget does to the WiFi.  Does it suck up bandwidth?  Is it chatty during down times?  Does it interfere with existing networks? Let's take the first question last ( Charles Van Doren voice).  The Chromecast w

The iPhone 5 is a chatty device.  How chatty?  I checked, and it is chattier than I thought. Yours truly has done more WiFi sniffing of iPhones than yours truly cares to recount.  What has always stood out about these captures is the amount of chatter than an iPhone seems to engage in. I did a little test of my unlocked iPhone 5 to see exactly how chatty it was.  The test involved me turning on the phone's screen, spending a second looking at iMessage (which happened to be the last app I was on when the screen was turned off), pressing the Home button, opening the Twitter app (because, after all, if you're not on Twitter these days then you're not wasting your time properly) and refreshing my Twitter feed. The test took about fifteen seconds.  My capture saw WiFi frames going to or from my phone for about 17.64 seconds (rounded up to 18 for the purposes of a catchier blog post title).  Here is what it looked like: The good news is that my phone was using high r

Fear not your sniffers, dear WiFi folk.  For they are your path to the truth. I had a conference call today and the topic of carrier devices (smartphones, 3G/4G enabled tablets, etc.) on Wi-Fi networks came up.  The person on the other end needed to make sure that his WiFi devices were optimized for a variety of different WLAN infrastructures. My first reaction (as is my first reaction to most WiFi related topics) was to sniff.  First set up the infrastructure.  Then use the device (which could mean connecting, roaming or running an app).  Then sniff what's happening.   His reaction to my sniffing idea was pretty negative.  Their testing procedures are basically trial & error.  Set up the WLAN, then connect the device and then document what the user experience is.  If the user experience stinks, then make a change.  He was a sniffophobe. I get why people are sniffophobes.  WiFi sniffers can be expensive and difficult to learn.  The idea that you're going to

A bunch of WiFi vendors made presentations at the Wireless Field Day events a couple of weeks ago, and the one that piqued my interest the most (at least in a positive way) was WildPackets'.  The WildPackets OmniPeek software can now sniff 802.11ac traffic, with a catch.  The catch?  It only sniffs single streams 802.11ac traffic.  Is that a useful thing? First things, first: In order to sniff 802.11ac traffic, you need a AE6000 (Linksys Wireless Mini USB Adapter AC 580 Dual Band)  adapter.  (And if you decide to buy one and want to support this blog, you can use that link to Amazon.) The AE6000 adapter is a single stream 802.11ac adapter with a Ralink chipset.  WildPackets is developing a driver for the Ralink chipset and demonstrated the AE6000 in action.  The expectation is that it will be a month or two before the OmniPeek drivers for the AE6000 actually get released, but I bought one so that I'm ready. Being able to sniff 802.11ac traffic may be great, but the eve

WildPackets has a sizable discount for OmniPeek Professional right now if you bundle it with three OmniWiFi 802.11a/b/g/n 3-stream USB adapters.   WildPackets OmniPeek has long been my favorite WiFi sniffer, and the OmniWiFi USB adapter is currently my favorite capture device.  So getting a package of OmniPeek Pro with three OmniWiFi adapters at a $900 discount would seem to be an awesome deal, right?  Sort of. There are several versions of WildPackets OmniPeek , and for the most part the more expensive versions add features that are far more useful for wired sniffing than for wireless sniffing.  One look at the OmniPeek comparison chart reveals that the Compass screen and roaming testing are the only features that could possibly maybe justify a WiFi person spending $3,000 (discounted to $2,400 as part of the deal referenced above) on OmniPeek Pro rather than $1,200 on OmniPeek Basic. Compass is nice , and if you have a relatively large budget for WiFi sniffing software, then

The 802.11v amendment has been voted, stamped and added.  It is part of the 802.11 standard.  We still are unsure if we'll ever see it, but if we do it could ease some concerns about high-density WiFi. Wireless Network Management is its name, and not being adopted is 802.11v's game. Wireless network management (WNM) is an addition to the 802.11 standard that puts more control in the hands of admins.  Today, the client/station controls everything: roaming, load balancing and congestion avoidance included.  WNM is designed to put that stuff in the hands of the infrastructure (APs, controllers and management software). Companies that sell client/stations have (predictably?) declined to adopt WNM thus far.  That means that admins will continue to have to wait for the ultimate careful-what-you-wish for WiFi technology. There is, however, one part of WNM that is separate from the move to infrastructure control: Multiple BSSID Beacons.  APs have supported multiple BSSIDs for

Today it was announced that 7 Signal  would be a first time presenter at Wireless Field Day in August.  7 Signal offers a product that uses distributed sensors that analyze a WLAN. Wait a moment.  This sounds familiar... It was a mere fifteen months ago that yours truly spouted a  negative opinion of distributed sensors for WLAN analysis and troubleshooting.  To be precise, distributed sensors were accused to producing a worthless capture. A company like 7 Signal, then, offers both good news and bad news. The Good: People are starting to care more about WiFi sniffing and analysis.  A company like 7 Signal can only exist if networking folks appreciate the value of seeing what it happening in the air. The Bad: Distributed sensors produce worthless captures.  Does it matter if a 7 Signal sensor can connect if an iPad cannot?  Does it matter if good channel quality is seen at the ceiling (where the Sapphire Eye sensors are supposed to be mounted) if channel quality is bad at a

As long time readers of this blog might know, WildPackets OmniPeek has been my favorite WiFi sniffer for nearly a decade.  Then I found out about WildPackets' OmniWiFi 3-stream 802.11n USB adapter and I fell even more in love.  Now I learn that OmniPeek 7.5 has added wireless features to the Compass screen.  A good product has been made better (though time will tell if it lasts). First, OmniWiFi: The fact that different 802.11n devices have different capabilities is one of those things that sometimes flies under the radar.  The standard may say 600 Mbps, but just on the Apple website one can buy 802.11n devices with maximum rates of 65 Mbps (iPhone 4S), 150 Mbps (iPad Mini), 300 Mbps (Macbook Air 2012) and 450 Mbps (Macbook Pro 2012). 450 Mbps WiFi devices are the ones that give WiFi pros trouble because so many sniffing tools fail to capture 450 Mbps traffic.  The popular (at least with Wireshark devotees) AirPcap NX from Riverbed, the beloved (at least by yours truly) D-Lin

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

When we last left off, yours truly had noticed that an Android tablet was probing for Wi-Fi networks even when associated.  This behavior would have been unusual, as consumer-grade Wi-Fi devices historically would probe when unassociated and stop probing once a connection is made.  After a little bit more investigation, it appears there was an extenuating circumstance that was causing all of the extra probing. I wondered if the Android tablet I have (Samsung Galaxy Tab 2.0 with 65 Mbps 802.11b/g/n WiFi) might have its probing behavior affected by movement, and sure enough it does. I'll try to amend this blog post later to add screenshots of my captures, but for now here is a summary of what I saw: I associated my Galaxy Tab to a WLAN that is on channel 1.  Then I captured on channel 11.  My hypothesis is that an associated device should stop probing on other channels as long as the signal is solid. Sure enough, once I was associated on channel 1, I stopped seeing Probe Req

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

Happy (belated) Cinco de Mayo!  In honor of Mexico (whose El Tri I actually like a heck of a lot less than Les Bleus ), today's discussion of Guerra de Conduccíon has a Spanish language title.   As noted by noted sarcastor Keith R. "The R Stands for Reassociation" Parsons , in some ways wardriving is a topic whose time has passed.  We've known about it for years.  Wardriving tells hackers where your network is.  Most WiFi networks are encrypted.  What else is there?  Hackers can try to connect, but if you use a long WPA2 Personal passphrase , they won't be able to.  Hackers can try to sniff, but if you're using WPA2 Enterprise, then decryption of data frames is impossible (as far as us non-NSA employees know). But imagine you are an NSA employee.  Or the CEO of a noted defense contractor .  Or holder of some other high-profile job where the nation's prosperity is dependent on your secrecy (like USC's head football coach).  Then if a hack

Ahh, the good ol' days.  The days when USC was beating UCLA by 50 points, AirTran was flying nonstops from LAX to Milwaukee and WiFi sniffing folks only had to carry one USB card for 802.11 protocol analysis.  Those days are gone, my friends.  It's time to update which cards we need for which applications. December of 2011 was a time yours truly looks back on with fond memories for the reasons cited above.  In the wireless world, the good news was that WildPackets OmniPeek had begun supporting monitor mode capture from Atheros-based 802.11a/b/g/n chipsets, thus allowing one USB adapter to be used for any good WiFi sniffing app. Things change, and when WLAN infrastructure vendors began selling APs that support three-stream spatial multiplexing (thus rendering high rate data frames un-sniffable to the D-Link DWA-160 802.11a/b/g/n USB adapter), the handwriting was on the wall.  The halcyon days of only needing one USB adapter for wireless protocol analysis were numbered.  Fo

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

Ahh, mobility.  The bane of my (and many others') wireless humanity.  Wherefore art thou be so fickle?  Different devices roam differently.  Different apps make the same device roam differently.  And sometimes it seems that the same device and same app will roam differently depending on the situation.  So what can we do about it?  And, perhaps more importantly, how can a WiFi sniffer help? Let's face it, folks: nomadic WiFi is easy (comparatively).  At a university, you have students that want WiFi for their iPads in dorms, classrooms, labs, the basketball arena and at lunch.  But rarely in between.  A student using an iPad nomadically is just plain easier to support than a doctor who wants to pull up an X-Ray while she's moving or a retail manager that needs to see a picture from the Band of Outsiders fall collection while she walks over from the jewelry section. Compounding the mobility problem is that the iPad may not be your only device.  There's an old say

Sometimes I dream That he is me You've got to see that's how I dream to be The dream I riff, the dream I sniff Like Nate I want to be like Nate (Silver) Much has been made of the increased emphasis on statistical analysis, especially in the wake of New York Times blogger Nate Silver correctly predicting the electoral results for all 50 states in the recent United States presidential election.  Can analytics be applied to WLANs?  Of course they can.  It's just a matter of sniffing the right stuff. There are a lot of bad WiFi networks out there. There.  I said it.  It's out there and I can't take it back.  I see a lot of Wi-Fi in my travels.  Almost all of it could be improved upon and much of it seems like it was installed by folks with little understanding of how 802.11 networks work. So, what do we do to fix it? We can have best practices.  We can finally ditch automatic RF controls.  (Please, people.  If you haven't head yet, you want to set