WiFi Deauthentication Frame Explained

WiFi Deauthentication Frame Explained


9 min read

The structure and functionality of deauthentication frames are something we get asked about regularly. So we thought it was time for a blog post to explore what they are and how they work.

404 tablet unsplash

What is a Deauthentication Frame?

The Deauthentication Frame is a type of packet defined in the IEEE 802.11 WiFi standard. It has been part of the standard since the beginning and still plays an important role.

It's used to terminate a WiFi connection. It can be sent by either the access point or the station to let the other side know that the connection is closed.

In case you're unfamiliar with the terminology, the access point (AP) is a device that provides access to a WiFi network, for example, your home router. While a station is a client device that can connect to an access point, for example, your phone.

The station might send a deauthentication frame to the access point because it's switching to another WiFi network. Or the access point might send a deauthentication frame to the station because the router has to restart. Deauthentication works both ways, and there are plenty of reasons why they are sent - you can find a complete list of reasons below.

But one crucial attribute of the deauthentication frame is that it's not a request; it's a notification, and it can not be refused.

Structure of a Deauthentication Frame

The actual data the packet holds is very minimal:

Deauthentication frame body

1Reason code
Last – 1One or more Vendor Specific elements are optionally present.
LastThe MME is present when management frame protection is enabled at the AP and the frame is a group addressed frame.

But if you look at a deauthentication frame in Wireshark, you'd see more than just the frame body. That's because deauthentication packets are part of the family of WiFi management frames, and their format looks like this:

2Frame Control
6Address 1
6Address 2
6Address 3
2Sequence Control
0 or 4HT Control
variableFrame Body

In the ESP8266 Deauther's code, a packet looks like this:

