Capturing Wireless Traffic from a Client Machine
Wireless packet captures are incredibly useful while troubleshooting specific events on a WLAN. The most common use is to see all communication (data, management and control frames) between a station (STA) and an access point (AP).
In order to do this without using the dedicated hardware, a Mac or a PC using Linux is needed.
If you don't have either a Macbook or Linux machine available, but you do have more Meraki APs in the network, try to collect wireless captures with the following method instead: Collect wireless captures when only Meraki Access Points are available.
Viewing wireless traffic is a two step process:
- Put the wireless adapter in monitor/promiscuous mode
- View the traffic using Wireshark in Monitor Mode
NOTE:
- When capturing traffic in the 5GHz band, always configure the AP to use a 20MHz channel width.
- When capturing wireless traffic on an SSID with encryption enabled, such as WPA2-PSK, ensure that the monitor mode capture is started before associating the client to the SSID so that the client traffic can be properly decrypted for later examination of the captures.
- When possible, create an Open test SSID to simplify the analysis of the capture.
Learn more with these free online training courses on the Meraki Learning Hub:
Monitoring on macOS
Monitoring on Macs running Sierra and High Sierra (10.12.x and 10.13.x)
Make sure you are not connected to any networks (including wired.)
Hold the Option key and click on the Wireless icon in the upper right. By holding the Option key, it will show a hidden option.
Choose "Open Wireless Diagnostics…”
Once it opens, go to the upper left under the “Window” section and choose “Sniffer”
Pick the appropriate Channel and Channel width to capture. This example shows an example of capturing on 5ghz – Channel 56 with a channel width of 80 Mhz.
Note: It is recommended to use 20 MHz to capture all the traffic from the AP to avoid any frame drops due to channel bonding.
Once you have set your channel and width, click “Start.” Note the directory that it will put the capture in. (/var/tmp)
Stop the capture once you have captured the event.
To navigate to the folder, switch to Finder. Then select Go at the top, and then “Go to folder…”
Fill in the folder /var/tmp and click “Go”
In the folder you’ll find your Monitor mode Capture
Monitoring on Macs running Yosemite (10.10.x)
Open the Wireless Diagnostics program from spotlight (Command + Spacebar):
When at the Introduction page, press Command + 6 to open the Sniffer:
Note: On 10.9 Mavericks, use Command + 2, then go to the Frame Capture tab.
Pick the Channel and channel Width, and press Start. This should match the channel currently in use by the client/AP that is to be monitored.
Ensure your AP is using 20 MHz channel width and select 20 MHz Width on the Sniffer menu too. Using a longer channel width can result in incomplete data.
During the capture you’ll see the eye icon over the wireless monitor indicating that the interface is in Monitor Mode:
This capture can be viewed live from Wireshark running in Monitor Mode (instructions found at the bottom of the article). Traffic collected will also will be automatically saved to a temporary .wcap file on the desktop. To open this capture in Wireshark, simple change the suffix from .wcap to .pcap and open from Wireshark.
To end the capture, simply click the Stop button.
Monitoring on Linux
- Install aircrack-ng. Once installed, this package should provide airmon-ng and airodump-ng. If you are using Kali Linux, aircrack-ng is probably already installed.
- Find your wireless interface(s) by running airmon-ng without any arguments. Other ways to find interfaces:
- Use ip link or iw dev on modern Linux distributions.
- Use iwconfig if it is an older distribution.
Starting Monitor Mode
To put your interface into monitor mode, follow these steps and examples below:
- Enter the command airmon-ng start [interface] [channel].
- Change the [interface] value to match the image above.
- Change the [channel] value to the channel you want to sniff traffic on.
- If any process needs to be killed, airmon-ng should alert you to it. Follow the instructions pictured below to stop monitor mode.
- Run airmon-ng check kill, and attempt to start monitor mode again.
- You can alternatively kill individual process via their Process Identifier (PID) with kill [PID]. The channel argument is optional, but it can help ensure you sniff on the correct channel to begin with.
- Note that when enabling monitor mode, a new interface is created in place of the original one specified with "-mon" appended to it.
- If airmon-ng states that some services could cause a problem, you'll need to stop them. Stop the capture by running airmon-ng stop [interface].
- If airmon-ng indicates that there are interfering processes, find the processes and kill them with the command kill [PID]:
- Run airmon-ng check kill to check for processes then kill them automatically.
Stopping Monitor Mode
To stop monitor mode, determine the interface name. It will be different than the one you used to activate monitor mode. The new interface should be the same name, but with "-mon" appended to it.
- Use airmon-ng without arguments to list the interfaces.
- Issue the airmon-ng stop [interface] command to stop monitor mode on this interface.
- If there are difficulties reconnecting after going back to station mode, restart NetworkManager and any other processes that were killed via systemctl. For example: systemctl restart NetworkManager.
Using Wireshark in Monitor Mode
Once a wireless card is in monitor/promiscuous mode, the data can be viewed live using Wireshark in Monitor Mode.
Note: The following screenshots were taken using an old (pre v2.0) version of Wireshark. To enable Monitor Mode in newer versions, please reference the Wireshark Wiki for details.
In the example below, interface en0 (Mac) or mon0 (Linux) was selected and specified to use monitor mode.
Once this mode is selected and the capture is started in Wireshark, the 802.11 frames will start to fill the screen. This will be the majority of the traffic, and since there aren't any coloring rules for 802.11 traffic by default, they should be white: