← Back to all posts

Blocking WiFi De-Auth Attacks in the Kernel with eBPF and XDP

April 7, 2026 · by Alessandro Sangiorgi · 7 min read

802.11 de-authentication attacks are one of the oldest and cheapest WiFi denial-of-service techniques. An attacker sends forged de-auth management frames to disconnect clients from an access point — aireplay-ng sends 128 per attack command (64 directed at the AP, 64 at the client). Despite being a known problem for over two decades, the main defense is still 802.11w (Protected Management Frames), which requires both AP and client support and still degrades under high-rate floods.

I took a different approach: detect and drop de-auth floods in the kernel using eBPF and XDP — at the mac80211 wireless driver level, before the frames ever reach the network stack. This is the first application of eBPF to the 802.11 protocol. The paper was published at IEEE NetSoft 2025 as first author.

Why Not Just Use libpcap or 802.11w?

libpcap is the traditional approach — capture packets in user space and analyze them. But it introduces latency from kernel-to-user-space copying, requires monitor mode (not all drivers support it), and is purely passive — it can detect but can’t drop packets. Under attack, the copy overhead spikes exactly when you need speed.

802.11w encrypts management frames to prevent spoofing, but it struggles with high-rate de-auth floods. Our experiments show that under sustained attack, 802.11w throughput drops below 5 Mbps with erratic spikes, while our eBPF/XDP solution maintains a consistent 10–12 Mbps. Additionally, many legacy devices and drivers lack PMF support — some APs are forced to disable 802.11w entirely to maintain compatibility.

XDP (eXpress Data Path) runs eBPF programs at the earliest possible point in the Linux network stack — at the driver level, before a sk_buff is even allocated. But XDP doesn’t work on WiFi interfaces. The Linux mac80211 subsystem has no ndo_bpf callback. So I patched the kernel.

Patching mac80211 for XDP Support

I modified two files in the mac80211 kernel module — the framework that implements IEEE 802.11 for wireless LAN drivers. Implementing XDP at the mac80211 level (rather than in individual drivers) ensures compatibility across all wireless drivers that use this module.

iface.c: The ndo_bpf Callback

This patch adds the infrastructure to attach and detach BPF programs on a wireless interface. It registers a .ndo_bpf handler in the ieee80211_dataif_ops structure — the net device operations table for mac80211 data interfaces:

static int generic_xdp_setup(struct net_device *dev, struct netdev_bpf *bpf)
{
    struct bpf_prog *old_prog, *new_prog;
    new_prog = bpf->prog;

    old_prog = xchg(&dev->xdp_prog, new_prog);
    if (old_prog)
        bpf_prog_put(old_prog);

    return 0;
}

static int ieee80211_xdp(struct net_device *dev, struct netdev_bpf *xdp)
{
    switch (xdp->command) {
    case XDP_SETUP_PROG:
        return generic_xdp_setup(dev, xdp);
    default:
        return -EINVAL;
    }
}

The xchg() atomically swaps the old program pointer with the new one. ieee80211_xdp is then registered in the device ops:

static const struct net_device_ops ieee80211_dataif_ops = {
    // ... existing ops ...
    .ndo_bpf = ieee80211_xdp,
};

The ndo_bpf routine is invoked from user space via Netlink sockets using iproute2 or bpftool. After this patch, ip link set dev wlan0 xdp obj program.o works on wireless interfaces.

rx.c: XDP Execution in the Receive Path

This patch hooks into ieee80211_rx_napi() — the main receive function that processes incoming packets using NAPI (New API) for efficient interrupt handling. It checks for an attached XDP program and runs it on every incoming frame:

xdp_prog = ieee80211_get_xdp_prog(sdata->dev);
if (xdp_prog) {
    struct xdp_buff xdp;
    xdp.data = skb->data;
    xdp.data_end = skb->data + skb->len;

    act = bpf_prog_run_xdp(xdp_prog, &xdp);
    switch (act) {
    case XDP_PASS:
        break;
    case XDP_DROP:
        kfree_skb(skb);
        return;
    }
}

The packet data is accessed through the sk_buff structure, which contains the complete 802.11 frame including headers and payload. Two actions are handled: XDP_DROP flushes the skb immediately, XDP_PASS allows normal processing to continue.

The eBPF De-Auth Detector

With XDP working on wireless interfaces, the detection program parses 802.11 management frames and identifies de-authentication packets by their frame control field:

