Detection and coverage

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 per second in each of three complete consecutive one-second windows for one BSSID. 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. Quiet gaps and channel changes reset confirmation.

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.

Family Evidence Limitation
Axon / body camera Axon CID 034D, FC81/FE6B/FE6C services, BWCDEVICE marker, registered OUI, body-camera vendor or name Confidence depends on combination; model/recording unknown
Flipper 0x3081–0x3083 advertised services; Flipper name fallback Advertising can be changed or absent
Pineapple Pineapple/Hak5 name; 00:13:37 OUI Not a universal model detector
Flock Name; Xuntong manufacturer + specific battery-name combination Generic module alone is insufficient
Meta Luxottica company ID; Meta company/service/name heuristics Other Meta products may match
Pwnagotchi Name; stronger peer MAC + structured peer fields Spoofable
Nyanbox / HaleHound Advertised name Low confidence
Tracker Find My payload/service or DULT service Owner/intent unknown
Serial-module / skimmer HC-05, HC-06, HC-08 name Often benign; alert disabled by default
Biscuit Name plus specific service Pro/Ultra model unverified
SmartTag Samsung FD5A service Owner unknown
Acoustic sensors Raven service combination Field validation pending
Google Find Hub Valid FEAA 40/41 frames and EID length; weaker Chipolo indicators Owner unknown
Tile Assigned services Owner unknown
Ring / camera / ALPR vendor Registered vendor-prefix database or name Vendor does not identify model/activity
Drone / Remote ID Decoded BLE, Wi-Fi beacon or NAN Remote ID; weaker vendor/service indicators Self-reported identity; no map in this UI
iBeacon Valid iBeacon payload Common benign beacon; alert disabled by default
Dragon fox Dragon training-beacon signature Training marker, not a threat; alert disabled

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 and Microsoft Swift Pair structures are recognized separately. 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. This detector is enabled by default in 2.0.2. Legitimate unusual pairing activity can still match; slow, short or fixed-address spam can be missed.

Coverage and limits

Wi-Fi remains on one channel while a web client is attached. Optional idle survey uses channels 1–11, six seconds each: roughly 66 seconds between visits. 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.

The queue has 20 slots; processing consumes at most 12 per loop. 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.