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.

stayed home to tick off some tasks from my todo list. my internet provider decided to make it hard for me. snapped a quick one showing my new iPad. // 20181210
Photo by Jonathan Kemper / 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

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

As you can see, all it can take is a code to describe a reason for the disconnect.

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:

Octets Description
2 Frame Control
2 Duration
6 Address 1
6 Address 2
6 Address 3
2 Sequence Control
0 or 4 HT Control
variable Frame 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...

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

Disassociation vs. Deauthentication

Authentication Failed – Please contact the administrator... Error code: -1 Login Retry. Binary HTML/CSS Javascript source code
Photo by Markus Spiske / Unsplash

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

Thank you ❤️

We hope you enjoyed this blog post.
Become a Github Sponsor or support us via Ko-fi!

Buy Me a Coffee at