The Problematic CTS TO SELF packet

Recently, I was working on a VOIP over Wi-Fi issue for a Japan customer. The complain from the user is that the VOIP calls over Wi-Fi goes static or disconnects often.  I started to Debug this issue analyzing the station log to see the behavior of the client while its associated to wireless network. I couldn’t find the issue straight forward.

Checked to Confirm the RF Numbers and Network configuration with best practices for VOIP over Wi-Fi is already in place. So, i though its better to sniff the Air and  read the packets to narrow down the issue.

VOIP SETUP IN PLACE: Android phone running VOIP application.

-Android client 4.4.2

-VOIP Application :Covia Networks(softphone)

-Fortinet(Meru)Wireless System.

My first level of Troubleshooting analysis on the aircapture took a different direction while analysis the packets in Ominpeek with the time frame of issue mentioned (I was bit lazy at this point)


Attached the Wi-Fi packet capture for your reference. Packets to look for are #45571,#65972

>I felt,  haaa why is the AP sending CTS frame with a 10000 Microsecond of duration time.


>You see Omnipeek EVENT/LOG viewer tells so. The AP has sent this CTS  frame to the client device with 10000 microsecond


Then i was looking at the same capture on wire shark protocol analyser(no event or log view ) and realized that client has never sent an RTS frame requesting for channel access.


>I then realized its a CTS TO SELF frame from Android client with high duration values set and that’s causing all the problem for VOIP application running over it.

>I felt, i gone so lazy that i almost decided that the issue is because of the AP sending high duration value by comparing EVENT/LOG in Omnipeek.(that was definitely incorrect).

>The android client build with Broadcom SOC chipset , so no quick fix from client side on this issue. Customer was asked to run the VOIP application on a different client device to sort this client side issue(Workaround i was able to suggest for)

Packet capture download link:


AirCapture with MacBook

Sniff AirTraffic using Macbook is easy and you just have to follow the steps below:
1.)Quit all open applications.
2.)Try to join the Wi-Fi network that you are having issues with if you are not already connected.
3.)Open Wireless Diagnostics. Tip: You can hold down the Option key and then click the Wi-Fi menu extra.
4.)Enter your admin name and password when prompted.
5.)In Wireless Diagnostics, choose Window > Sniffer,
5.)Choose appropriate channel and channel width as per your Wireless AP Radio configuration

Start the capture , click stop when you are done , A capture file will be placed on the desktop.

I also found a Video done my benmiller regarding the same:

Some Wireless Capture Analysis today

I was working on a WiFi client Disconnection issue and got to analyse some Wireless  frames . Thought of sharing  some IO



==>Capture particular client traffic for sa/da/ra/ta:

(([4-5]==XX:XX || wlan.da[4-5]==XX:XX || wlan.ra[4-5]==XX:XX || wlan.ta[4-5]==XX:XX))

(([4-5]==e9:d4 || wlan.da[4-5]==e9:d4 || wlan.ra[4-5]==e9:d4 || wlan.ta[4-5]==e9:d4))

==>Here’s a Wireshark display filter to capture beacons for a specific BSSID

wlan.fc.type_subtype == 0x0008 && wlan.bssid == xx:xx:xx:xx:xx:xx

wlan.fc.type_subtype == 0x0008 && wlan.bssid == 06:02:02:0d:49:96

==>Capture retries of a station:

wlan.fc.retry eq1 and” ” || wlan.ta== ” ”
wlan.fc.retry eq 0 and” ” || wlan.ta==” “\

wlan.fc.retry eq 1 and wlan.ta==0d:c3 and
wlan.fc.retry eq 1 and wlan.ta==06:02:02:0d:49:96

wlan.fc.type_subtype == 0x001c && wlan.duration >2000


* Show only the beacon frames:
wlan.fc.type_subtype == 0x08
* Show everything except the beacon frames:
!wlan.fc.type_subtype == 0x08
* Show only beacon frames and ack frames:
(wlan.fc.type_subtype == 0x08) || (wlan.fc.type_subtype == 0x1d)
* Show everything except the beacon and ack frames
(!wlan.fc.type_subtype == 0x08) && (!wlan.fc.type_subtype == 0x1d)
” Capture only Ethernet type EAPOL” ether proto 0x888e
” Probe Requests” wlan[0] == 0x40
” No Probe Requests” wlan[0] != 0x40
” Probe Response” wlan[0] == 0x50
” No Probe Response” wlan[0] != 0x50
” Ack” wlan[0] == 0xd4
” No Ack” wlan[0] != 0xd4
” CF-End” wlan[0] == 0xe4
” No CF-End” wlan[0] != 0xe4
” Clear-to-send” wlan[0] == 0xc4
” No Clear-to-send” wlan[0] != 0xc4
” Beacon Frames – Probe Response/Request – Ack” wlan[0] == 0x80 or wlan[0] == 0x50 or wlan[0] == 0x40 or wlan[0] == 0xd4
” No Beacon Frames – No Probe Response/Request – No Ack” wlan[0] != 0x80 and wlan[0] != 0x50 and wlan[0] != 0x40 and wlan[0] != 0xd4
” Beacon Frames-Probe Resp/Req-Ack-CF-End-Clear-to-send” wlan[0] == 0x80 or wlan[0] == 0x50 or wlan[0] == 0x40 or wlan[0] == 0xd4 or wlan[0] == 0xe4 or wlan[0] == 0xc4
” No Beacon Frames-Probe Resp/Req-Ack-CF-End-Clear-to-send” wlan[0] != 0x80 and wlan[0] != 0x50 and wlan[0] != 0x40 and wlan[0] != 0xd4 and wlan[0] != 0xe4 and wlan[0] != 0xc4