Changing Wireshark Link-layer Header settings on Mac OS

This is one of those quick posts aiming to save me and (maybe you) some time the next time I forget this.

On my Mac, I use Wireshark primarily to capture Wi-Fi traffic, in monitor mode. I want to see the Radiotap and 802.11 headers. Usually I leave Wireshark set this way.

On occasion, I actually use Wireshark to inspect higher level traffic – I want to see the IP addresses and TCP/UDP ports etc. I might be troubleshooting an issue and am using my Mac as the client trying to recreate the issue – so I don’t need monitor mode for that. Simple enough – turn it off in the interface settings (Find this button on the Main toolbar Wi-Fi. en0 Wireshark, Today at 9.20.38 PM  to access the menu, then scroll to the right to find the Monitor mode drop down and make sure your Wi-Fi interface has this disabled):

Wireshark · Capture Interfaces Wireshark, Today at 9.30.03 PM

Then just set the Link-layer header back to Ethernet, just like your other interfaces:

Wireshark · Capture Interfaces Wireshark, Today at 9.30.57 PM

Except “Ethernet” isn’t an option. I could’ve sworn that’s what it is set to by default after install…

I can’t believe this still trips me up every few months. I spent half an hour the other day scratching my head, when the trick is simply to restart Wireshark. Close it entirely, reopen it and voila:

Wireshark · Capture Interfaces Wireshark, Today at 9.34.30 PM

Ethernet is back! Also, the 802.11 options have disappeared because we’re no longer in monitor mode. Now I can see Ethernet, IP, and TCP/UDP headers again:

Wi-Fi. en0 Wireshark, Today at 9.35.58 PM

In comparison to capturing 802.11 frames in monitor mode:

Wi-Fi. en0 Wireshark, Today at 9.38.08 PM

I keep forgetting the need to restart Wireshark for the Link-layer options to change #facepalm.

Note: you also need to restart Wireshark after enabling monitor mode before the 802.11 options will show up in the Link-layer header drop down option.

Or maybe it’s just me. I’m confident that I’ll still forget all about this post next time I try to show a University Computer Engineering class how many packets it takes to load the Facebook home page.

It was 781 (including DNS lookups and a couple of retransmitted frames), in case you’re wondering…

PING! Not always what you think! – Meraki Wireless troubleshooting

I’m quite fond of the Meraki dashboard. I’ve seen firsthand how it can enable lean and low-skilled IT departments to manage more of their own networks themselves. The dashboard GUI makes it easy to find status and troubleshoot at a basic level, but it’s still important to actually understand what is going on under the hood.

Here’s an example. If you’ve ever seen the Meraki dashboard, you’ve probably seen the Ping tool on every client status page. Here, a Meraki AP is successfully Ping-ing my MacBook Pro:

pign-success-invalid-ip

Pretty straightforward. Ping the client, client responds, client is online and working, right?

If you have a Meraki Security Appliance, you may stumble across this little note on the Addressing & VLANs page:

ping-is-arp

Wait… Ping is based on ARP? What happened to ICMP?

We may have jumped to conclusions here. As it turns out, Meraki is not using ICMP like most of us would assume. Here’s an example of a few PCAP frames of that same Meraki AP ARP-Ping-ing my MacBook Pro:

directed-arp

Notice this is a directed-ARP; the Meraki AP (MAC 13:da:90) is sending an ARP request to the MBP (MAC 91:75:d8) rather than sending a broadcast. That is, the Meraki AP already knows the MBPs MAC address. But the ARP response tells the Meraki AP that the MBP is alive, and online – just like an ICMP Ping.

This brings about an interesting question. We network engineers often use Ping as a way to confirm that the network is working. A successful Ping means that routing, IP addressing and the physical path are all functioning correctly at layer 3. But if we’re doing a Ping at layer 2 with ARP – would we be wrongly assuming all is well when we get a response, just like with ICMP?

There is definitely some potential to make incorrect assumptions here. In fact, even though that screenshot above of the Meraki AP Ping-ing my MBP has a loss of 0%, at the time, my MBP had an incorrect IP address and was not Ping-able by other devices in the network (well, via ICMP at least). Here’s the PCAP’d ARP frames from the same time as that Ping output:

directed-arp-wrong-ip

Almost identical, except that both the ARP request and response are from 10.11.3.1, when the subnet is actually 10.11.30.0/24. However, the client is still responding, albeit at layer 2, and that’s good enough for the Meraki AP.

Now, I do think this is one of those things where the vendor has made an odd decision to label this as a Ping without being clear about what is actually being done, but it is after all our responsibility as the network engineer to know what we’re looking at. There are similar examples where traceroute can use UDP or ICMP, depending on the OS, and now you know that sometimes Ping is ARP instead of ICMP.

Here’s the relevant documentation:

Meraki Ping Tool

When a 6 means 5 – Cisco WLAN QoS

Making sure QoS does its job as expected includes ensuring that the WLC is properly configured to translate between WMM markings on the WLAN and CoS/DSCP markings on the LAN. Many of us know that the WLC uses the Platinum QoS profile which is associated to the Access Category (AC) AC_VO which uses a user priority (UP) marking of 6. On the wired LAN, we tend to use a layer 2 CoS (or 802.1P) marking of 5, which is also usually mapped to a layer 3 DSCP marking of 46, or EF. So we know that a WLC or AP should map the UP 6 to a CoS 5 when bridging frames between the WLAN and LAN.

I’ve been reviewing some past projects, and I was reminded that Cisco documentation used to recommend that we map UP 6 to CoS 6. This didn’t make a lot of sense to me at the time, especially when I wanted the voice traffic to end up with a CoS 5 or DSCP EF on the wired LAN. Here is a screenshot I had taken from the Cisco configuration guide at the time:

