My Troubleshooting experience with 802.11 Beacon Frames.

Wireless Frame Analysis involve understanding what to look for in the 802.11 packet. Here lets look at “Beacon” Wi-Fi Management frames and those Interesting packet fields that can come handy while you troubleshoot client connectivity and performance issues caused by beacon frames.

802.11 management frames enable stations to establish and maintain communications.

The following are common 802.11 management frame subtypes:

802.11managementframes

#Beacon Frame:

The access point periodically sends a beacon frame to announce its presence and relay information, such as timestamp, SSID, and other parameters regarding the access point to radio NICs that are within range. Radio NICs continually scan all 802.11 radio channels and listen to beacons as the basis for choosing which access point is best to associate with.

 

beacon

The  Beacon frame has some information that we could glance through.

Section 1 : Physical Header of a Beacon: The radio tap header information are basically pseudo-header to supply additional info from driver to userspace.

And I use wire-shark to decode the packets for analysis and sometime it also depends on how best the software decodes the Wi-Fi packets for analysis. Rarely you might get to see some issues on the protocol analyzers that fail to decode the information right. we might need to double confirm with another (It just happens in corner cases)

The following are few information we have in physical header

*The signal strength

*channel (frequency)

*data rate of the packet

Section 2 : MAC Header and Frame Control of a beacon frame

Following information’s are available in  MAC-LAYER.

*Type of fame

*sub-frame type

*Frame control Flags

*Source address of the frame

*Destination address of the frame : FF:FF:FF:FF:FF:FF(Broadcast)

*BSSID

Section 3: Beacon Frame Body

Following information’s are available in  frame body of Beacon frame.

*Beacon Interval

*capability information: Support for APSD, BLOCK-ACK

*SSID parameter

*Supported rates

*Country Information

*RSN Information

*HT Capability

*Vendor Specific attributes

Wi-Fi troubleshooting with Beacon Frame:

1.)Beacon Miss : I have experienced issues where client missing to hear the beacons would cause them go for repeated frequency scanning and re-association request or disconnections. Some clients are so sensitive that missing 3 or 4 beacons will cause a disconnection and few other survive till 7 too.

You might need to analyse the AIR traffic to see if AP sending out beacons at regular interval or if the beacons getting corrupted in Air or if client receives a corrupted frames.

In such cases try to plot a IO graph in your Wireshark application and/or enable the column DELTA TIME  in Wireshark, which ever is your choice or if both. I prefer to use IO output(this can be further more customized during the Tshoot). NOTE: Getting the exact/close enough problem time frame is key thing.

IO Graph:

The Below sample graph shows you the total traffic on AIR captured VS Beacon (IN RED)send out by AP for a given time.

IO_Beacon

Y-axis represents number of packets and X-axis shows with respect to the time interval.

Default beacon interval time on most vendors are usually every 0.1024 second.

2.)Wifi signal strength identifier: If you get to sniff the traffic staying as close as possible to the client machine , you get to see how well the client can hear the SSID(signal strength). [ considering comparing receiving sensitivity of the sniffing adapter and client NIC ]. Then by Looking at the signal strength parameter you can tell if the client is connected to far away access point or having week signal.

This will help mostly to isolate issues such as network coverage holes especially for engineers who is validating the network from remote.

3.)Date rate: Looking at the rate Beacon is sent out, you can tell if lower data rate has been disabled or not. Since Beacons always sent out @ lowest rate (base rate) configured on the Essid. Also the supported rate parameter in the frame body gives you information at the lowest rate the data packet(QoS data) will be send.

4.) BSSID parameter on the Beacon will tell you which AP the beacon belong to. So you get to know how far the AP is away from the user(if the capture is taken close to the user). NOTE: BSSID is unique to an AP.

Unless the wireless infrastructure is a single channel architecture where all the APs will share the same BSSID on a given radio.

5.) If you want to know whether if the AP supports or advertising its support for WMM, Fast BSS transition support , you should be able to find that by looking at the beacon frame.

6.)RSN information on the Beacon frame will tell if the SSID is secured or open. This field is critical for a wireless client to identify if they are connected to open network or secured network and after the wireless layer 1 association(I like to call this as Layer-1) if client need to send out a DHCP packet(Layer-3) or it has to perform layer 2 authentication further like MAC-AUTH/MACHINE-AUTH/DOT1.X before layer 3.

Seen following cases in field:  On a beacon frame RSN bit is set for a captive portal SSID(incorrect behavior of AP a software bug) causing the client connection issues. While in the same environment Macintosh laptops were able to survive this issue while the other IOS devices couldn’t and they were not able to associate to Wireless network.

7.)Beacon frame carries information about the AP vendor and even the AP chipset vendor in use.

Its been helpful for me adding some useful column’s such as “DATE RATE , SIGNAL STRENGTH, CHANNEL, RETRY, DELTA-TIME” in Wire-shark application during my packet analysis.

You can always add more packet list column preference that will help your packet analysis.

wireshark colume's

 

 

 

 

 

 

 

 

Advertisements

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

 

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:

http://www.sniffwifi.com/2013/10/how-to-capture-wifi-free-in-mac-os-x.html

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

wifi_sniff_analysis

WIRELESS PACKET CAPTURE ANALYSIS FILTERS

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

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

Example:
((wlan.sa[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

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

==>Capture retries of a station:

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

Example:
wlan.fc.retry eq 1 and wlan.ta==0d:c3 and wlan.sa==0d:c3
wlan.fc.retry eq 1 and wlan.ta==06:02:02:0d:49:96
#FOR WIFI THROUGHPUT TEST ANALYSIS:

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

#OTHER HANDY WIFI PACKET FILTERS :

* 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