Detection and coverage

This describes 2.1.0. Detection logic is shared by every board profile; S2 has Wi-Fi only. Physical and build verification are listed in validation.

Radio observations cannot establish ownership, intent, recording state or whether a device is tracking anyone.

Disconnect bursts

Packets are length-checked and their hardware FCS removed before parsing. The callback queues observations; the main loop makes detection decisions.

The default requires at least 60 deauthentication/disassociation frames in each of three complete one-second windows for the same BSSID within 30 seconds. Each window must also have at least half the threshold directed at the same station, or broadcast. Thresholds cannot be lowered below 40 per second. Isolated departures, one short burst, and one disconnect each for many clients do not satisfy these conditions. RSSI filtering applies first.

Retry-flagged copies with the same source, destination, subtype and sequence within two seconds are deduplicated. Non-retry frames with constant sequence numbers still count, because flood tools may reuse them. Protected frames, invalid addresses/reasons, fragmented and truncated management frames are excluded. Channel changes clear partial packet windows, but preserve completed strong evidence for 30 seconds. This catches repeated sweeps without combining isolated departures across different access points. Thirty-two bounded evidence records survive the shorter-lived active packet windows; old evidence expires.

The default output is ten red flashes (200 ms on, 200 ms off), then the nightlight. The 30-second cooldown follows the four-second flash sequence. A new qualifying window after cooldown can repeat the alert; stale evidence alone cannot retrigger it.

Marauder's deauth sniffer was reviewed as a reference for packet recognition. Its packet display does not establish that a flood is occurring; Skid Detector adds the sustained-window and repeated-target requirements above. No transmit functionality was imported.

These are attack-pattern alerts, not proof of intent. Sustained network faults can still resemble attacks. Slow or short attacks, protected frames, off-channel traffic and dropped observations can be missed.

Device candidates

The Dragon Detector parser retains weak, medium and strong confidence labels. Presence alerts require repeated observations spanning at least one second. By default, strong Axon observations maintain alternating red/blue police lights. Each new qualifying observation renews a 15-second presence timeout, independently of the event-log cooldown. An old cached contact cannot renew it. Once observations stop, lights return to the nightlight when that timeout expires. Flood alerts take priority and Axon lighting resumes afterward if the presence is still current. The Axon rule can disable this behavior with Keep lights active while Axon is detected. Manual output tests remain bounded and do not create presence evidence.

Ordinary Wi-Fi/BLE devices appear in Nearby without generic presence alerts. Strong Axon candidates, deauth floods and Bluetooth pairing spam are enabled by default. All other device families, including Find My/AirTags and Ring, are opt-in. Disabled matched families are hidden from Nearby and do not alert. Strong-only rules stay silent for families that have no strong signature.

The parser, vendor-prefix table and Axon helpers come from the current Dragon Detector v0.13.23 source release. Public BLE addresses can supply vendor evidence; random addresses are not treated as registered vendor assignments. The local monitor accepts packets up to 768 bytes; larger records are discarded, not partially classified.

SSID security conflicts compare repeatedly observed beacons from different BSSIDs with the same exact SSID. An open/protected mismatch is a candidate alert, not proof of an evil twin: legitimate network configurations can also differ.

Pairing bursts

Apple popup, Google Fast Pair, Microsoft Swift Pair and the Samsung EasySetup watch structure are recognized separately. Samsung's company ID alone is insufficient; the complete watch record header and length must match. The watch signature was checked against Marauder's Samsung record. When enabled, an alert requires 60 matching advertisements and 24 fresh addresses in each of three complete consecutive two-second windows within the same protocol family. A bounded rotating address history prevents stable crowds from repeatedly being counted as fresh addresses. Hash collisions can suppress freshness, making this test more conservative.

Ordinary BLE crowd size and a single burst do not trigger an alert. BLE flood alerts have been enabled by default since 2.0.2. Legitimate unusual pairing activity can still match. Slow or short spam can be missed; the separate identity-change rule below handles some fixed-address sources. Mixed-protocol traffic is evaluated separately for each protocol; no claim is made that every "spam all" mode, payload or device will meet these criteria. The default output is ten blue flashes with an independent 30-second cooldown, repeating only if newly received traffic still confirms the flood after cooldown.

An additional rule covers a source that retains its address while cycling through pairing identities. It requires 24 advertisements, four different identities and eight identity changes in each of three consecutive six-second windows from the same address and address type. Apple model/action IDs, Google's three-byte discoverable model ID, Samsung watch models and Microsoft Swift Pair display names provide identity evidence. Battery levels, authentication bytes, RSSI and Google account-key data do not count as identity changes. Advertisements containing more than one recognized identity are excluded from this rule. A stable device or a crowd of individually stable devices cannot build this evidence by sheer volume.

Identity parsing references: Google's provider advertising format, Microsoft's Swift Pair format, and the Apple/Samsung records in the Marauder source linked above. Only receive parsing is implemented. Fixed-identity spam can still evade both rules; RF identity and intent are not authenticated.

Coverage and limits

Wi-Fi remains on one channel while a web client is attached. Default idle survey uses channels 1–11, 350 ms each (roughly 3.85 seconds for a quiet sweep). A repeated disconnect candidate temporarily holds the current channel for confirmation, up to eight seconds. A brief hold is not an alert. BLE continues during Wi-Fi survey. The AP stays on its home channel for the first 30 seconds after boot. Directed requests to join this device pause hopping for 15 seconds, allowing a phone to finish connecting. Wildcard probes and requests for other networks do not pause the survey. While paused, Wi-Fi detection continues on that channel and BLE detection continues independently. C5 uses 2.4 GHz only. BLE scans continuously and passively with a 35/120 ms window/interval. The former four-second scan/two-second pause schedule could break sustained pairing-burst confirmation; 2.0.2 removes that pause. Names available only in scan responses may be absent.

Separate queues hold 128 short disconnect records, 12 BLE records and 8 other Wi-Fi records. Processing is bounded per loop to keep lights, HTTP and USB responsive. System and USB diagnostics expose per-queue drops, received/accepted counts, evidence progress, cooldowns and channel coverage. Contacts cap at 48 and disappear from the UI after two minutes. Events cap at 24. Both are RAM-only. Heavy traffic or HTTP transfers can drop observations; System exposes the count.

Duration and cooldown are separate. Continued activity can re-alert after its cooldown. Silence suppresses light/sound for five minutes while event logging continues. Manual tests override silence. Deauth alerts can preempt lower-priority patterns; otherwise one alert pattern plays at a time.