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)

CTS_TO_SELF

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.

CTS1

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

CTS_TO_SELF

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.

cts-self_wireshark

>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:

https://www.dropbox.com/s/969z0w8xr881c1g/100ch_3min_default.pkt?dl=0

 

Advertisements

4 thoughts on “The Problematic CTS TO SELF packet

  1. Hello,

    Good job, but i don’t understand why the high duration value cause issue on the Android device for voip? if it reserve too much time it may not cause issue for other client instead ?
    Also in the capture i can see the device is using the 5Ghz band. if we consider that CTS to self is to reserve channels before sending OFDM signals which isn’t supported by older Wi-Fi standards equipment (like IEEE 802.11b) i don’t understand why its its use by a device on 5GHz

    Like

  2. Hi Leo,

    Appreciate your questions.

    Questions 1:

    why the high duration value cause issue on the Android device for voip?
    ==>
    Once after client(culprit) sending a CTS to SELF frame to reserve the channel access it went MUTE. Later you would see after a delta time of 20Milliseconds all the RTP frame downstream from the AP going unacknowledged(This is where the customer faced the VOIP issue).

    You can try filter the client traffic and check for the frames between 45569-45615.

    Filter:
    wlan.sa[4-5]==c6:ee || wlan.da[4-5]==c6:ee || wlan.ra[4-5]==c6:ee || wlan.ta[4-5]==c6:ee.

    Question 2:

    if it reserve too much time it may not cause issue for other client instead ?
    ==>
    Yes, ideally it should affect the channel access for data client too(all type of clients). Here the customer Wi-Fi network is primarily for VOIP application purpose. Customer network didn’t had much of other client connected(so customer’s concert was more of fixing the VOIP issue).

    Questions 3:

    CTS to SELF is to reserve channels before sending OFDM signals which isn’t supported by older Wi-Fi standards equipment (like IEEE 802.11b)
    ==>

    You already kind of answered this questions. You would notice the client and AP communication is on channel 100(5ghz). So, NO 802.11b(legacy) client over there in 5ghz who don’t know how to decode these packets.

    Cheers,
    Praveen

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s