Cisco Unified Wireless QoS Tech Note - Cisco Safari, Today at 8.28.19 PM

Sometimes mistakes make their way into documentation, so at the time I decided I had better test to see what the WLC would do with these settings. I set up packet captures on the wired switch ports and used a Cisco 7925 handset to get WLAN captures. With the QoS profile mapping set according to the screenshot above, here is what happened:

  • The 7925 marked the voice payload frame with UP 6 at L2, and DSCP EF at L3
  • From AP to WLC, the CAPWAP encapsulated frame was marked with DSCP EF
    • APs were on access ports, so no L2 CoS markings
  • When the WLC placed the packet on the wired LAN as an 802.3 frame, the markings were L2 CoS 5 and L3 DSCP EF

Wait – didn’t we map the Platinum (UP 6) profile to CoS 6? Even better, if we mapped the profile to Cos 5, the result was… exactly the same!

Turns out Cisco’s was saying one thing and doing another. Here’s a recent tech-note where they come clean:

Cisco Unified Wireless QoS Tech Note - Cisco Safari, Today at 8.58.42 PM
source

 

 

I knew I remembered this from somewhere! What a odd behaviour. Note that the all that has changed is the default setting and thus the recommendation – we should map WMM 6 to CoS 5. The behaviour hasn’t changed and if you map to CoS 6, well then Cisco still goes ahead and spits out a 5 anyhow.

And frankly, that’s the right choice in my opinion.

Airtool – the Wireshark Sidekick

There’s one more piece to the puzzle to make monitor mode captures on OS X really functional – Airtool is a free download from Adrian Granados. Do yourself a favor, take a short detour to his site here and check out all of his apps. Wifi Signal and Wifi Explorer are both well worth the small cost and do a great job at optimizing your access to the wifi info hitting your machine.

But back to Airtool – free download. Airtool sits in your menu bar and gives you quick draw access to capture settings. Take a look:

Airtool Menu
Airtool can change the channel in a live capture via the Channel menu

 

 

Channel Change!
Channel change mid-capture. That’s how we roll.

Airtool can start it’s own captures and then open them in Wireshark for you when stopped. Basically, Airtool is a better interface to the OS X wireless diagnostics capture utility.

Better yet – you can have Airtool disconnect from the current WLAN for you. OS X doesn’t do this well on it’s own (option + click on the wifi icon for the option, but it will usually just reconnect).

 

You’ll also notice that you can set the capture channel width – dependent of course on your internal NIC’s capabilities.

 

The preferences menu lets you make some tweaks to the status icon, set the capture file location. With Airtool and Wireshark on OS X, you’ve got all you need to do 0-80 (MHz) in under 10 seconds!

 

 

 

Wi-Fi Channels in Wireshark

So we’ve got our easy monitor mode wireless captures in OS X (thank you built-in monitor mode!), now let’s tweak Wireshark to be a little more useful.

The radiotap header tells us some wireless specific info that might be useful to see in the main packet list, including the channel or frequency that the packet was captured on, but Wireshark doesnt show this in the packet list by default (maybe because wireless captures are for REAL experts 😎):

Radiotap Header

Let’s edit the displayed columns: Right-click on any of the column headers that you already see, like the Time or Protocol columns, and choose “Column Preferences”.

Column Prefs

Alternatively, The “Edit” menu and then “Preferences” > “Columns”.

Click the + button to add a new column, which will show up at the bottom of the table. Click the “Title” field and type in whatever you want the column header to be called (like “Frequency”!). Then click the “Type” field and set it to “Frequency/Channel”:

Add Column

Lastly, drag the new row up to fit it in where you want to see it. Here I’ve put it in between the Protocol and Length columns.

You can add and remove more columns this way – if you look you’ll also note that you can add columns for the 802.11 RSSI and TX Rate values from the radio tap header:

80211 Columns

Note that Wireshark displays the “Frequency/Channel” Column as the Frequency, but the channel is also listed in the radiotap header field in the packet details view. The channel is also available in the 802.11 Radio information:

80211 Radio info

We can also create a column based on this field. Right click on the line and select “Apply as  Column”:

Channel Apply Column

Then go back to your column preferences to see what Wireshark did for you:

custom channel column

We can use just about any field as a column with this method – just let Wireshark find the field ID for you!

Now we can filter and re-order our packets based on the new columns. That’s better!

 

Quick, Live Monitor Mode Wifi Captures on OS X

Unlike Windows, OS X offers the ability to put the wifi NIC into monitor mode without any special drivers, meaning we can actually capture wifi traffic in the air, even if it isn’t specifically destined for our NIC. All we need is Wireshark.

Open the capture interfaces options dialog (look for the gear icon on the toolbar), and make sure to set monitor mode to “enabled” for the Wi-Fi NIC (highlighted below, labeled as “Wi-Fi: en0”). We’ll also want the Link-layer header to be set to “802.11 plus radiotap header” (mine was already set to that option):

Wireshark · Capture Interfaces Wireshark, Today at 10.09.20 AM

Then click the “Start” button on the bottom of the dialog window to start capturing!

I find it helpful to NOT use Wireshark in full screen mode so that I can see the top menu bar at the same time as the Wireshark Start/Stop controls. When in monitor mode, the Wi-Fi icon in the menu bar changes to look like an eyeball overlayed on the typical icon (green highlight mine):

Capturing from Wi-Fi. en0 Wireshark, Today at 10.18.00 AM

That’s it! We should see beacons, probes and other frames not addressed to our NIC now.

In next posts I’ll note how to setup wireshark to show the channel/frequency and talk about using Airtool to change channels.

Side note: Credit to Tom LaBaude on Twitter for bringing this little Wireshark bug to my attention when capturing. Here’s the workaround.