Power-on order, establishing a known-clean baseline, reading the warning line, what to do on a warning, the Wi-Fi-AP sleep quirk, and clearing recordings between trips

7.1 About this Volume

This volume is about operating a running detector in the places it is meant for — travel, transit hubs, rallies, any setting where the operator wants a chance of noticing a cell-site simulator. The detector is passive: it participates in the cellular network exactly as any hotspot does, and watches the control-plane traffic that participation generates. The operator’s job is not to “scan” — the device does that continuously — but to interpret the status it shows and to respond sensibly when it changes.

Three ideas run through everything here. First, a baseline: the detector is far more useful once the operator knows what “normal” looks like in a known-clean place. Second, the warning line is a status light with a severity ladder, not a verdict. Third, and most important, a warning is signal, not proof — the correct response is a posture shift, not a conclusion. Volume 5 (sibling-authored) explains how the analyzers decide; this volume is about what the operator does with their output.

7.2 Power-on order

Rayhunter starts recording the moment the device powers on — there is no separate arm step. The sensible field order follows from that:

1.  Power on the Rayhunter hotspot in a KNOWN-CLEAN place (home / office).
       → green line appears; it is now recording a baseline.
2.  Let it settle: confirm green, confirm the web UI loads, note the serving cell
       if you track that (Vol 8).
3.  Pocket/stow it and travel. It keeps recording the whole way.
4.  On arrival / at the sensitive location, glance at the status line.
       → still green  = nothing has tripped since you left clean ground
       → not green    = something tripped en route or here (Vol 5, Vol 8)
5.  After the trip: review recordings, then clear them (§8).

Powering the detector on before leaving clean ground is deliberate. It means the recording that covers the sensitive location is continuous with a known-good stretch, which makes later review (Vol 8) far easier: the analyzer behaviour during the clean segment is the reference against which the suspicious segment is read.

7.3 Establish a known-clean baseline first

A detector that has never seen “normal” is hard to trust the first time it warns. The baseline practice closes that gap:

Run it at home / in a trusted location for a while before relying on it. Learn what the status line does during ordinary use: normal tower handovers, moving between cells, weak-signal areas. Some of those produce informational analyzer notices that are not warnings (Vol 5’s Diagnostic Information analyzer logs ordinary connect/disconnect events).
Note the serving cell identifiers at your baseline location if you intend to cross-reference towers later (Vol 8 covers OpenCelliD lookups). Knowing the legitimate cells near home makes an anomalous one elsewhere stand out.
Confirm the quiet state is genuinely quiet. If the detector throws medium/high warnings in a location you have every reason to believe is clean, that is itself worth understanding before a trip — it may be a configuration choice (an over-eager analyzer enabled), a local network quirk, or a device issue. Better to learn it at home than to misread it in the field.

Why the baseline matters. The analyzers are heuristic. They flag patterns associated with cell-site simulators, and some of those patterns occur occasionally in legitimate networks (a genuine tower handover, an unusual but real reselection). A baseline teaches the operator the local false-positive texture, so a real deviation reads as a deviation.

7.4 Reading the web UI and the warning line

Two surfaces, two jobs.

The on-device line is the glanceable status. Its job is to let an operator check state without unlocking anything. Green (or blue, in Colorblind Mode) means running-and-recording with no warnings. Any other colour means an analyzer fired — the line changes to show severity (§5), and the alert persists until the device is rebooted or a new recording is started. Persistence is intentional: a warning that cleared itself the moment the suspicious behaviour stopped would be easy to miss.

