Sunday, 1 April 2018

Wireshark Capture Filters for 802.11


Generally, when performing over the air captures of WLAN traffic with Wireshark, the workflow adopted is as follows:

  • pick a specific channel where target traffic resides
  • switch the capture adapter to that channel
  • capture all 802.11 traffic over the air on that channel
Once a sample of traffic has been captured, the capture is stopped and analysis of the traffic using Wireshark's built-in display filters can begin.

In most situations, this is the best workflow to adopt. It ensures that all required frames are captured. Filtering wireless traffic while capturing frames is very problematic due to the complexity of 802.11 frame exchanges. It is very easy to miss parts of interactions between stations if you filter traffic as it is being captured.

However, there are a few edge cases where it may be useful to filter over-the-air frames at the point of capture. This will mean that only the filtered frames are available to display in Wireshark - all other frames are lost - but in some rare cases, this may be what you want.

Capture filters are added prior to commencing an over the air capture with Wireshark, as shown in the screen-shot below (see green highlighted text):



(Note that if the capture filter text is highlighted in red (rather than the green shown above), then there is an issue with your filter that needs fixing. You can access the screen display shown above via the Wireshark menu items: Capture > Options

The filter language used for capture filters is different from the built-in filter language with which most people are familiar. Capture filters in Wireshark use Berkeley Packet Filter (BPF) syntax. You can find out more about the syntax here: https://wiki.wireshark.org/CaptureFilters

I thought it might be useful to provide some examples of capture filters for 802.11 (Wi-Fi) traffic, as I didn't find many examples when Googling around.

Here are a few example filters:
  • wlan type mgt - capture only management frames
  • wlan type ctl - capture only control frames
  • wlan type data  - capture only data frames
  • wlan type mgt subtype beacon - capture only beacon frames
  • wlan type mgt subtype deauth - capture only deauth frames
  • wlan type mgt subtype prob-req - capture only probe requests
  • not wlan mgt - do not capture management frame (i.e. capture data & control frames)
  • not wlan mgt subtype beacon - capture all frames except beacon frames
  • wlan type mgt and (subtype beacon or subtype prob-req) - capture only beacon  and probe request frames 
  • wlan type mgt and (subtype deauth or subtype disassoc) - capture on deauthentication and disassocation frames
  • (wlan type data) or (wlan type ctl and (subtype rts or subtype cts)) - capture only data frames and RTS/CTS control frames

By studying the examples above,you will likely be able to craft your own capture filters. However, you will need to understand the various types of 802.11 frame available and their roles to be able to construct valid filters (maybe take a look at the CWNA or CWAP certification programs if you are not familiar with these)

The following extract from the PCAP filter manpage provides all of the filter options available to you:

type wlan_type subtype wlan_subtype
True if the IEEE 802.11 frame type matches the specified wlan_type and frame subtype matches the specified wlan_subtype.
If the specified wlan_type is mgt, then valid wlan_subtypes are: assoc-reqassoc-respreassoc-reqreassoc-respprobe-reqprobe-respbeaconatimdisassocauth and deauth.
If the specified wlan_type is ctl, then valid wlan_subtypes are: ps-pollrtsctsackcf-end and cf-end-ack.

If the specified wlan_type is data, then valid wlan_subtypes are: datadata-cf-ackdata-cf-polldata-cf-ack-pollnullcf-ackcf-pollcf-ack-pollqos-dataqos-data-cf-ackqos-data-cf-pollqos-data-cf-ack-pollqosqos-cf-poll and qos-cf-ack-poll.

Again, it is worth stressing that most of the time, capture filters are not what you want. It is very easy to miss some important interactions unless you capture all frames over the air (e.g. it is no good capturing just data frames and not seeing deauth frames that are kicking your client off the network).