← Tejasvi Konjeti
ShieldWave · home RF security sensor Receive only · never transmits

A Wi-Fi attack you cannot see, and a sensor that will not fight back.

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.

≈ 20 s attack begins attack ends first alert feed empty alerts
Figure 1. Schematic of a controlled test against my own access point, drawn from the test log rather than plotted data. The alert feed was empty before the attack. About 20 seconds after a deauthentication flood began, the sensor raised BCASTDISCON, a broadcast disconnect of all clients, and attributed the spoofed frames to the targeted network. Alerts persisted for the duration and stopped when it ended. Machines on a separate network stayed connected throughout.

The attack

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.

The constraint that defines the product

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.

How it detects

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.

A real attack, not a false alarm

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.

System architecture

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.

HOME · RECEIVE ONLY FIREBASE · SERVER SIDE THE OWNER Wi-Fi adapter monitor mode, listen only Protocol detector reads Kismet's alerts deauth · disassoc floods HackRF One software radio, receive only RF detector learned noise floor 2.4 and 5 GHz Fusion engine next: combine both detectors events + heartbeats Ingest function checks the device key rebuilds each event from a fixed list of fields Cloud Firestore events · sensors Alert function runs on each new event false-alarm gate one alert per 10 minutes The apps never connect to the sensor directly, and the sensor is never reachable from the internet. iOS app live events · what to do now Web dashboard read-only read Alerts push · Pushover e-mail · text, call pending notify
Figure 2. How ShieldWave is built. The sensor listens on two layers, each with its own detector, and both send events and heartbeats over HTTPS with a key unique to that device. The server checks the key and rebuilds each event before storing it. A second function decides whether a new event is worth waking someone over: weak signals must arrive in a burst, and a sensor alerts at most once every ten minutes. The fusion engine, drawn dashed, is the next phase.

Privacy enforced by the server, not by policy

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.

The ShieldWave dashboard listing five disassociation-attack events, each showing only the attack type, how long ago it occurred, the frequency band, and a confidence level.
Figure 3. Real events recorded by the sensor, shown in the owner's dashboard. Each row shows the attack type, its age, the band and a confidence level. The badge at the top reports the sensor's live status.

Treating my own data as hostile

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.

The record

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.

GitHub's weekly commit-activity chart for the ShieldWave repository, with the repository URL shown above it, peaking in July and August 2026.
GitHub's commit-activity view for the repository, which is private. The address bar is included so the source is visible.

Stack

Sensor
Raspberry Pi 5 · Python · Kismet · HackRF One through SoapySDR · monitor-mode MT7612U adapter
Middle tier
No custom server. Firebase Cloud Functions (Node) handle ingest, alerting, device provisioning, and account deletion.
Data
Cloud Firestore, behind one canonical JSON event schema shared by all three tiers
Clients
iOS: React Native / Expo. Web: a read-only dashboard on Firebase Hosting.