My Network Keeps Dropping: Could It Be a Deauth Attack?
Your WiFi keeps dropping. Devices disconnect, reconnect, then drop again. The router logs show nothing unusual. You've restarted the router twice. The problem persists.
There are several possible causes - interference, channel congestion, hardware issues, bad drivers - but deauthentication attacks are real and produce exactly this symptom. This article walks through the diagnostic process: what deauth-caused disconnects look like versus other causes, and how to use the BLEShark Nano's Deauth Checker to confirm or rule out an attack in a few minutes.
Note: The BLEShark Nano's active deauth feature is disabled in EU-region firmware per RED regulations. The Deauth Checker (passive monitoring) works in all regions.
Table of Contents
- The Symptom Profile of a Deauth Attack
- Other Causes That Look Similar
- The Quick Check: BLEShark Deauth Checker
- Deeper Diagnosis: Packet Capture
- Microwave Interference
- Channel Congestion
- Driver and Firmware Issues
- What to Do If It's Confirmed Deauth
The Symptom Profile of a Deauth Attack
Deauth attacks produce a specific disconnection pattern that's somewhat distinctive when you know what to look for:
Multiple devices drop at the same time. A broadcast deauth (addressed to ff:ff:ff:ff:ff:ff) disconnects all clients on the AP simultaneously. If your phone, laptop, and smart TV all lose connection at exactly the same moment, that's more consistent with a broadcast deauth than with an individual device issue.
Devices reconnect quickly but then drop again. After a deauth, devices immediately attempt to reconnect. If the attacker is sending continuous deauth frames, the reconnection attempt fails (more deauth frames arrive during the reassociation). Devices get stuck in a disconnect-reconnect loop. This is distinct from a router reboot, where devices can reconnect successfully after the router comes back online.
The router's admin interface is accessible. During a deauth attack, the router is functioning normally - it's just being prevented from maintaining client connections. If you can access the router's admin page (usually 192.168.1.1 or 192.168.0.1) from a wired connection, the router is up. If you can't access it from any device, the router itself is the problem.
Signal strength looks normal. A deauth attack doesn't reduce signal strength - the frames travel through the same air as normal WiFi. Your device may show a strong signal to the AP while simultaneously failing to maintain a connection. A signal strength problem (physical obstruction, distance) causes slow speeds or intermittent connectivity, but the device stays connected.
Problem is time-bounded. Deauth attacks don't happen continuously forever. They're typically active while someone is in range with the attacking device. If the disconnection problem stops after a while and doesn't return for days, it's more likely a transient attack than a hardware fault.
graph TD
subgraph "Diagnostic Flowchart: Is It a Deauth Attack?"
START["Network keeps
dropping"] --> CHECK1{"Multiple devices
affected?"}
CHECK1 -->|"Yes"| CHECK2{"All on same
WiFi band?"}
CHECK1 -->|"No, just one"| DRIVER["Check WiFi driver
or device issue"]
CHECK2 -->|"Yes"| CHECK3{"Drops happen
in bursts?"}
CHECK2 -->|"No, mixed"| ISP["Check ISP or
router hardware"]
CHECK3 -->|"Yes, periodic"| CHECK4{"Wired devices
also drop?"}
CHECK3 -->|"No, random"| INTERFERENCE["Check for
2.4GHz interference
(microwave, Bluetooth)"]
CHECK4 -->|"No, WiFi only"| LIKELY["Likely deauth
or WiFi attack"]
CHECK4 -->|"Yes"| ROUTER["Router or ISP
problem"]
LIKELY --> VERIFY["Verify with
packet capture"]
VERIFY --> WIRESHARK["Filter: deauth frames
(type/subtype 0x0c)"]
WIRESHARK --> FOUND{"Deauth frames
found?"}
FOUND -->|"Many from
same source"| ATTACK["Confirmed:
Deauth attack"]
FOUND -->|"None or few"| LEGIT["Legitimate
network issue"]
ATTACK --> MITIGATE["Enable 802.11w PMF
Switch to 5GHz
Use WPA3"]
end
Diagnostic flowchart to determine if network drops are caused by a deauth attack, with verification and mitigation steps
Other Causes That Look Similar
Before assuming deauth, consider these other causes that produce similar symptoms:
Router firmware bug: Some router firmware versions have memory leaks or bugs that cause the WiFi subsystem to restart periodically, disconnecting all clients. Check the manufacturer's firmware notes for known issues. A firmware update often fixes this.
DHCP lease exhaustion: If your DHCP pool is too small or leases aren't being released properly, new devices can't get IP addresses and existing leases may not renew. This causes devices to drop connectivity even with a working WiFi association. Check the router's DHCP client list and pool size.
2.4GHz interference: Microwave ovens, baby monitors, cordless phones, and neighboring WiFi networks all operate in 2.4GHz and can disrupt connections. Interference is usually channel-specific and correlates with the interfering device's operation (microwave only disrupts WiFi while you're using it).
Driver bugs: Particularly on Linux and some older Windows drivers, WiFi driver bugs cause spontaneous disconnections or failed reconnections. These typically affect one device, not all devices simultaneously.
AP hardware failure: Overheating, failing capacitors, or RF component degradation in the router can cause intermittent disconnections. If the problem gets worse over time and the router is old, this is worth investigating.
The Quick Check: BLEShark Deauth Checker
The BLEShark Deauth Checker puts the radio into passive monitor mode on the 2.4GHz channel your AP is using. It listens for deauth and disassociation frames without transmitting anything. If an attack is happening on that channel, you'll see an alert within seconds.
Steps:
- Find your AP's channel. Check the router admin interface, or use the BLEShark WiFi scanner to find your SSID and note the channel number.
- Navigate to the WiFi menu on BLEShark Nano and select Deauth Checker.
- Lock to the channel your AP is using (or leave it in hopping mode to scan all channels).
- Wait 2-3 minutes, ideally during a time when the disconnection problem is actively occurring.
If the Deauth Checker fires an alert - showing a count of deauth frames and their source MAC address - you have strong evidence of an attack. If the Deauth Checker shows nothing after several minutes during an active disconnection problem, the cause is likely not a deauth attack, and you should focus on the other causes listed here.
The Deauth Checker shows you the source MAC of the frames. Write this down. If the source MAC matches your AP's BSSID (visible in the WiFi scanner), the attacker is spoofing your AP's identity (standard deauth attack). If the source MAC is different, it may be a different type of management frame abuse or a client sending deauth to the AP (less common).
graph TD
subgraph "Diagnostic Flowchart: Is It a Deauth Attack?"
START["Network keeps
dropping"] --> CHECK1{"Multiple devices
affected?"}
CHECK1 -->|"Yes"| CHECK2{"All on same
WiFi band?"}
CHECK1 -->|"No, just one"| DRIVER["Check WiFi driver
or device issue"]
CHECK2 -->|"Yes"| CHECK3{"Drops happen
in bursts?"}
CHECK2 -->|"No, mixed"| ISP["Check ISP or
router hardware"]
CHECK3 -->|"Yes, periodic"| CHECK4{"Wired devices
also drop?"}
CHECK3 -->|"No, random"| INTERFERENCE["Check for
2.4GHz interference
(microwave, Bluetooth)"]
CHECK4 -->|"No, WiFi only"| LIKELY["Likely deauth
or WiFi attack"]
CHECK4 -->|"Yes"| ROUTER["Router or ISP
problem"]
LIKELY --> VERIFY["Verify with
packet capture"]
VERIFY --> WIRESHARK["Filter: wlan.fc.type_subtype == 0x0c
(deauth frames)"]
WIRESHARK --> FOUND{"Deauth frames
found?"}
FOUND -->|"Many from
same source"| ATTACK["Confirmed:
Deauth attack"]
FOUND -->|"None or few"| LEGIT["Legitimate
network issue"]
ATTACK --> MITIGATE["Enable 802.11w (PMF)
Switch to 5GHz
Use WPA3"]
end
Diagnostic flowchart to determine if network drops are caused by a deauth attack, with verification and mitigation steps
Deeper Diagnosis: Packet Capture
If you want more detail than the Deauth Checker alert provides, use the BLEShark's PCAP capture mode to record management frames. Download the PCAP via the file portal and open it in Wireshark.
Filter for deauth frames:
wlan.fc.type_subtype == 0x000c
Look at:
- Rate of deauth frames: 10+ per second sustained is an attack. 1-2 isolated frames is normal.
- Source MAC: Matches your AP? Spoofed attack. Unknown MAC? Rogue device.
- Destination MAC: ff:ff:ff:ff:ff:ff = broadcast deauth (all clients). Specific client MAC = targeted attack on one device.
- Reason code: Code 1 (unspecified) repeated for every frame is typical of automated attack tools.
- Timing: Do the deauth frames correlate with when you experience disconnections? Export the timeline and compare against your device's disconnect logs.
If you see 500 deauth frames in 30 seconds, all from the same source MAC, all addressed to broadcast or your specific client MAC, all with reason code 1 or 3, that's a deauth attack. No ambiguity.
Microwave Interference
Microwave ovens are notorious 2.4GHz disruptors. A microwave running at full power leaks significant RF energy in the 2.4GHz band, particularly around channels 6-11. If your WiFi drops every time you reheat food, this is the culprit, not a deauth attack.
How to distinguish from deauth:
- Problem correlates exactly with microwave use - starts when you start cooking, stops when microwave stops
- Affects devices physically closer to the microwave more than devices farther away
- Deauth Checker shows no deauth frames during the disconnection event
- Moving to a 5GHz network eliminates the problem (microwaves don't disrupt 5GHz)
Fix: use 5GHz WiFi if your devices support it, or switch the AP to channels 1 or 6 which have less overlap with typical microwave emission frequency.
Channel Congestion
In dense apartment buildings or office environments, dozens of neighboring WiFi networks compete for the three non-overlapping 2.4GHz channels (1, 6, and 11). High channel utilization from neighboring APs causes packet collisions, retransmissions, and degraded performance that can feel like disconnections to applications with tight timeout values.
This is distinct from deauth in important ways: the problem is consistent and correlated with occupancy (worse during busy hours, better at 3am), all devices on the AP are equally affected, and the Deauth Checker shows no deauth frames.
Use the BLEShark WiFi scanner to count how many APs are on each channel in your area. If channels 1, 6, and 11 all have 10+ APs, you're in a congested environment. Switching to 5GHz WiFi dramatically reduces this problem - there are far more 5GHz channels and far fewer devices using them.
Driver and Firmware Issues
WiFi driver bugs affect individual devices, not all devices simultaneously. If only your laptop is dropping but your phone stays connected, the problem is device-specific.
Common driver-related symptoms:
- Specific device spontaneously disconnects, others unaffected
- Problem appears after OS update or driver update
- Disabling "power saving" in the WiFi adapter settings (Windows: Device Manager > adapter properties > Power Management) fixes it
- Rolling back the WiFi driver resolves the issue
Windows and Linux WiFi drivers both have known power management issues where aggressive power saving causes the adapter to miss beacon frames and disconnect. This is a common source of "WiFi keeps dropping" complaints that has nothing to do with the network.
What to Do If It's Confirmed Deauth
You've run the Deauth Checker, you see frames, and you've confirmed via Wireshark that you're being deauthed. Now what?
Enable PMF (Protected Management Frames) on your AP. This is the most effective technical mitigation. On WPA2 networks, PMF is optional but widely supported on 2020+ router firmware. Find it in your router's wireless security settings - it may be labeled "802.11w" or "Management Frame Protection." On WPA3 networks, PMF is mandatory and already active.
With PMF enabled, your client devices will negotiate protected management frames during association. Forged deauth frames (which can't pass the MIC check without the session key) will be silently ignored. The attack stops working.
Upgrade to WPA3 if your router and devices support it. WPA3 mandates PMF and provides additional session security that WPA2 lacks. If your router is from 2020 or later, it likely supports WPA3 in at least Wi-Fi 6 (802.11ax) mode.
Identify where the attack is coming from. RSSI from the deauth frames gives a signal strength estimate. Strong signal means the attacker is close. Check the BLEShark's WiFi scanner - is there an unfamiliar AP or device broadcasting nearby? The attacker's device might appear in the scan results. If you're using a Shiver mesh with multiple BLEShark Nano nodes, you can triangulate approximate location from RSSI readings across nodes.
Document and escalate if needed. If this is happening on a business network, document the attack: download the PCAP, record timestamps, note the source MAC address. This is the starting point for an incident report. If it's on a shared network (apartment building, coworking space), consider notifying the network administrator.
A deauth attack is annoying but not in itself a compromise - it's a denial-of-service, not a data theft. The main risk is if someone is using deauth to force WPA2 handshakes for offline cracking. With PMF enabled, this attack vector is also blocked.