How to Capture and Analyze Wireless Packets Using Omnipeek and Aircrack

With the rise of IoT, more and more embedded devices are equipped with built-in Wi-Fi modules, providing them with network access capabilities. During development, it’s inevitable to encounter various network issues, and the ability to Capture Wireless Packets is undoubtedly the most direct and effective way to analyze such problems. By capturing packets, you can identify whether the issue lies with the sender or the receiver, thus quickly narrowing down the troubleshooting scope.

However, many embedded devices may operate on real-time operating systems (RTOS) or even lack an operating system entirely, instead of running on Linux. Additionally, the communication endpoint of the device might not support tools like tcpdump or Wireshark to Capture Wireless Packets, making traditional point-to-point packet capture methods ineffective.

1. Over-the-Air Packet Capturing

1. Principle

We know that wireless network signals propagate outward from the transmission point, like ripples. In theory, if a receiver is located where the wireless signal passes through, it can receive (“listen to”) any signal passing by, although it may not “understand” them (i.e., parse the message content).
As shown in the diagram below, if the iPad is communicating with the desktop on the far left, the MacBook is entirely capable of eavesdropping on their communication.

Over-the-air packet capturing works based on this principle. If we want to capture the wireless packets of a particular embedded device, we simply need to run a PC with monitoring features nearby.

2. Operating Method

On Windows, you can use Omnipeek; however, this software requires a specialized wireless network card and driver. Detailed installation instructions and operating steps can be found on the Omnipeek official website.

On Linux, you can use aircrack. Below is a brief introduction to its usage on Ubuntu 16.04:

1. Check if your network card supports monitor mode by entering the iw list command. If “monitor” appears in the output, it is supported. Otherwise, over-the-air packet capturing is not possible.
   

software interface modes (can always be added):

* AP/VLAN

* monitor


2. Install the aircrack tool suite (aircrack includes a series of tools):
   sudo apt-get install aircrack-ng
3. Clean up the environment by stopping services that may interfere with packet capturing:
   sudo airmon-ng check kill
4. Create a virtual monitoring network interface:
   sudo airmon-ng start wlp2s0 4
   In the above command, “wlp2s0” is the name of the wireless network card, and “4” is the channel number.
   After executing the command, a virtual network interface “wlp2s0mon” will be created, which operates in monitor mode and listens to channel 4.
   If you omit the channel number in the command, all channels will be monitored. (The airodump-ng tool will cycle through channels at a certain frequency.)
5. Capture packets using airodump-ng:
   sudo airodump-ng -c 4 wlp2s0mon -w huo.pcap
   The above command specifies listening only to channel 4. Without the “-c” parameter, airodump-ng will cycle through all channels periodically, which may lead to packet loss. Therefore, it is recommended to specify the channel for packet capturing.
   The “-w” parameter writes the captured packets to a file, which can be analyzed using Wireshark or Omnipeek. Omnipeek is recommended as it provides more robust wireless packet analysis features.
   However, airodump-ng does not include signal strength, channel number, or rate information in the captured file, which may affect troubleshooting in some cases. To address this, you can use tcpdump instead. Simply replace the command in step 5 with the following (other tcpdump options remain applicable):
   sudo tcpdump -i wlp2s0mon -w huo.pcap

2. Case Analysis

1. Mobile Compatibility Issues

During a project, it was discovered that when devices communicate with different mobile phone brands, the throughput tested using iperf varied significantly.
For example, the iperf throughput with an OPPO R11 was around 13 Mbps, while with a Xiaomi 5X, it was around 25 Mbps.

As shown in the figure below, during interaction with the Xiaomi 5X, the TCP data packet payload is consistently 1460 bytes:

In contrast, during interaction with the OPPO R11, a 1420-byte large packet alternates with a 40-byte small packet.

From the TCP handshake phase in the above packets, we can see that the Maximum Segment Size (MSS) of OPPO R11 (192.168.42.2) is 1420. This field represents the maximum segment size, meaning that if the data length exceeds this value, it needs to be fragmented for transmission.

This value is generally derived from the MTU. By executing “ifconfig” on the OPPO phone via adb, it was observed that the MTU is 1460. Subtracting the 20-byte IP header and the 20-byte TCP header leaves an effective data length of 1420 (i.e., MSS).

Checking the MTU of Xiaomi 5X reveals it is 1500, making the MSS 1460.

Upon further inspection of the device’s iperf code, it was found that each call to the send function sends a fixed 1460 bytes. This results in the following: The same data packet is sent in one transmission when interacting with Xiaomi 5X, but is fragmented into two packets—1420 and 40 bytes—when interacting with OPPO R11.
This explains why the throughput of Xiaomi 5X is nearly double that of OPPO R11.

Note: Normally, if the TCP_NODELAY option is not enabled, the Nagle algorithm will aggregate small packets into larger ones to some extent. However, the protocol stack used by this device lacks such functionality.

2. Wi-Fi Power-Saving Mode

During Wi-Fi stability testing, it was observed that throughput sometimes dropped to around 5 Mbps every ten minutes, taking about 3 seconds to recover.
Opening the capture file with Omnipeek and analyzing the traffic chart revealed a low throughput section:

Upon analyzing the packets near the dip, it was found that the PC’s network card had entered power-saving mode.
After disabling the power-saving mode of the PC’s network card and retesting, Wi-Fi throughput remained stable.

3. Other Applicable Scenarios

• Diagnosing issues with phones unable to connect to an Access Point (AP)
• Diagnosing slow connections to an AP
• Diagnosing cases where the AP cannot be found
• Diagnosing issues during business interaction processes.
  Note: To analyze packet content, it is recommended to set the AP to open mode. This way, captured content doesn’t need to be decrypted. If the AP is password-protected, you must capture the connection process to the AP in order to decrypt the packets.

​

Others

Let me know if further refinements are needed!