The web UI (http://<device>:8080, Vol 6 §6) is the detail. For each recording it shows which analyzers fired and at what severity, and it is where recordings are started, stopped, downloaded, and deleted. In the field the operator typically only needs the line; the UI comes into play when something warns and when reviewing after a trip.

Resetting the line after a warning:

Reboot the device, or
Start a new recording from the web UI, or
Double-tap the power button — if that input mode is enabled in the config (it ships disabled since 0.4.0; Vol 6 §8). A double-tap stops the current recording, starts a fresh one, and resets the line in one gesture.

7.5 The severity ladder: what each colour means

The line escalates through a visible ladder as severity rises. The colours are the operator’s first-order read; the web UI gives the analyzer behind them.

Table 1 — 5. The severity ladder: what each colour means

Line state	Meaning
Green (blue in Colorblind Mode)	Running and recording; no warnings
Yellow dots	A warning has fired at the lower end of the severity range
Orange dashes	A warning at a higher severity
Solid red	A high-severity warning

   green ───▶ yellow dots ───▶ orange dashes ───▶ solid red
  (clean)    (something        (stronger          (high-severity
             tripped)          pattern)            pattern)
                 └──────────────┴───────────────────┘
                     persists until reboot / new recording

Severity rises with how strongly, and in what combination, the recorded control plane matches the patterns the analyzers watch for. A single lower-severity analyzer firing once is a different thing from several firing together — and Volume 5 notes that some analyzers are weak on their own but strong in combination (an incomplete SIB plus an IMSI request, for instance). The line colour compresses that into one of four states; the UI is where the operator sees which analyzers produced it.

Informational ≠ warning. The Diagnostic Information analyzer (Vol 5) emits informational notices in normal operation to aid later PCAP review. Those are not the yellow/orange/red ladder and can be ignored until an actual low/medium/high warning appears.

7.6 Warning is signal, not proof — the user response

This is the most important paragraph in the volume. A Rayhunter warning is evidence worth acting on, not a confirmed detection. The analyzers are heuristic and work on the control plane only; they flag behaviour associated with cell-site simulators, and legitimate networks occasionally produce similar behaviour. The correct response to a warning is therefore a posture shift — becoming more cautious — not a declaration that an attack is underway.

What a posture shift looks like in practice:

Treat the cellular link as untrusted for the moment. Hold off on sensitive calls or messages over the cellular network until the situation is clearer. Prefer end-to-end-encrypted apps over an already-trusted data path, or defer until clear.
Note the context. Where, when, which severity, which analyzers. This is what makes the recording reviewable later (Vol 8) and what lets a pattern across trips emerge.
Preserve the recording. Don’t immediately clear it — it is the artifact an expert would want to see (Vol 8). Clear only after review.
Consider leaving the area if the threat model warrants and it is practical — the simplest way to stop participating in a suspicious cell is to move out of its coverage.
Do not escalate to certainty. A warning does not identify an operator, a device, or an intent. It says the control plane did something the analyzers associate with interception.

            ┌─────────────────────────┐
            │  Status line goes        │
            │  yellow / orange / red   │
            └───────────┬─────────────┘
                        ▼
            ┌─────────────────────────┐
            │  Open web UI: which      │
            │  analyzer(s), what sev?  │
            └───────────┬─────────────┘
                        ▼
      ┌─────────────────────────────────────────┐
      │  SHIFT POSTURE (signal, not proof):       │
      │   • pause sensitive cellular comms        │
      │   • note where / when / which analyzer    │
      │   • keep the recording (don't delete)     │
      │   • move out of the area if warranted     │
      └───────────────────┬───────────────────────┘
                          ▼
            ┌─────────────────────────┐
            │  After trip: review the  │
            │  recording (Vol 8),      │
            │  then clear (§8)         │
            └─────────────────────────┘

7.7 The ~10-minute Wi-Fi-AP sleep quirk

Some hotspots power down their Wi-Fi access point after a period of inactivity to save battery. On TMOHS1 and CT2MHS01, the Wi-Fi AP sleeps after roughly 10 minutes idle. This matters because the web UI is reached over that Wi-Fi: if the AP has slept, the UI appears unreachable even though the detector is still running and recording.

The key point for the operator: AP sleep does not stop detection. The daemon keeps recording the cellular control plane and the status line keeps working regardless of whether the Wi-Fi AP is awake. Only access to the web UI over Wi-Fi is affected.

Table 2 — 7. The ~10-minute Wi-Fi-AP sleep quirk

Situation	What to do
UI unreachable after idle on TMOHS1 / CT2MHS01	Wake the device (interact with it) so the AP comes back, then reconnect to :8080
Want persistent UI access on a sleep-prone device	Use Wi-Fi-client mode (Vol 6 §9 — available on TMOHS1/Wingtech among others) so the device sits on an existing network, or reach it over USB/ADB (Orbic)
Worried detection stopped because UI went away	It didn’t — the line and the recording continue; the AP sleeping is a Wi-Fi power-save, not a daemon event

Don’t mistake a sleeping AP for a dead detector. The most common field confusion with these two devices is assuming Rayhunter stopped because the web page won’t load. Check the device’s own status line; if it’s showing a state, it’s recording.

7.8 Clearing recordings between trips

Recordings accumulate on the device’s storage (Vol 6 §7) and each one is a record of where the device — and by extension its carrier — has been, plus the control plane it saw. Clearing between trips serves two ends:

Storage hygiene. Flash/SD space is finite; a device left running for weeks will fill. A detector with nowhere to write is no longer recording usefully.
Privacy / OPSEC. A recording is sensitive data. The fewer trips’ worth of control-plane logs sit on a device that travels and could be lost, seized, or inspected, the less there is to expose. Volume 10 develops the OPSEC argument.

The discipline:

AFTER a trip:
  1. Download any recording worth keeping  (web UI → Download; QMDL/PCAP — Vol 8)
  2. Review it off-device                   (Vol 8)
  3. Delete it from the device              (web UI → Delete)
BEFORE the next trip:
  4. Start a fresh recording from a known-clean place  (§2, §3)

If a recording captured a warning worth preserving, keep the exported copy off the device (host, or the WebDAV upload target from Vol 6 §8) before deleting the on-device original. Delete is destructive; the export is the archive.

7.9 Pre-trip checklist

Pre-trip checklist (field). ☐ Device charged; spare power if the trip is long (continuous recording draws power) ☐ Powered on in a known-clean place; green confirmed (Colorblind Mode: blue) ☐ Web UI reachable at http://<device>:8080 before you leave ☐ Old recordings cleared; a fresh recording running (§8) ☐ UI Level set for the trip’s discretion needs (Vol 6 §8) — Invisible/Subtle if the point is not to advertise ☐ (ntfy configured?) notifications tested, if you want to be told without looking ☐ (Sleep-prone device TMOHS1/CT2MHS01) you know the AP sleeps at ~10 min and how to wake it (§7) ☐ You can explain what the device is if asked (Vol 10) ☐ The Rayhunter hotspot is not your sensitive-traffic path (Vol 10 OPSEC)

7.10 Field anti-patterns

The ways a well-intentioned operator gets less than the detector can give:

Treating a warning as a verdict. It is signal, not proof (§6). Over-reacting (panic) and under-reacting (dismissal) are both failures to shift posture appropriately.
No baseline. The first warning in an unfamiliar place is unreadable without a sense of local normal (§3).
Powering on only at the sensitive location. The recording then has no clean reference segment, and any warning stands without context (§2).
Clearing a warning recording before reviewing it. The artifact an expert would want is gone (§6, §8).
Assuming a sleeping Wi-Fi AP means the detector stopped (§7).
Routing real sensitive traffic through the Rayhunter hotspot. It is an instrument; treat it as one (Vol 10).
Loud UI Level in a setting where discretion is the point. High-visibility/Demo modes advertise the device (Vol 6 §8).

Volume 8 turns to the recordings themselves: pulling the QMDL/PCAP off the device, opening the control plane in Wireshark, cross-referencing serving cells against public tower databases, and a host-side summary workflow.

Rayhunter Volume 7 — Using It in the Field