On a network without protected management frames, a deauthentication attack knocks devices offline without touching a password, and the homeowner sees only an internet connection that seems unreliable. ShieldWave is a sensor that watches for one and tells you it happened, and nothing more, by design.
On networks that do not use protected management frames, Wi-Fi management frames are unauthenticated. Anyone within range can forge a deauthentication frame that tells every device on such a network to disconnect, repeatedly, for as long as they like. No password is needed and nothing is breached. The devices simply stop working.
To a homeowner it looks like the internet is being unreliable, which is also what it looks like when a burglar alarm's camera goes offline on purpose.
There is an obvious response to a jamming attack, and it is illegal. Transmitting to counter, jam, or interfere with a signal is a serious regulatory violation. Receiving and monitoring is lawful.
So the first requirement in the specification, ranked above user experience and above detection coverage, is that the product never transmits. Its software contains no transmit code, and both radios are configured to receive only, even though the HackRF and the Wi-Fi adapter are capable of transmitting. The user-facing guidance points to lawful remedies and never suggests locating or confronting whoever is responsible.
Validating detection did require a transmitter. That is a separate microcontroller, fenced off as a test instrument, firing only at my own access point on my own network, documented as a test harness and shipped in nothing.
Two independent detectors, because the two attacks live at different layers.
The protocol detector reads an intrusion-detection feed from a monitor-mode adapter and maps its alerts onto a threat model of deauthentication floods, disassociation floods, and rogue access points. The RF detector sweeps 2.4 and 5 GHz with a software-defined radio, in receive only, watching for broadband and narrowband jamming.
Neither fires on raw counts. Each maintains a learned baseline (management-frame rate per channel, noise floor per frequency bin) and flags only energy that exceeds that baseline and sustains across consecutive windows. A microwave oven, a neighbour's network, and a phone roaming between bands all produce bursts. Requiring persistence is what separates an attack from ordinary life in a crowded radio environment.
Detection was tested on genuine attack traffic, not a simulation. I fired a real deauthentication flood from a separate ESP32 running Marauder firmware, aimed only at my own access point. Kismet raised the exact alert ShieldWave watches for, BCASTDISCON at severity 10, within about 20 seconds, and the alert reached e-mail, push and Pushover. A phone on the test network disconnected, while machines on my other network stayed connected throughout. Kismet also flagged that the test network’s devices were not using protected management frames, which is why the flood worked.
False alarms are handled separately. An alert goes out only for a strong flood alert or a burst of weaker ones, never for a single stray frame, and at most once every 10 minutes per sensor. Both directions were tested: the real flood sent an alert, and a lone frame stayed silent.
Every attack in the project logs is one I ran myself, against my own equipment and network, which is what makes the test lawful. No attack from anyone else has been logged.
Three tiers: the sensor in the home, a small Firebase backend, and the owner’s apps. Events move one way, from the sensor to the cloud to the owner, and no custom server runs anywhere.
A sensor watching a home network could trivially capture the traffic crossing it. The events ShieldWave sends and stores carry two kinds of information: which 802.11 management frames were seen and how often, and RF signal power. Never the contents of anyone's traffic.
That promise is enforced in code rather than left to intention. The server does not store what it receives: the ingest function rebuilds each event from a fixed list of fields, takes the user and sensor identity from the device registry rather than from the request, drops nested data, and caps the size of the one free-form evidence block. Tests check the identity, timestamp and evidence rules. All three tiers are written against one documented event schema, closed to extra fields and kept in the same repository, so a change to it is visible to all three at once.
One finding from the security audit reshaped how the apps render alerts. Every interesting field in a detection event (the transmitter address, the network identifier, the alert text) arrives inside frames an attacker forged. It is attacker-controlled input that travels from the radio into a push notification, an email, and a dashboard.
So those fields are escaped and validated before they are rendered or interpolated anywhere. The sensor holds no administrative credentials; it authenticates to a single ingest function with a per-device key. The dashboard is read-only, the sensor is never exposed to the internet, and remote access runs through an SSH tunnel.
A real deauthentication flood, fired by my own test transmitter at my own access point, has been caught end to end, from radio to phone. The RF jamming detector runs on the Pi as its own service with a stable learned baseline, and text and phone-call alerts are built but wait on carrier verification. False-positive tuning over long runs is the current work, and a fusion engine that correlates the protocol and RF detectors into single confirmed events is the next phase.