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.

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

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:

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

Disassociation vs. Deauthentication

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

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.