How To

Options for wireless packet captures in Windows.

In Windows, you cannot effectively analyze wireless frames, because you are unable to put the wireless NIC in "RF Monitor Mode" - that is the mode in which the wireless NIC can see ALL 802.11 frames in the air, not just ones intended for itself.

Historically, it's been an expensive proposition. There are some great tools out there like OmniPeek (which I use), the gold standard for Windows packet analysis. And for years, AirPcap Nx was the main NIC folks used for pcap'ing WLANs with Wireshark. Unfortunately, both options are pricey. And the AirPcap NX is no longer manufactured. You’d be lucky to find a used one on eBay. Linux and MacOS have been the only ways to cheaply get access to RF Monitor mode without spendy software and hardware, like Omnipeek and the AirPcap Nx.

But, not everyone uses Linux, or macOS. Fortunately, and fairly recently, there are more and more ways to get RF Monitor mode in Windows. Here are some relatively inexpensive options (NOT an exhaustive list) to perform an RF Monitor Mode wireless packet capture in Windows using relatively inexpensive hardware. Here's a list from least to most expensive.

OR, you could just get a Mac and do it natively. 😉

If you'd like or learn more about understanfing wireless packet analysis I highly recommend the CWAP (Certified Wireless Analysis Professionals) Study Guide.

Use macOS Wireless Diagnostics to help you diagnose Wi-Fi issues.

We love our Macs. And this is just one of that MANY reasons why.

We use Apple's built-in wireless diagnostics often to troubleshoot, or get quick diagnostic information about a WLAN. Everything from performing a Wireless Scan, a packet capture, Monitoring the connection, and more:

Read Apple's article about using OS X's Wireless Diagnostics utility here. →

Leverage DHCP Fingerprinting for Role-Derivation

I was recently at a customer site upgrading an Aruba controller and doing some basic WLAN "best-practices". During this I was asked by the customer if there was a way to keep mobile devices off the corporate network. Without something like Aruba's ClearPass it's not easy to identify and restrict these devices.

My initial thought was with their current solution (Microsoft NPS) they couldn't easily keep 802.1X capable devices from connecting to the corporate WLAN if they had valid AD credentials. Then as I was working it occurred to me that Aruba mobility controllers use DHCP fingerprinting to profile devices. I could leverage that ability to help keep mobile devices off the corp WLAN. It's not 100% accurate (and should not be considered a complete security solution), and I let the customer know this, but it identifies iOS and Android devices pretty well.

Essentially, a DHCP fingerprint is an "almost" unique identifier for OSes, or device types. The DHCP protocol (RFC 2132) allows for information other than just IP requests and acknowledgments to be sent. These DHCP "options" includes vendor specific information which makes it possible to identify devices and even OSes by their unique signature. That being the case we can use the fact that ArubsOS supports this to create roles for these various devices and OSes and thus provide some level of management of these devices.

For example, we can create a rule that says if a device is an iPhone it will be placed in the "Mobile_Device" role. This role can then be restricted to Internet only with no access to internal resources, placed in another VLAN, or just sandboxed altogether. Not the best overall solution, but it works well enough.

Step one is to identify the DHCP fingerprint for that specfic device. There are several ways to do this and a simple Google search will give you plenty of options. You can also search for the specific fingerprint as well and hopefully someone will have posted it. In this post we'll just focus on using Aruba OS to find the fingerprint. Here is a list I've compiled so far from various blog-posts and from the Aruba Airheads community.

Android_device    3C64686370636420342E302E3135
Android 2.X           3c6468637063642034
Android 2.2           3701792103061c333a3b
Android 2.3.X        0c616E64726F69645F
Android 4.0.X        37012103060f1c333a3b
Android 4.0.X(2)    37012103061c333a3b
Blackberry 2          3C426C61636B4265727279
Blackberry(2)         370103060F775ffc2c2e2f
iOS Device             370103060F77FC
iPad                        37011c02030f06770c2c2f1a792a
OS X 10.6               370103060f775ffc2c2e2f
OS X 10.7               370103060f775ffc2c2e
Win Mobile            3c4d6963726f736f66742057696e646f77732043450
Win Mobile6          370103060f2c2e2f

How To Find A DHCP Fingerprint

Step One

Login to the CLI of your Aruba controller and go to enable mode. Once there go to configure mode and enable logging level debug for DHCP by entering:


(config)# logging level debugging network

Step Two

