Capturing 802.11 management frames on Windows using Acrylic WiFi Pro

Studying for CWAP, I embarked on a mission to capture 802.11 management frames using my Windows laptop. For those with MacBooks that do this natively, read no further, just keep on perfecting that smug look of disdain with a slight hint of pity for the rest of us Microsoft peasants.

For those whose laptops aren’t fruit branded, but you still want to capture 802.11 frames in promiscuous mode, this is the post for you. Especially if you can’t quite justify the cost an AirPcap adapter for study purposes.

While researching alternatives to pricey AirPcap adapters, I came across this Acrylic WiFi Professional post on their option for an NDIS driver. This driver allows you to capture in promiscuous mode, so you can capture all that management frame goodness, but without the AirPcap adapter. I checked out the supported USB wireless options, ordered one off the list from Amazon (I picked the NETGEAR A6200), and downloaded a free trial of Acrylic WiFi Pro to get started.

The installation of Acrylic Pro is straightforward, as is turning on Monitor Mode when you know where to look. By default, Monitor Mode is turned off and the NDIS driver is not installed. Just click the menu in the right corner, and select Change to get to the Monitor Mode settings.

Select Monitor Mode On and select Install the NDIS driver. You’ll get a warning message that you might crash your system and you’ll need to acknowledge that you are completely okay with this*.

Once the driver is installed you can swap over to the Packet Viewer using the icon in the top tool bar or by clicking Packet Viewer from the menu. You will also see that you are in Monitor Mode and can select to change out of Monitor Mode if so desired.

While all of this is really super cool, I was extremely interested in capturing these frames inside of my most familiar tool of packet sniffing choice, Wireshark.

Unfortunately, I didn’t see the NDIS driver as an available capture interface when I launched the Wireshark application. This post by Acrylic reminded me why. I needed to launch Wireshark with Run As Administrator, even though I am a local administrator on the laptop**. Once I did this, I could select the Acrylic NDIS NETGEAR A6200 WiFi Adapter and start capturing wireless management frames.

I could also select the Wireless Toolbar in Wireshark and see that the NDIS driver emulating an AirPcap adapter.

Unfortunately, I still had one tiny problem at this point. Every time I launched the Wireshark application, my built-in wireless card immediately quit passing all traffic. Not exactly ideal for productivity.

Easy fix, though, if you encounter this issue. Head over to the settings for the Network Adapter, uncheck the Tarlogic NDIS Monitor Driver for the built-in adapter, and the problem is solved.

I would be remiss not to point out that there are limitations to this NDIS driver. For instance, there is no support for 40 or 80 MHz channels at this time. But for my CWAP study purposes, this is working quite well and saves me a bit of cash. Also, Ben Miller did a great write up on this very same subject, which, of course, I found just AFTER I went through this process and drafted this post. The universe has quite the sense of humor like that.

Published 2/7/2017

*Do this at your own risk, please don’t blame me for your system crash, there’s a good chance I’ll just point and laugh…

**If you need to know how to set a program to always run as administrator in Windows 10, look here.

Voice basics: troubleshooting a failed outbound fax

Faxing is a technology that instead of nuking it from orbit (the only way to be sure), we’ve propped it up and tried to make it part of the VoIP world, resulting in a whole lot of troubleshooting and whole lot of bang-head-here moments for voice engineers.

While time, variances in equipment, and sheer PTSD keep me from exploring all the ways in which faxing can ~~suck~~ go wrong, I thought I’d throw out a recent example of an all too common occurrence – proving your fax machine isn’t the (biggest) offender in an outbound communication failure.

Specifically, this example deals with an XMedius fax server, a Cisco voice gateway with PRI, and a who-knows-what fax endpoint on the other side. Your mileage in fax troubleshooting may and likely will vary, just keep that in mind and a drink at hand.

The first step in dealing with one of these reported issues (after cursing, of course) is to determine if it’s an isolated incident or possibly a dialing issue. Besides calling and confirming* a fax machine actually picks up, checking your inbound and outbound logs on the fax server can quickly quell those reports the server is down when someone really forgot to dial a 9 when sending the fax. Happens all the time.

In my case, I had plenty of inbound/outbound successes to determine this was an isolated case. I also had the packet capture feature of XMedius turned on.**

This feature is brilliant, truly not an understatement.

I opened the packet capture for one of the failed attempts, navigated to Telephony -> VoIP Calls -> and then selected Flow for my call. When you do this, there will be quite a bit of information presented in graph form.

You should be looking for a few basic things in particular:

Do you see the call ever connect?
Do you see the sender’s cng (calling tone) packet?
Do you see a DIS (Digital Identification Signal) from the remote endpoint?
Do you see the sender’s training message?
Do you see the remote endpoint’s CFR (confirmation to receive)?

In my flow graph of the not-so-happy fax, I notice that even though I’ve made contact with the (whiny) fax machine on the other side and negotiations have been successful – the remote endpoint never sends a CFR, therefore the server will not send the fax data.

The fax server tries again and again to elicit a response, but there’s only silence from the other side. I assume because the remote endpoint realized that for every successful fax, a puppy dies. Well, that’s the rumor I’ve heard (or started).

Here’s an excerpt from the flow graph, definite lack of CFR.

No CFR

Below is flow graph of a fax that the server sent successfully to another number. While there are differences, you can see that CFR goodness the flow graph above is missing.

After reviewing this information, I moved onto finding out if the voice gateway ever sees the CFR and maybe just forgets to send it along.

After working with TAC and doing a PCM capture on the gateway, I was able to confirm that the remote endpoint never sends the CFR, which meant I could declare with some amount of relative certainty that this was a whole lot of not-my-problem.***

TAC even provided me this handy-dandy flow graph built from the captures we took on the gateway, you can see that the fax server tries three times (TCF (9600)) to get the remote end to cough up a CFR, but no dice.

outbound fax flow

While this just scratches the surface, these basics, along with a formidable hammer, should get you started in your fax fighting mission. Just remember to really effectively troubleshoot a fax machine, it’s all in the swing…

Published 4/10/2015

*Do not skip this step. Never assume a user is asking you about problems with a working telephone number. Always test from outside your phone system to confirm that the phone number in question hasn’t been disconnected or written down wrong by the user. This will save you countless hours and possibly what’s left of your sanity.

**Check your XMedius Administrator’s guide or call their support for steps to turn on this feature, it’s a pretty straightforward process and well worth the time.

***Trust me there are no absolutes in fax, unless you’re talking about frustration, that part is guaranteed.

Runt Post: Big Tap Monitoring and its Wireshark goodness

Anyone reading my blog posts or tweets knows that I am huge fan of Wireshark and all its packet capturing greatness, so let me point you to this great Big Tap video from Networking Field Day 8 where Sunit Chauhan demonstrates how you can troubleshoot a client issue using Big Tap Monitoring Fabric, even generating an impromptu packet capture in the process. The ease of the process is beautiful, just beautiful.

Skip to the 13 min mark to start the troubleshooting fun. After that, you’ll want to watch those first 13 minutes to find out how the magic is done.

Big Switch Networks Big Tap Monitoring Fabric from Stephen Foskett on Vimeo.

Published: 10/3/2014

Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to this fantastic event and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.