struct ieee80211_mgmt {
    uint16_t frame_control;
    uint16_t duration_id;
    uint8_t da[6];       // Destination address
    uint8_t sa[6];       // Source address
    uint8_t bssid[6];    // AP MAC
    uint16_t seq_ctrl;
    uint16_t reason_code;
};

The Frame Control field encodes the type (bits 2–3) and subtype (bits 4–7). Management frames have type 0, de-authentication has subtype 0xC (12):

uint8_t type = (mgmt->frame_control & 0x000C) >> 2;
uint8_t subtype = (mgmt->frame_control & 0x00F0) >> 4;

if (subtype == 0xC && type == 0) {
    // De-authentication frame detected
}

State is tracked in a per-CPU array map (lock-free counters):

struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(key_size, sizeof(uint32_t));
    __uint(value_size, sizeof(uint64_t));
    __uint(max_entries, 2);
} packet_count SEC(".maps");

When de-auth frames exceed a threshold, the program logs the attack metadata (BSSID, source/destination MACs, reason code, nanosecond timestamp) and returns XDP_DROP. The frame is gone before the network stack ever sees it.

Compile and attach:

clang -O2 -target bpf -c deauth_ebpf.c
ip link set dev wlan0 xdp obj deauth_ebpf.o

Once deployed, the protected device can only be disconnected manually — all de-authentication frames are filtered out.

Evaluation

eBPF vs. libpcap: Detection Time

Setup: Two Debian Bookworm VMs (kernel 6.1.52, 4 GB RAM, 12 logical CPUs) with external ATHEROS UB93 [0108] USB wireless cards using the ath9k_htc driver. One VM as the victim, one as the attacker running a modified aireplay-ng with nanosecond timestamps. Both eBPF and libpcap detectors ran on the victim, logging de-auth events with nanosecond precision.

eBPF reduces detection time by 60% on average compared to libpcap, with peak improvements of up to 7x. The CDF of detection times shows XDP/eBPF reaching 100% distribution at significantly lower thresholds — it is consistently faster, not just on average. Both solutions maintain a relatively constant memory footprint, with libpcap exhibiting slightly higher average usage.

eBPF/XDP vs. 802.11w: Throughput Under Attack

Setup: Two Raspberry Pi 4s running OpenWrt — one as AP, one as client — with ath9k-htc USB wireless cards (because the onboard Broadcom brcmfmac doesn’t support WPA3/PMF configurations required for 802.11w testing). The client ran iperf3 against an Android 15 device as the server. An attacker on a separate laptop with an Intel wireless card in monitor mode launched sustained de-auth floods with aireplay-ng over a 5-minute window.

Throughput comparison under sustained attack:

MetriceBPF/XDP802.11w
StabilizationFast, consistentSlow, erratic
Sustained throughput10–12 MbpsFrequent drops below 5 Mbps
VarianceMinimal fluctuationsFrequent dips and spikes

Both solutions initially reach ~20 Mbps, but eBPF/XDP stabilizes faster and maintains a consistent throughput with fewer deviations. 802.11w exhibits erratic performance with frequent dips, making it less reliable for latency-sensitive applications like security cameras or streaming sessions — exactly the IoT scenarios where de-auth attacks are most damaging.

The OpenWrt Integration

For real-world deployment on embedded hardware, the mac80211 patches are integrated into a custom OpenWrt build targeting Raspberry Pi. This includes:

  • The two mac80211 kernel patches applied to the OpenWrt build system
  • BPF toolchain configuration for cross-compilation (clang/LLVM pipeline)
  • Build infrastructure for compiling eBPF programs against OpenWrt kernel headers

Flash a Raspberry Pi with the custom image, attach an ath9k_htc USB WiFi adapter, load the eBPF program, and you have a wireless intrusion prevention sensor on a $35 board.

Limitations and Future Work

  • No source verification — the current solution does not verify the legitimacy of the source of de-authentication packets. A future MAC address whitelist mechanism would allow selective protection for critical devices (IoT cameras, medical equipment) while preserving standard de-auth behavior for other clients.
  • Threshold tuning — the current fixed threshold works for research. Production deployments would need adaptive thresholds based on network characteristics.
  • Single-run throughput data — the throughput comparison results come from single runs. We release the code for reproducibility and further testing.

Source Code


A. Sangiorgi, A. Pinto, R. Tourani, F. Esposito, “Mitigating De-authentication DoS Attacks in 802.11 via eBPF and XDP,” IEEE NetSoft 2025. First author. Department of Computer Science, Saint Louis University.

This work was supported by NSF awards OAC-2201536 and CPS 2133407.

DOI: 10.1109/NetSoft61042.2025.11080545