Connect your device to the appropriate WLAN and then use the show command to view all the recent network entries. Then search for the MAC address of the device and locate the DHCP option:

(config)#show log network all | include Options


You should then see a output like this:

Sep 7 12:54:43 :202536: <DBUG> |dhcpdwrap| |dhcp| Datapath vlan10: REQUEST b8:e8:56:xx:xx:xx Transaction ID:0xb78173e6 reqIP= Options 37:0103060f77fc 39:05dc 3d:01b8e856f1e09c 33:0076a700 0c:46697265666c79
Sep 7 12:55:15 :202536: <DBUG> |dhcpdwrap| |dhcp| Datapath vlan1: REQUEST 00:60:2e:xx:xx:xx Transaction ID:0x464bcafb reqIP= Options 3d:0100602e024a08 3c:756468637020302e392e392d707265 37:0103060c0f1c
Sep 7 12:57:20 :202536: <DBUG> |dhcpdwrap| |dhcp| Datapath vlan10: REQUEST b8:e8:56:xx:xx:xx Transaction ID:0xb78173ef reqIP= Options 37:0103060f77fc 39:05dc 3d:01b8e856f1e09c 33:0076a700 0c:46697265666c79

You're looking for options that start with 37, 0C, 32, or 33. These are hex for DHCP options 12, 55, 60, and 81. In the above example the fingerprint for my device is 37:0103060f77fc, an iPhone. So, what I would use is that value without the colon (:) - just 370103060f77fc. Now that we have found the DHCP fingerpring we can create our rules and start enforcing policy.

Create a User Role

A user role us just a set of policies for the user/device in that role. This role can simply be an "allow-all" policy that does not restrict access, or it can be very specific like only allowing DHCP, DNS, and http/hhtps to the Internet. Or, as stated previously, placing the device in a different VLAN. It can even just be a role that denies access altogether. Regardless, the role need to be created first so we can apply it in the User Rules for the devices later on. Since roles are pretty common usage in ArubaOS I'll just say create the roles you want how you want. You can call it "iPhones", or "MacBooks", or "Android", etc. If don't know how to create roles page 265 in the Aruba OS User Guide walks you step-by-step.

Create A User Rule for the DHCP Fingerprints

1. In the controller UI go to Security > Authentication > User Rules.

2. Click on "Add" to create a new User Rule. Give it a name like "Mobile_devices." You will be able to add multiple fingerprints in one rule so you don't have to create multiples if don't need to.
3. Now click on your newly created rule and then click "Add" to start adding your rules. Here's an example of adding iOS signature:

+ In this image the "set-type" is Role since we want a specific role to be assigned this device when it connects. 

+ "Rule Type" says we're looking at the DHCP options. 
+ "Condition" is what condition is met to trigger this rule -  so "equals" is what we want. 
+ "Value" is what te condition of "equals" will match. This will be your DHCP fingerprint.
+ "Role" is the role you created earlier.
+ And lastly the description of the this rule (i.e. iPhone, Android Tablet, AppleTV, etc.).

Finally, click "add" and you've created your first rule!

Apply the new User Rule

So, now we have the User Role that will be assigned to devices matching the DHCP fingerprints we have added in the User Rule. SO, to make the magic happen we need to apply the User Rule to the AAA profile assigned to the specific VAP (Virtual AP) that you want this rule to function on.

1. In the controller UI navigate to Configuration > Security > Authentication > AAA Profiles.
2. Click on the profile for the WLAN/SSID you want to apply the User Rules to.
3. On the right you should see an option called "User derivation rules". From the drop-down select the User Rule you created. Click "Apply" to save you changes. 

Now connect your fingerprinted device to the apprpraite SSID. If your device was recently connected it may get the same role it had before. This is because it has not yet timed out of the database. To insure that the device gets the correct role you should delete it from the database. The best way to do this is from the CLI. SSH into the controller, go to enable mode, and enter the following:

(Master-7010) #aaa user delete mac [device mac address]

Now you should reconnect and see that your device has been given the new mobile device role that you assigned in your User Rule for that specific devices DHCP fingerprint. The controller matched the DHCP fingerprtint of your device with the rule you created and assigned the appropriate User Role.

Now, as I said in the beginnig this isn't 100% fool-proof, but it catch most modern devices. It's already part of the OS and short of purchasing ClearPass (which if you're interested we'd love to talk to you about! :-) this is a great way to manage devices on your WLAN.