uint8_t deauthPacket[26] = {
    /*  0 - 1  */ 0xC0, 0x00,                         // type, subtype c0: deauth (a0: disassociate)
    /*  2 - 3  */ 0x00, 0x00,                         // duration (SDK takes care of that)
    /*  4 - 9  */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // reciever (target)
    /* 10 - 15 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // source (ap)
    /* 16 - 21 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // BSSID (ap)
    /* 22 - 23 */ 0x00, 0x00,                         // fragment & squence number
    /* 24 - 25 */ 0x01, 0x00                          // reason code (1 = unspecified reason)

Deauthentication frame definition in ESP8266 Deauther code You can find this definition in the Attack.h file.

You might notice that some data is left out of this array. For example, the frame check sequence (FCS) is not defined here. That's because it's already handled by the underlying ESP8266 SDK functions automatically. The same goes for the duration and the flags in the second byte of the frame control field.

Reason codes

As mentioned, every deauthentication frame has to contain a code for the reason of disconnect. Here is a list of the available reason codes and what they mean.

Yes, the list is quite long...

1Unspecified reason
2Previous authentication no longer valid
3Deauthenticated because sending STA is leaving (or has left) the BSS
4Disassociated due to inactivity
5Disassociated because AP is unable to handle all currently associated STAs
6Class 2 frame received from nonauthenticated STA
7Class 3 frame received from nonassociated STA
8Disassociated because sending STA is leaving (or has left) BSS
9STA requesting (re)association is not authenticated with responding STA
10Disassociated because the information in the Power Capability element is unacceptable
11Disassociated because the information in the Supported Channels element is unacceptable
12Disassociated due to BSS transition management
13Invalid element, i.e., an element defined in this standard for which the content does not meet the specifications in Clause 9
14Message integrity code (MIC) failure
154-way handshake timeout
16Group key handshake timeout
17Element in 4-way handshake different from (Re)Association Request/Probe Response/Beacon frame
18Invalid group cipher
19Invalid pairwise cipher
20Invalid AKMP
21Unsupported RSNE version
22Invalid RSNE capabilities
23IEEE 802.1X authentication failed
24Cipher suite rejected because of the security policy
25TDLS direct-link teardown due to TDLS peer STA unreachable via the TDLS direct link
26TDLS direct-link teardown for unspecified reason
27Disassociated because session terminated by SSP request
28Disassociated because of lack of SSP roaming agreement
29Requested service rejected because of SSP cipher suite or AKM requirement
30Requested service not authorized in this location
31TS deleted because QoS AP lacks sufficient bandwidth for this QoS STA due to a change in BSS service characteristics or operational mode (e.g., an HT BSS change from 40 MHz channel to 20 MHz channel)
32Disassociated for unspecified, QoS-related reason
33Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA
34Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions
35Disassociated because STA is transmitting outside the limits of its TXOPs
36Requesting STA is leaving the BSS (or resetting)
37Requesting STA is no longer using the stream or session
38Requesting STA received frames using a mechanism for which a setup has not been completed
39Requested from peer STA due to timeout
46In a Disassociation frame: Disassociated because authorized access limit reached
47In a Disassociation frame: Disassociated due to external service requirements
48Invalid FT Action frame count
49Invalid pairwise master key identifier (PMKID)
50Invalid MDE
51Invalid FTE
52Mesh peering canceled for unknown reasons
53The mesh STA has reached the supported maximum number of peer mesh STAs
54The received information violates the Mesh Configuration policy configured in the mesh STA profile
55The mesh STA has received a Mesh Peering Close frame requesting to close the mesh peering.
56The mesh STA has resent dot11MeshMaxRetries Mesh Peering Open frames, without receiving a Mesh Peering Confirm frame.
57The confirmTimer for the mesh peering instance times out.
58The mesh STA fails to unwrap the GTK or the values in the wrapped contents do not match
59The mesh STA receives inconsistent information about the mesh parameters between mesh peering Management frames
60The mesh STA fails the authenticated mesh peering exchange because due to failure in selecting either the pairwise ciphersuite or group ciphersuite
61The mesh STA does not have proxy information for this external destination.
62The mesh STA does not have forwarding information for this destination.
63The mesh STA determines that the link to the next hop of an active path in its forwarding information is no longer usable.
64The Deauthentication frame was sent because the MAC address of the STA already exists in the mesh BSS.
65The mesh STA performs channel switch to meet regulatory requirements.
66The mesh STA performs channel switching with unspecified reason.
67Transmission link establishment in alternative channel failed.
68The alternative channel is occupied.

Disassociation vs. Deauthentication

Authentication failed unsplash bMvuh0YQQ68

Besides the deauthentication frame, there is also the disassociation frame. They sound similar, work similar, and their structure is basically identical.

To understand the difference between Disassociation and Deauthenticatios, we have to understand the difference between WiFi association and authentication.

When you connect to a WiFi network, you first authenticate yourself. This is done by entering a password, for example. Then, to use the WiFi network, you now have to associate to an access point. It's simply another step before you can start browsing the web through WiFi. Of course, this is all done automatically and really fast.

In the case of a regular home router, you both authenticate and associate to the same access point. And if you disconnect, you both deauthenticate and disassociate to the same access point. But in a larger network made out of multiple access points, you might disassociate from one access point and associate to a new one while staying authenticated to the same network.

How deauthentication frames can be exploited

ESP8266 Deauther

Deauthentication frames are very simple in their structure. You basically only need a sender or receiver MAC address. And you can obtain such by simply scanning for WiFi devices nearby.

So it's super easy to spoof a deauth packet. And keep in mind that if the target receives it, it has to drop its connection.

The target can reconnect immediately, of course, and it can do that quite fast, maybe without the user noticing that the connection was ever dropped. But if these deauth packets are sent continuously, it results in a denial of service attack, and network access is blocked for the entirety of the attack.

Luckily this was addressed, and we now have protected management frames! This feature allows packets like deauthentication frames to be safe against spoofing.

The only problem with this feature is that not every access point has it enabled yet. If you want to test if your network is safe against this type of attack, check out our ESP8266 Deauther project.