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.

Deauthentication/disassociation packets share a per-BSSID counter. Identical source/destination/sequence combinations within two seconds are deduplicated. Protected frames are excluded because their encrypted reason payload is unavailable.

The default requires 30 distinct frames in each of two consecutive 2-second windows for one BSSID. The first window never alerts. Quiet gaps and channel changes reset confirmation. Thresholds cannot be lowered below 20 per window. RSSI filtering applies first.

This suppresses isolated departures and brief bursts. Legitimate mass disconnects or sustained network faults can still look similar. Reason codes do not establish intent. Slow 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.

Ordinary Wi-Fi/BLE devices appear in Nearby without generic presence alerts. Meta defaults to medium confidence. 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. At least 16 distinct addresses in five seconds within a matching payload family are required. Ordinary BLE crowd size is not an alert criterion. Crowded venues can still produce legitimate matching traffic.

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 passively scans four seconds per six-second cycle, 35/120 ms window/interval. 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.