I’ve tried to condense my notes from the study for CWAP-403 exam. The exam consists of lot of details which need to be learnt if you have not done enough capturing and analyzing 802.11 wireless frames before.
I have pen down a some troubleshooting scenarios which I’ve come across while studying for CWAP exam.
To begin with,
Management Frames > Foundation of how wireless radios detect, join and operate on WLAN. Control Frames > Frames which control the delivery of Data frames. Data Frames > Carry actual data payload from/to layers 3-7.
Some scenarios which frames can provide an insight for.
Client Roaming Observations – In some cases, there might be some issues with clients not able to perform seamless roaming or the roaming might be delayed when client moves from one AP to another. In some cases we may need to find which type of roaming method are supported by the AP to diagnose other issues. Let’s see how the frames can help.
To find the roaming handoff time from one AP to another we have to examine the frames from type > Reassociation Type to the completion of 4-way handshake. E.g. frame below
Total roaming time can be calculated by subtracting the EAPOL M4 time (0.105180) with Reassociation Request Frame(.003857)= .101323 ~ approx. 101ms
Type of roaming method can be deduced from the Tagged Parameters set in 802.11 Wireless LAN section. Below example uses Over-the-air Fast BSS, value of 1 will denote it using Over-the-DS BSS.
Management Retries – Generally anything under 20% of Management retries in the network is considered OK or acceptable. There is no set vendor recommended management retry. In a prod environment it is bound to have certain % of retries even if the AP or Client placement/AP Tx Power/Interference and Channel settings are set to optimal. In any case anything over constant 20% retries could indicate some concerns in the WLAN environment which need investigation.
We can also check this on the Wireshark IO graphs as below to highlight the management retries. Below network has lot of management retries and needs further investigation
Duration/ID field
16 bits in length, used for virtual carrier-sense, legacy power management & contention-free period.
In the below RTS frame, the duration value is 2048ms. The radio is asking for permission to reserve airtime to pending transmission. The receive radio can allow or deny this request. But higher duration value can indicate the delays it is causing in allowing/denying the request. This can cause some weird behavior in client operation, may also cause disruption in network services. We have to closely check the change log on the WLAN environment. If this is a result of some WLAN controller/AP software update or other updates which may cause the issues. Also NOTE: Please check the device and not always high duration value can be a problem.
Null Data Frames / Power Management
The null
data frames are in fact not null as per their description. They can help in
troubleshooting few WLAN issues. Null data is categorised under control frame.
It is only transmitted from a STA/Client. The sole purpose is to carry power
management frames controlled field. The power management bit will either be set
to 0 or 1. Below are the examples.
STA = 0,
it is informing AP that it(STA) is In active power state (awake) and
transmission of frames from AP to STA should be normal.
STA =1,
is informing AP that it is going offline and any frames that come into the AP
from this STA should be buffered at the AP till the STA returns and sends a
NULL frame of 0, active state.
PSM >
Power Save Mode allows the client STA to go into sleep mode. It can essentially
turn of the NIC functions including the radio thereby consuming less battery
and conserving it. Some devices can benefit from this but there are some which
may have aggressive power save mode options. So one needs to check the client
driver details to troubleshoot any issues relating to client.
Some
known issues with Power Management are described in below links
Another
reason why client STA may inform AP about changing the bit to 1 is when it is
roaming. Suppose client has reached the roaming limits of the AP it was
connected to and wants to switch to the nearby one, in order to to this it may
go off the channel sending the buffer frames signal to AP and resume its
connection.
This blog post will focus on tools I’ve used for performing Wireless Frame Captures. I’ve been largely dependent on Macbook for capturing the wireless frames. I would highly suggest you for sourcing a Macbook for frame capture as Windows PC option involves getting a third party WLAN pcap which is not cheap. Thank you Apple for making it possible to capture frames natively on Mac.
The Hardware
Macbook Pro
Other Utilities Required/Recommended.
Wireshark is available as free tool to download. It is highly recommended to optimize it using the wireless configuration profiles available at Metageek. This is our primary tool for capturing and analyzing the frames.
It is recommended to add (Absolute Time, Relative Time & Delta Time) values on the Wireshark as it is important when analyzing the wireless frame analysis. In roaming scenarios, one may need to acquire the time it took for a client to move between one AP to another.
Airtool is also available for free. This tool is not mandatory but good to have. Since it is free, then why not? It helps capture frames on few mouse clicks and helping you easily move them analyze them on wireshark or via online (Packets)
Packets (Arista) – Phenomenal tool for analyzing the frames. Birds eye view of various frame types in the wireless environment, management retries, problem clients etc. Free account available up to 100MB of pcap (more than sufficient for your CWAP studies).
WiFi Explorer – Highly Recommended if you can purchase, the professional version costs around $20 USD. Can really help with identifying the WLAN discovery and metrics of the environment.
If you own an iPhone or iPad, one can configure Wi-FI Diagnostics on the phone. Thanks for George Stefanick for explaining it so nicely.
802.11 Frame Exchanges section account for 25% of syllabus for CWAP-403 exam. Potentially around 15 questions out of 60 in the exam can be expected from this section. This blog post focuses on the “security” component of 802.11 Frame Exchange. I will be focusing on other sections in the subsequent posts in the next week or two. Let’s begin!
Authentication
1st
step required to connect to 802.11 BSS. Both authentication and association
must occur in order to successfully pass wireless traffic over to the AP and
further. IEEE 802.11i-2004 defines RSNA. Open System & Shared Key
Authentication are Prior to RSNA (Pre-RSNA) methods. The
802.11 authentication merely establishes an initial connection between the
client and the access point, basically validating or authenticating that the
STA is a valid 802.11 device.
Open System Authentication > Allows any device to authenticate and then attempt to communicate with the AP. The STA can communicate only its Wired Equivalent Privacy(WEP) keys match the AP
Shared Key Authentication > Not used anymore. Requires static WEP key configured on STA and AP.
Open
System authentication and association between client STA and AP occurs prior to
802.1x/EAP authentication exchange between client STA and Radius server.
WLAN Encryption Methods
WEP
Pre-RSNA
Weak / Vulnerable / No Protection against replay attacks
Open/Shared Authentication
TKIP (Temporal Key Integrity Protocol) (RSN)
Uses dynamically created encryption keys as opposed to static keys.
128-bit temporal key can either be a pairwise transient key (PTK) or group temporal key (GTK) used to encrypt
WPA-PSK & WPA-Enterprise
Can be vulnerable against certain attacks.
CTR with CBC-MAC Protocol (CCMP) (RSN)
CTR – Counter mode is used for data confidentiality
CBC MAC(Cipher-block chaining message authentication code) is used for integrity.
Used with AES block cipher suite with 128 bit key
SAE (Simultaneous Authentication of Equals)
Uses SAE known as Dragonfly Key Exchange, with forward secrecy feature
WPA3 Personal – 128 Bit SAE, Enterprise – 192 bit SAE
Not Vulnerable to KRACK attacks and offline dictionary attacks.
The info
that is protected by these L2 encryption methods is data found in layers of
3-7. L2 encryption methods are used to provide data privacy for 802.11 data
frames. These methods encrypt MSDU payload of an 802.11 data frame.
Security Protocols
WEP
TKIP (WPA)
CCMP (WPA2)
OWE (Opportunistic Wireless Encryption)
Cipher
RC4
RC4
AES
AES-GCM
& Elliptical Curve Cryptography
Key
40/104
bits
128
bits
128
bits
192
bits
Authentication
N/A
IEEE
802.1X/EAP/PSK
IEEE
802.1X/EAP/PSK
WPA3
Personal / Enterprise
Data
integrity
CRC32
MIC
CCMP
Secure
Hash Algorithm-2 for each input
IV
Length
24 bits
48 bits
48 bits
24 bits
RSNA (Robust Security Network Association) First published & ratified as IEEE 802.11i-2004, defined stronger encryption and better authentication methods. Now part of 802.11-2007 standard. Association between two stations is referred to as RSNA which means the two radios should share dynamic encryption keys that are unique between those two radios. CCMP/AES s mandatory, TKIP RC4 is optional. All client stations have to undergo a unique RSNA process called the 4-way handshake.
The RSN
information element field is found in 4 management frames: beacon, probe,
association request and reassociation request frames. Client STA use the
association request frame & reassociation request (in case of roaming
to/from) to inform the AP about their security capabilities.
RSN
information element – AES(CCMP) used in the below frame example.
802.1X
The
802.1X standard is port-based access control standard which provides an
authorization framework that allows or disallows traffic to pass through port
thereby granting access to the network resources. 802.1X can be implemented in either
wireless/wired environments. The L2 protocol called EAP (Extensible
Authentication Protocol) is used and consists of 3 major components of this
framework.
Supplicant > Client STA
Authenticator > AP or WLAN Controller.
Authentication Server > Usually Radius(NPS), ISE (Cisco)
EAP
Defined
in IETF RFC 2284 and ratified in the IETF RFC 3748, provides support to many
authentication methods.
L2 Protocol
Two way authentication also called as mutual authentication.
EAP messages are encapsulated in EAP over LAN (EAPOL)
Five major types of EAPOL messages as shown below
EAP Protocols
The
stronger and more commonly deployed methods of EAP use TLS (Transport Layer
Security) or TLS-tunneled authentication. EAP-MD5 and EAP-LEAP have only 1
supplicant identity making them weaker EAP types. EAP-TLS uses 2 supplicant
identities – outer and inner identity. The outer identity is effectively a
bogus username and can be seen clear text, and then inner identity is the true
identity protected with TLS tunnel.
Table describes all the protocols with their characteristics.
802.1X EAP TypesFeature / Benefit
MD5—Message Digest 5
TLS—Transport Level Security
TTLS—Tunneled Transport Level Security
PEAP(WIDELY USED)Protected Transport Level Security
Difficult
(because of client certificate deployment)
Moderate
Moderate
Moderate
Moderate
Wi-Fi Security
Poor
Very
High
High
High
High
High when strong passwords are used.
4-Way Handshake
802.11-2007
standard requires EAPOL-Key frames be used to exchange cryptographic
information between STA supplicants and the authenticator, which is usually an
AP. EAPOL key frames are used for the implementation of three different frames
exchanges: 4-way handshake, group key exchange & peerkey handshake. 4 way
handshake is the final process used to generate pairwise transient keys (PMK /
GTK) for the encryption of unicast transmissions and the group temporal key for
encryption of broadcast/multicast transmissions.
The 4-way
handshake uses pseudorandom functions, it hashes various inputs to derive a
value (PRF). The PMK is one of the inputs combined with other inputs to create
the pairwise transient key (PMK). Some of the other inputs used by the PRF are
called nonces. A nonce is a random numerical value that is generated one time
only. In the case of 4-way handshake, a nonce is associated with the PMK. Two nonces are created in 4-way
handshake – authenticator nonce (anonce), supplicant nonce (snonce).
Authenticator sends EAPOL-Key frame containing “anonce” to supplicant
With this info, supplicant have all the necessary input to generate PTK using PRF
M2 –
Message 2
Supplicant sends an EAPOL-Key frame containing “snonce” to the authenticator
Authenticator has all the inputs to create PTK
Supplicant also sends RSN IE capabilities to Authenticator & MIC (message integrity code)
M3 –
Message 3
If necessary, Authenticator will derive GTK from GMK
Authenticator sends EAPOL-key frame containing “anonce”, RSN-IE and a MIC.
GTP (encrypted with PTK) delivered to the supplicant.
Message to supplicant to install temporal keys.
M4 –
Message 4
Supplicant sends final EAPOL-key frame to authenticator to confirm temporal keys have been installed.
Group Key Handshake
The
802.11-2007 standard also defines a two-frame handshake that is used to
distribute a new group temporal key to client STA that have already obtained a
PTK and GTK in a pervious 4-way handshake. The GKH is used only to issue a new
group temporal key to client STA that have previously formed security
associations. Effectively GKH is identical to M3/M4 in 4 way handshake.
Fast BSS Transition (FT)
Published
in 2008, 802.11r – technical name for standardized fast secure roaming. An
Amendment to improve handoff from one AP to another. The handoff is the same
with or without 11r, the device is what ultimately decides when and where to
roam. 802.11r are often discussed in
context with WLAN controller architecture. Mobility domain is a group of AP
that belong to the same ESS where the client STA can roam in a fast and secure
manner. FT BSS transitions can happen over-the-air or over-the-DS (Distribution
System).
FT over-the-air (AP to AP, Same Controller)
Client associates with AP1 and requests to roam to AP2
Client sends a FT authentication request to AP2 and receive FT authentication response from AP2.
Client sends FT reassociation request to AP2 and receives FT re-association response from AP2.
Client completes the roaming from AP1 > AP2
FT over-the-air
(AP-CONTROLLER|CONTROLLER-AP)(Inter-Controller)
Step 1 & 2 similar to above steps.
WLC1 ends PMK and mobility message to WLC-2 about the roaming client that uses mobility infrastructure.
Client completes the roaming from AP1 > AP2
FT over-the-DS (AP to AP, Same Controller)
Client Associates to AP1 and requests to roam to AP2
Client sends a FT authentication request to AP1 and receives a FT authentication response from AP1
The controller sends the pre-authentication info to AP2 as the AP are member of same controller.
Client sends a FT re-association request to AP2 and receives a FT re-association response from AP2.
Client completes its roaming
FT over-the-DS (AP to AP, Different Controller)
Step 1 and 2 are similar to above steps.
WLC-1 sends PMK and mobility message to WLC-2 about the roaming client
Accounts
for 10% of the CWAP knowledge domain areas, approx. 6/60 questions
Medium Contention :Protocols that allow large number of devices to effectively share the wireless channel. All AP & STAs will contend with each other on a common transmission medium.
CSMA / CA – The AP/STAs (802.11) use carrier
sense multiple access with collision avoidance as opposed to collision
detection used by the Ethernet (802.3) realm.
802.11
devices must avoid multiple devices transmitting simultaneously over a shared
medium which can cause failed transmissions. Wireless mediums cannot detect
collision but find ways to avoid them. Collision handling is not straight
forward and may be time consuming at times. Hence one of the reasons that
802.11(WLANs) have much lower throughput-to-data rate ratio than 802.3(Wired
LANs).
CSMA/CA
uses DCF (Distributed Coordination Function) for non-QoS WLANs & HCF (Hybrid Coordination Function) for QoS
WLANs using EDCA (Enhanced Distributed Channel
Access).
There are
two carrier sense protocols used by the
stations to indicate whether a channel is busy or idle.
Physical Carrier Sense, also known as CCA (Clear Channel Assessment)
Virtual Carrier Sense, also known as NAV (Network Allocation Vector)
Both QoS
& non-QoS use either of the above protocols for transmitting data.
CCA (Layer 1) > Identify
whether the channel is unused and available prior to the packet transmission.
Channel Occupied = State of Busy ~ Energy Detection Levels.
Channel Clear = State of Idle
Apply to
802.11 modulation, if the AP or STA is too far away to detect any transmission
at requisite energy level, the CCA may go into the idle state even though the
channel is still occupied.
NAV (Layer 2) > is a timer that counts down
toward zero(0). When a device has a NAV value greater than zero, the device
says quiet. Once the NAV = 0, the medium is considered clear.
As
discussed earlier, CCA may fail to keep other devices on the channel quiet (Too
far transmitting device, obstruction, interference), the design of the NAV
keeps APs and stations quiet.
Duration
value in the 802.11 header set the NAV values for AP and STAs.
It is
vital for the AP and STA to stay with the RSSI data range in order to
successfully demodulate a transmitted frame so that the Duration/ID field in
the header can be accurately set.
Interframe Spaces
When 2 or
more STAs begin frame transmission at the same time in the idle environment,
collisions are bound to happen. Hence we have additional medium contention
protocols beyond CCA & NAV. These protocols must keeps AP and STAs quiet
like CCA/NAV & also allow differentiated medium access.
IFS is
the quiet period that AP & STA must wait before any 802.11 frame
transmission.
TIPS to
Remember!
If the contention has been completed, then a reduced IFS (RIFS) or short IFS (SIFS) will be used. Most cases it is SIFS but RIFS is only used between consecutive frames transmitted by 802.11n device.
If the contention/arbitration is not determined, then arbitration IFS (AIFS) or DCF IFS (DIFS) will be used. The AIFS is used for WLANs that support 802.11e QoS, and the DIFS is used for WLANs that do not support 802.11e QoS.
If an AP or STA has received a corrupted frame as defined by having an incorrect FCS, then extended IFS will be used.
PCF IFS (PIFS) is part of PCF and therefore not used in real world. (May be ignored for CWAP prep!)
802.11 FHSS network use 50ms slot time.
Steps involved for a STA to go through before starting the frame transmission in the wireless medium (Source : 802.11 Arbitration CWNP White Paper)
SIFS >
Foundation of all IFSs.
10ms for 802.11b/g/n (2.4GHz)
16ms for 802.11a/n (5GHz).
It is used after
contention/arbitration is completed. Exception being 802.11n device using
MIMO to transmit frames then RIFS is used.
RIFS >
Simplest IFS to understand.
Length is always the same 2ms.
Only for devices which use 802.11n/MIMO.
It precedes for only “data” frame.
DIFS >
Designed to force AP and STA with ordinary data in the queue to stay quiet for enough time to allow QoS frames to have access to the channel.
It is used when arbitration process has not yet completed.
DIFS is equal to length of SIFS + 2 slot times. Slot times are quiet periods, similar to IFS.
They are equal to 9ms for 802.11a/n/ac operating in 5GHz and 802.11g/n with 2.4GHz.
The 20ms slot is used if the HT or ERP is used with long preamble and 802.11b/g/n 2.4 GHz DSSS.
The short preamble is default setting when HT or ERP is used.
EIFS >
Designed to give AP and STA a chance to retransmit after a failed frame.
This happens when AP/STA failed to receive ACK after transmission.
EIFS = SIFS + DIFS plus the time taken acknowledge the frame to transmit.
802.11b/g/n(2.4GHz) using DSSS= 364ms, 802.11a/n(5GHz) & 802.11g/n (2.4GHz) = 160ms. EIFS is the longest of the IFS.
Near/Far Problem : STA closer to AP may cause
problem to STA at far. When data is transmitted between AP and nearby STAs they
can use higher data rate than far stations. (This is why STA dynamically switch
their data rates downward when moving away from the AP). The frame therefore
will appear to be corrupt even though it was successfully transmitted. The far
STA have to stay quiet for an EIFS at the beginning of the arbitration process,
while the near STA will be allowed to use the shorter DIFS.
PIFS > Equal to one slot time + 1 SIFS and
it is designed to give AP the chance to send the beacon in order to begin the
CFP (Contention Free Period). In real-world the PIFS is only used with Channel
Switch Announcement frame, which is one of the Action frames from 802.11h.
RANDOM BACKOFF
The
mechanism which prevents collision by differentiating 802.11 channel access is
the Random Backoff. Unlike the IFS, the random backoff is not static. It is the
period of time that changes based on a random number chosen by AP or STA.
AP and
STA stay quiet during the random backoff by randomly choosing a number of slot
times and then counting down until the number of slot times equal to zero.
Transmission resumes after slot time equals zero.
For the random backoff to work, there must be an upper and lower limit to the number of slot times that ca be chosen.
The lower limit is always 0. The upper limit for the random backoff is equal to the contention window (CW).
The CW is derived from the equation 2x – 1, where x is a value that increments with each failed frame. For DSSS-based networks, x starts at 5, which results in a CW of 31. For OFDM-based networks, x starts at 4, which results in a CW value of 15. For both DSSS and OFDM-based networks, the x value stops incrementing at 10, which results in a CW value of 1023.
Failed frames cause the contention window to grow exponentially. More quiet time means a less efficient channel thus causing latency and throughput issues.
QoS FRAMES
AIFS >
Used by QoS enabled STA to transmit all data, management, PS-Poll, RTS, CTS (when not transmitted as response to RTS), Block Ack Req and Block Ack (when not transmitted as a response to Block Ack Req).
Slot times in AIFS is called as AIFSN (slot number).
802.11e specifies Voice (AV_VO), Video (AV_VI), Background (AV_BK) & Best Effort (AV_BE).
Video and Voice = 2 Slot times
Best Effort = 3 Slot times
Background = 7 Slot times
Calculate AIFS for a given Access Category = AIFSN[AC] x Slot Time x SIFSTime
TXOP
Transmit Opportunity or TXOP is the amount of time a STA can send frames when it has won contention for the wireless medium. This is in relation to EDCA (Enhanced Distributed Channel Access).
When a STA sends QoS data, it must first contend for the access to the wireless medium.
STAs perform CCA and determine if the channel is idle. It must have its NAV set to 0. Then it must wait for the appropriate InterFrame Spacing.
Then it would wait for the contention window to complete. CW has 4 categories as discussed in the previous section. Each category has different TXOP.
This chapter accounts for 10% of the Knowledge Domain in the CWAP exam. Approx. 6/60 questions!
Exam Moment from the Book : It is not important, for the CWAP exam, that you know all the details of the variations of the PHY preambles; however, you should know that the preamble adds extra overhead to the communications and that older devices may introduce a preamble that reduces performance overall and forces all devices in the BSS to communicate based on that long preamble.
CS/CCA
Carrier Sense > State of STA where it is ready to transmit or receive packets/signals
Clear Channel Assessment > Identify whether the channel is unused and available prior to the packet transmission
Transmit (Tx) > Upon checking if the wireless medium is available the STA needs to transmit a frame which is enabled by CS/CCA process. Unlike ethernet the wireless frames cannot transmit and receive the frames at the same time.
Receive (Rx) > The transmitting STA will precede the data portion of the frame with a preamble. It contains a binary strings that the receiving station can identify and synchronise with , essentially alerting the receiving station to the transmission. The preamble also includes a Start Frame Delimiter field, which the receiving station uses to identify the beginning of the frame. An ACK frame Is sent with the entire frame is received.
PMD > transmits the data as RF modulated 1s and 0s. When receiving , the PMD listens to the RF and passes the received data up to the PLCP sublayer. PLCP Protocol Data Unit> When PLCP receives PSDU, it then prepares PPDU. PLCP adds a preamble + PHY header to the PSDU.
PLCP Preamble > String of 0/1 bits that are used to synchronise incoming transmissions. IEEE 802.11-2007 standard defines 3 different PPDUs.
Long PPDU > 144 bit PLCP Preamble, 128 bit Sync field + 16 bit Start of Frame Delimiter (SFD).
Short PPDU > 72 bit PLCP Preamble, 56 bit Sync field and 16 bit SFD
OFDM PLCP Preamble >10 short symbols + 2 long symbols
PLCP Header > Long & Short PLCP Headers are both 48 bits log and contain 4 fields (Signal(8) + Service(8) + Length(16) + CRC(16).
802.11n
PPDUs
Non-HT Legacy PPDU
Consists of Preamble(Short/Long symbols)
Mandatory for 802.11n radios and transmissions can occur in only 20MHz channels.
Effectively same format used by legacy 802.11a/g radios.
HT-Mixed PPDU
802.11n amendment
Likely be most commonly used format as it supports HT + Legacy 802.11a/g.
Transmission can occur in both 20MHz and 40MHz channels
HT-Greenfield PPDU
2nd of the two new PPDU formats defined by 802.11n.
Not compatible with legacy 802.11 radios, only the HT Radios can communicate with this format.
Can transmit using 20MHz and 40MHz fields.
Data Field
The data
field portion of PPDU is the PSDU. In easy terms, the data field is the 802.11
MAC frame.
This post covers the important 802.11 Frames which can help in performing the analysis and troubleshoot any issues related to WLAN networks. I have referenced Wireshark filters for the ease of each frame.
Used to authenticate to an AP to prepare association or roaming
Used to remove the AID (Authentication ID) and deauthenticate with an AP.
Frame body consists of
Authentication Algorithm Number – 0 for Open System and 1 for Shared Key
Authentication Transaction Sequence Number – Indicate current status of progress
Status Code – 0 for Success,1 for Unspecified failures
Challenge Text Used in Shared Key Authentication frame 2 & 3
Association
and Disassociation Frames (0000, subtype =0)(0001 subtype =1) wlan.fc.type_subtype==0 or wlan.fc.type_subtype==10
Simple 4-frame exchange (authentication request, ACK, authentication response & ACK) used to enter the authenticated and associated state with the AP.
After Association STA may either use the network (open system authentication) or begin the 802.1x/EAP authentication process if used.
The Disassociation frame is used to change from authenticated/associated state to “authenticated not associated state”. They contain a reason for disassociation. In case of below frame the reason code is unspecified reason.
Reassociation
Request and Response Frames – (0010, subtype : 2) (0011, subtype : 3) (wlan.fc.type_subtype == 0x2 or wlan.fc.type_subtype ==0x3)
These frames are used to roam to another AP within the ESS (extended service set) or to reconnect after brief disconnection.
The reassociation response frame will also include an AID for the STA and the status code indicating the reassociation success or failure.
RTS and CTS frames are used to clear the medium for transmission of larger frames.
The Duration Field in RTS/CTS is very important.
SIFS (Short Interframe Space) – Amount of time in m/s required for a wireless interface to process a received frame and to respond with resoonse frame.
RTS duration = SIFS(3) + CTS + Data + ACK(1)
CTS duration = SIFS(2) + Data + ACK(1)
CTS-to-self > is another method of performing NAV (Network Allocation Vector) distribution that use only CTS frames. It is used strictly as a protection mechanism for mixed mode environment.
These frames are sent right after data/management frames to inform(ack) the transmitter.
With ACK frame, the transmitter assumes the frame was lost due to the corruption from interface or some other issue, and so retransmits the frame.
ACK frame includes Frame Control, Duration, RA and FCS subfields
Duration Field value is set to : Duration Value of previous frame + ACK(1) + SIFS(1)
Null
Data & PS-Poll Frames (0100 Subtype : 4) (wlan.fc.type_subtype
== 0x24) or (wlan.fc.type_subtype == 0x1a)
Null Data Frames are used to notify an AP that the STA is awake and able to receive the frames.
It is simply a data frame with no date in the Frame Body field.
PS-Poll on the other hand are used to notify the AP that the client STA is awake and available for buffered frames.
STA indicate the power save mode using the Power Management bit the Frame Control field. When a STA is in PM mode = 1 it alternates between awake and sleep states.
AP may send buffered data frames to the client in two ways.
If the data belongs to legacy power-save queue, transmission follows the legacy power save.
If the data belongs to WMM Power Save queue, data frames are downloaded according to a trigger-and-delivery mechanism.
Main Objective: To successfully transfer every bit of information(data) from one device to another.
802.11 MAC HEADER
Let us now go through the basics of the frame header and the components. I have captured a simple beacon (management) frame using Wireshark.
I will briefly explain each of the fields. Notice the number in the bracket refers to the bytes. For memory 1 Byte = 8 bits. 🙂
802.11 Beacon frame captureFrame Control Field dissection
Frame Control > 16 bits | 2 Bytes – contains 11 subfields as displayed in the above examples. Considering the amount of valuable information contained in 802.11 Frame Control sub-fields is mind-boggling
Protocol Version (2 bits): For now, always set to 0 by default. Changes in the version are expected in the future.
Type: Management (0,0), Data(1,0), Control(0,1), Extension Frame(1,1)*only available with 802.11D
Sub Type (4 bits): There are different kinds of management, control and data frames. Therefore the 4-bit Subtype field is required to differentiate. The above examples have Beacon & ACK subtypes.
To DS – if set to “1” – Frame going from STA > Distribution System (DS) From DS – if set to “1” – Frame going from DS > STA
To DS = 0, From DS = 0 > Management or Control frames where it does not go to DS, Can be STA to STA communication in an ADHOC/IBSS setup. To DS =0, From DS = 1 > Downstream traffic from AP to the STA. To DS =1, From DS = 0 > Upstream traffic from STA to AP To DS =1, From DS = 1 > Data frame using 4 MAC header format, usually occurs in WDS or Mesh Network.
More Fragments– If set to “1” it is usually preceded by another fragment of current MSDU or MMPDU to follow.
Retry – 0 or 1. 1 is for retransmissions. Lot of 1’s may indicate a network with a lot of retry rate due to some issue. The issues can impact the performance by increased application/network latency thereby degrading user experience.
Power Management– if set to “1”, STA is using power save mode.
More Data: if set to “1” it indicates that the AP or STA is holding more frames for the STA to which the current frame is targeted.
Protected Frame – if set to “1” it indicates payload is encrypted.
Order – If set to “1” in any non-QoS data frame when a higher layer has requested that the data be sent using strictly ordered CoS, which tells the receiving STA to process the frames in order.
Duration/ID > 2 Bytes | 16 bits – May be used for 2 purposes, it may contain the duration of the frame. Secondly, it may contain association identifier (AID) of the STA that transmitted the frame.
Address 1,2,3 and 4: Each address contains 6bytes/48 bits of data.
SA > Source Address DA > Destination Address TA > Transmitting Address RA > Receiving Address BSSID >
Sequence Control Field (2 Bytes/16 bits): Divided into 4-bit fragment number and a 12-bit sequence number. Used when MSDUs are fragmented. 802.11-2016 allows for fragmentation of frames.
QoS Control Field: (2 Bytes/16 bits): Only used in MAC header of QoS frames. Sometimes referred to as WMM (Wi-Fi Multimedia) which provides traffic prioritization.
HT Control Field (4 bytes/32 bits): Parameters related to HT & VHT operations. Only used in Management + QoS control frames.
Frame Body: Contains the actual MSDU payload to be transmitted.
FCS: (Frame check sequence field 4Bytes/32 Bits) – Final field on the frame header. Also known as Trailer as the word says. Used to detect errors in communication.
![IEEE 8ø2.11 Request-to-send, Flags: ..... ...C
Type/Subtype: Request—to—send (Oxøølb)
v Frame Control Field: exb40e
. .øø = Version: 0
= Type: Control frame (1)
= Subtype: 11
løll
Flags:
øxoo
. .øø = DS status: Not leaving DS or network is operating in AD—HOC mode (To DS:
ø . — More Fragments: This is the last fragment
— Retry: Frame is not being retransmitted
- PWR MGT: STA wilt stay up
. = More Data: No data buffered
. — Protected flag: Data is not protected
Order flag: Not strictly ordered
.øøø løøø oøøø ooøø -
Duration: 2ß48 microseconds
Receiver address: App 92:ga)
Transmitter address: 7a:8a:2ø:øf:bg:6f
Frame check sequence: øx4d4e67bf (unverified]
[FCS Status: Unverified]
e From DS: e)
(exø)](https://i0.wp.com/keepcalmandping.online/wp-content/uploads/2020/02/image-3.png?w=1600&ssl=1)
![IEEE 8ø2.11 Probe Request, Flags: ..... ...C
Type/Subtype: Probe Request (øxeeø4)
Frame Control Field: ex4øoe
. ..øø = Version: e
eløø
ø . — Type: Management frame (e)
= Subtype: 4
Flags: øxee
. øøø oøøø eøøø eeøø = Duration: e microseconds
Receiver address: Broadcast ff)
Destination address: Broadcast ff:ff)
Transmitter address: (fc:fc:48:5e:2b:33)
Source address: Apple_5e:2b:33 (fc: fc:48:
BSS Id: Broadcast (ff:ff:ff:ff:ff:ff)
= Fragment number: ø
eeøø
0101 eøøø løøl
= Sequence number: 1289
Frame check sequence: øxda049ff4 (unverified]
(FCS Status: Unverified]
IEEE 8ø2.11 wireless LAN
v Tagged parameters (141 bytes)
Tag: SSID parameter set: Hob—wireless
Tag Number: SSID parameter set (e)
Tag length: 12
SSID: Hob—wi re less
Tag: Supported Rates 1, 2, 5.5, 11, (Mbit/sec)
Tag Number: Supported Rates (1)
Tag length: 4
Suppo rted Rates: 1 (exø2)
Suppo rted Rates: 2 (exø4)
Suppo rted Rates: 5.5 (øxøb)
Suppo rted Rates: 11 (ex16)
Tag: Extended Supported Rates 6, 9, 12, 18, 24,
Tag Number: Extended Suppo rted Rates (5ø)
Tag length: 8
36,
48,
54,
(mbit/sec)
Extended
Extended
Extended
Extended
Supported
Supported
Supported
Supported
Rates:
Rates :
Rates:
Rates:
6 (øxec)
g (øx12)
12 (øx18)
18 (øx24)](https://i1.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-2.png?w=1600&ssl=1)
![IEEE 8ø2.11 Probe Request, Flags: ..... ...C
Type/Subtype: Probe Request (øxeeø4)
Frame Control Field: ex4øoe
. ..øø = Version: e
eløø
ø . — Type: Management frame (e)
= Subtype: 4
Flags: øxee
. øøø oøøø eøøø eeøø = Duration: e microseconds
Receiver address: Broadcast ff)
Destination address: Broadcast ff:ff)
Transmitter address: (fc:fc:48:5e:2b:33)
Source address: Apple_5e:2b:33 (fc: fc:48:
BSS Id: Broadcast (ff:ff:ff:ff:ff:ff)
= Fragment number: ø
eeøø
0101 eøøø løøl
= Sequence number: 1289
Frame check sequence: øxda049ff4 (unverified]
(FCS Status: Unverified]
IEEE 8ø2.11 wireless LAN
v Tagged parameters (141 bytes)
Tag: SSID parameter set: Hob—wireless
Tag Number: SSID parameter set (e)
Tag length: 12
SSID: Hob—wi re less
Tag: Supported Rates 1, 2, 5.5, 11, (Mbit/sec)
Tag Number: Supported Rates (1)
Tag length: 4
Suppo rted Rates: 1 (exø2)
Suppo rted Rates: 2 (exø4)
Suppo rted Rates: 5.5 (øxøb)
Suppo rted Rates: 11 (ex16)
Tag: Extended Supported Rates 6, 9, 12, 18, 24,
Tag Number: Extended Suppo rted Rates (5ø)
Tag length: 8
36,
48,
54,
(mbit/sec)
Extended
Extended
Extended
Extended
Supported
Supported
Supported
Supported
Rates:
Rates :
Rates:
Rates:
6 (øxec)
g (øx12)
12 (øx18)
18 (øx24)](https://i1.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-3.png?w=1600&ssl=1)
![IEEE 802.11 Authentication, Flags: ..... ...C
Type/ Subtype: Authentication (OxØØØb)
v Frame Control Field: OxbØØØ
00
1011
= Version:
00.. = Type: Management frame (0)
= Subtype: 11
Flags: ØXØØ
.øøø 0001 0011 1010
= Duration: 314 microseconds
Receiver address: RuckusWi_4f:d3:c8 (2c:5d:93:4f:d3:c8)
Destination address: RuckusWi_4f:d3:c8 c8)
Transmitter address: SamsungE_2d:6Ø:91 (5c:51:81:2d:6Ø:91)
Source address:
BSS Id:
. øøøø
= Fragment number:
1101 1001 0001
= Sequence number: 3473
Frame check sequence: Oxa186b162 [unverified]
[FCS Status: Unverified]
IEEE 802.11 wireless LAN
v Fixed parameters (6 bytes)
Authentication Algorithm: Open System (0)
Authentication SEQ: Ox0ØØ1
Status code: Successful (Ox0ØØ0)](https://i0.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-4.png?resize=521%2C417&ssl=1)
![802.11 radio information
PHY type: 8ø2. lla (5)
Turbo type: Non—turbo (ø)
Data rate: 12.0 Mb/s
channel: 108
Frequency: 554%Hz
Signal strength (dBm): —84dBm
Noise level (dBm): —89dBm
Signal/noise ratio (dB): 5dB
TSE timestamp: 6964589ø3
(Du ration: 44gsl
IEEE 8ø2.11 Disassociate, Flags: ..... ...C
Type/Subtype: Disassociate (øxøeea)
Frame Control Field: exaøøø
..øø = Version: e
lølø
= Type: management frame (e)
= Subtype: lø
Flags: øxee
.øøø oøøø eø11 eeøø = Duration: 48 microseconds
Receiver address: SamsungE_2d:øe:4ø (4c:66:41:2d:øø:4ø)
Destination address: SamsungE_2d:øø:4e (4c:66: 41:2d
Transmitter address: (2c:5d: 72:5c)
source address: 72:5c)
BSS Id:
Fragment number: ø
. eeøø =
eøøø eøøø eløl
= Sequence number: 5
Frame check sequence: øx8043a47a [unverified]
(FCS Status: Unverified]
IEEE 8ø2.11 wireless LAN
v Fixed parameters (2 bytes)
Reason code: Unspecified reason
( øxøool)](https://i1.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-6.png?w=1600&ssl=1)
![8ø2.11 radio information
Data rate: 7.0 Mb/s
channel: 108
Signal strength (percentage): 78*
IEEE 8ø2.11 Reassociation Request, Flags: op.PR.F.
Type/Subtype: Reassociation Request (Oxøø02)
Frame Control Field: ex2øda
eølø
. .øø = Version: e
= Type: management frame (e)
= Subtype: 2
Flags: øxda
Duration/ID: 5391 (reserved)
Receiver address:
Destination address: 89: ba (c9:6a:
Transmitter address: al:2a:51:84:9b:9e (al:2a:51:84:9b:9e)
source address:
BSS Id: 79)
STA address:
= Fragment number: ø
ooøø
— Sequence number: 1860
0111 eløø eløø -
HT control (+HTC): øx2473a9cd
WEP parameters
Initialization Vector: øx952d2a
Key Index: ø
WEP ICV: exac6532aø (not verified)
Data (1514 bytes)
Data: 73a428øa537ø8af4618Ø23beb54d94ba647d7ø892c5øc22cm
(Length: 1514]](https://i0.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-7.png?w=1600&ssl=1)
![info rmat
PHY type: 8ø2. lig (6)
Short preamble: True
Proprietary mode: None (0)
Data rate: 24.0 Mb/s
Channel: 6
Frequency: 2437MHz
Signal strength (dBm)
: -42dBm
Noise level (dBm)
: -96dBm
Signal/noise ratio (dB): 54dB
TSE timestamp: 94735155
(Du ration: 28gs)
IEEE 8ø2.11 Request-to-send, Flags: ..... ...C
Type/Subtype: Request—to—send (exøølb)
Frame Control Field: exb4øø
. .øø = Version: e
løll
= Type: Control frame (1)
= Subtype: 11
Flags: øxee
.øøø oøøø løll eelø = Duration: 178 microseconds
Receiver address: RuckusWi_cf:cf:d8 (2c:5d:93:cf:cf :d8)
Transmitter address:
Frame check sequence: øxbde58b2c (unverified]
(FCS Status: Unverified]](https://i2.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-8.png?w=1600&ssl=1)
![802.11 radio information
PHY type: 8ø2. lig (6)
Short preamble: True
Proprietary mode: None (0)
Data rate: 24.0 Mb/s
Channel: 1
Frequency: 2412MHz
Signal strength (dBm)
: -83dBm
Noise level (dBm)
: -90dBm
Signal/noise ratio (dB): 7dB
TSE timestamp: 92681566
[Du ration: 64gs)
IEEE 8ø2.11 Clear-to-send, Flags: .pm.R.FTC
Type/Subtype: Clear—to—send (øx001c)
Frame Control Field: exc66b
. .10 = Version: 2
= Type: Control frame (1)
. — Subtype: 12
lløø -
Flags: øx6b
Duration/ID: 11803 (reserved)
Receiver address:
Frame check sequence: øx1b21827a (unverified]
(FCS Status: Unverified]](https://i0.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-9.png?w=1600&ssl=1)
![802.11 radio information
PHY type: 8ø2. lig (6)
Short preamble: True
Proprietary mode: None (0)
Data rate: 12.0 Mb/s
Channel: 11
Frequency: 2462MHz
Signal strength (dBm)
: -85dBm
Noise level (dBm)
: -90dBm
Signal/noise ratio (dB): 5dB
TSE timestamp: 91694972
[Du ration: 32gs)
IEEE 8ø2.11 Acknowledgement, Flags: .C
Type/Subtype: Acknowledgement (exøøld)
Frame Control Field: exd4ee
. .øø = Version: e
1101
= Type: Control frame (1)
= Subtype: 13
Flags: øxoe
.øøø oøøø eøøø eeøø = Duration: e microseconds
Receiver address: (fc:
Frame check sequence: øx66678fb7 (unverified]
[FCS Status: Unverified]](https://i2.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-10.png?w=1600&ssl=1)
![8ø2.11 radio
info rmation
PHY type: 8ø2. lig (6)
Short preamble: True
Proprietary mode: None (0)
Data rate: 24.0 Mb/s
Channel: 11
Frequency: 2462MHz
Signal strength (dBm)
: -88dBm
Noise level (dBm)
: -96dBm
Signal/noise ratio (dB): 8dB
TSE timestamp: 54ø37578
(Du ration: 92gsl
IEEE 8ø2.11 Nutt function (No data), Flags: o.m. .MFTC
Type/Subtype: Nutt function (No data) (øxee24)
Frame Control Field: ex4ba7
.. 11 = Version: 3
Type: Data frame (2)
lø.. =
eløø
= Subtype: 4
Flags: øxa7
Duration/ID: 11355 (reserved)
Receiver address: 1b:
Transmitter address: ce:2f :9e
Destination address: 89:ae:ø6:4e:6d:7e (89:ae:ø6:4e:6d:7ø)
source address: by: 13:
= Fragment number: 12
lløø
1110 lløl eølø
= Sequence number: 3794
Frame check sequence: øxa0bff4b1 [unverified]
(FCS Status: Unverified]](https://i0.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image.png?w=1600&ssl=1)
![v 8ø2.11 radio information
PHY type: 8ø2. lig (6)
Short preamble: True
Proprietary mode: None (0)
Data rate: 24.0 Mb/s
Channel: 11
Frequency: 2462MHz
Signal strength (dBm): —88dBm
Noise level (dBm)
: -96dBm
Signal/noise ratio (dB): 8dB
TSE timestamp: 54143357
(Du ration: 1ø4gsl
IEEE 8ø2.11 Power-save poll, Flags:
...P.M.TC
Type/Subtype: Power—Save pott (exøøla)
Frame Control Field: exa415
..øø = Version: e
= Type: Control frame (1)
= Subtype: lø
lølø
Flags: øx15
. løø eløø lløø eløl = Duration: 17605 microseconds
Receiver address: fc.
•55
BSS Id:
Transmitter address: 24.
•f5:e8
(unverif iedl
Frame check sequence: øxb471eø46
(FCS Status: Unverified]](https://i0.wp.com/keepcalmandping.online/wp-content/uploads/2020/01/image-11.png?w=1600&ssl=1)
