ZeroTrace AirLeak
Settings Reference
Every persistent firmware setting, its default, and its effect
This page documents every persistent setting in the AirLeak firmware. All settings survive reboot, firmware updates, and power loss — only airleak-factory-reset clears them.
Most settings can be changed from the desktop's AirLeak → Settings → Settings tab. The full set is reachable via the CLI.
Capture mode
| Property | Value |
|---|---|
| CLI | airleak-mode |
| Type | enum |
| Values | setup, monitor |
| Default | setup |
| Persisted | yes |
Determines whether the radios are running and whether sessions are recording.
setup— radios off, no events flowing. Used when configuring or moving locations.monitor— full sweep. Channel hopper sweeps 1–13, BLE active scan runs, all alert rules armed, session auto-recorded.
After power-cycle, the firmware automatically restores the previous mode before the desktop attaches. A unit last left in Monitor wakes up capturing.
See Capture Modes for the full picture.
Active BLE scan
| Property | Value |
|---|---|
| CLI | airleak-active-scan |
| Type | bool |
| Values | on, off |
| Default | on |
| Persisted | yes |
Controls whether the unit transmits SCAN_REQs to elicit SCAN_RSPs from BLE peers.
on(default) — captures friendly device names, full Service UUID lists, richer manufacturer dataoff— passive only, smaller RF footprint, but ~80 % of devices appear nameless
Most BLE devices put their friendly name in the scan response, not the legacy advertisement. Without active scan you'd see all the AirTags and AirPods, but the laptop named DESKTOP-II1L6R8, the TV named [TV] Samsung 5 Series, and the watch named Galaxy Watch5 (VBNY) would all be unnamed.
The single SCAN_REQ packet per peer is a 30-byte burst once per scan window. It is not decoded as anything other than a scan request by surrounding equipment, but technically the unit is transmitting. Set off for fully passive mode.
BLE scan window
| Property | Value |
|---|---|
| CLI | airleak-scan-window |
| Type | integer |
| Unit | milliseconds |
| Range | 20–10240 |
| Default | 75 |
| Constraint | ≤ scan-interval |
| Persisted | yes |
How long the radio listens within each scan period. With the default 75 ms window inside a 100 ms interval, the BLE radio is receiving 75 % of the time.
- Larger window → more frames captured per period
- Smaller window → more time for WiFi capture to use the radio
The default is tuned for typical environments (≥10 BLE peers). In a dense public space (50+ peers), increasing to 100 ms matched with a 100 ms interval (100 % duty cycle on BLE) catches more advertisements but starves the WiFi side. The right choice depends on whether BLE or WiFi is your priority.
BLE scan interval
| Property | Value |
|---|---|
| CLI | airleak-scan-interval |
| Type | integer |
| Unit | milliseconds |
| Range | 20–10240 |
| Default | 100 |
| Constraint | ≥ scan-window |
| Persisted | yes |
The total period of one scan cycle (window + gap). Default 100 ms gives a fast scan rate.
A (window=75, interval=100) setup is the sweet spot we ship by default — high BLE duty cycle with enough gap for WiFi to interleave.
Event throttle window
| Property | Value |
|---|---|
| CLI | airleak-throttle |
| Type | integer |
| Unit | milliseconds |
| Range | 0–60000 |
| Default | 1000 |
| Persisted | yes |
The minimum gap between consecutive same-type events from the same MAC, on the USB stream. Events arriving sooner are aggregated into the device record but suppressed from the wire.
| Setting | Behavior |
|---|---|
0 | Firehose. Every event streamed. ~500 events/s peak. Use for debugging or short focused captures. |
500 | Aggressive — see updates twice per second per device. |
1000 (default) | Balanced — most updates per device once per second. |
2000 | Conservative — useful in dense environments to reduce stream pressure. |
5000+ | Very conservative — for headless logging where you only need periodic state. |
Important: the throttle only affects the USB stream, not the aggregator or the alert engine. Every captured event still updates last_seen, RSSI, classification, and runs through alert rules. You're choosing how often the desktop sees updates — not how fast the firmware works.
See the Throttle page for capacity numbers.
WiFi channel list
| Property | Value |
|---|---|
| CLI | airleak-channels |
| Type | comma-separated integer list |
| Range | 1–13 |
| Default | 1,2,3,4,5,6,7,8,9,10,11,12,13 |
| Persisted | yes |
Which 2.4 GHz channels the channel hopper visits.
Common alternatives:
| Setting | Use |
|---|---|
1,6,11 | The non-overlapping channels — covers most APs faster, dwells more time per channel |
1,11 | Edges only |
6 | Single channel — useful for focused capture of one AP / room |
default | Full 1–13 sweep |
Note: regulatory channels in some regions are limited (e.g. US allows 1–11). The unit doesn't enforce regulatory limits on capture (passive listening is generally allowed) but be aware of local rules.
Per-channel dwell time
| Property | Value |
|---|---|
| CLI | airleak-dwell |
| Type | integer |
| Unit | milliseconds |
| Range | 50–2000 |
| Default | 150 |
| Persisted | yes |
How long the WiFi radio stays on each channel before hopping.
| Dwell | Full-sweep time (13 channels) | Beacon catch rate |
|---|---|---|
| 50 ms | 0.65 s | misses some |
| 100 ms | 1.3 s | most catches |
| 150 ms | 2.0 s | all catches |
| 250 ms | 3.3 s | all + multiple per AP |
| 500 ms | 6.5 s | sluggish but very thorough |
A typical AP beacons every ~102 ms. Dwelling at least 150 ms guarantees catching one beacon per visit, even when the channel-hop timing is unlucky.
Alert-rule enabled state
| Property | Value |
|---|---|
| CLI | airleak-alert-enable / airleak-alert-disable / airleak-alert-list |
| Type | per-rule boolean |
| Default | most enabled (see below) |
| Persisted | yes |
Each alert rule has an enabled flag. Disabled rules don't fire and don't consume cycles.
Default enabled state per rule:
| Rule | Default |
|---|---|
airdrop_discoverable | enabled |
findmy_separated | enabled |
multi_hour_follower | enabled |
pii_ssid_in_probe | enabled |
corp_ssid_in_probe | enabled |
airport_ssid_in_probe | enabled |
hotel_ssid_in_probe | enabled |
cafe_ssid_in_probe | disabled (often noisy) |
open_network_near | enabled |
wep_network_near | enabled |
wpa_personal_only | enabled |
wps_enabled | enabled |
mfp_required_off | enabled |
deauth_burst | enabled |
tile_tracker | enabled |
samsung_smarttag_near | enabled |
unknown_tracker_near | enabled |
random_mac_no_name | disabled (info-only) |
mac_rotation_detected | enabled |
See Alert Rules for what each rule does.
Internal counters (read-only)
These survive reboot but you can't write them:
| Field | Description |
|---|---|
boot_count | Number of successful boots since factory reset |
last_firmware_version | Tracks updates — used to detect newly applied firmware |
total_uptime_hours | Cumulative uptime across all boots |
factory_reset_at_ms | Timestamp of last factory reset |
These are surfaced via airleak-info.
Default-restoring
Two ways to return to defaults:
-
Per-setting — pass
defaultto most commands:airleak-channels default airleak-throttle default airleak-scan-window default -
All settings —
airleak-factory-resetwipes the NVS partition entirely.
Setting changes don't break recording sessions. If you change the throttle mid-session, the session continues uninterrupted — only the post-change events are subject to the new throttle. Mode changes (Setup ↔ Monitor) do finalize the active session.