From a verified-rootable hotspot to a flashed, running detector: the EFF installer workflow, first boot, reaching the web UI, enabling flash/SD logging, and the configuration file — all at a user and workflow level

6.1 About this Volume

This volume covers getting a supported hotspot from “box on the bench” to “flashed, running, and reachable in a browser” — as a high-level workflow, not a device-specific root recipe. The distinction matters and is enforced throughout: the act of gaining the privileged shell that the installer needs is device-specific, changes with firmware revision, and is documented authoritatively in EFF’s own per-device install guides. Those guides are the single source of truth for the rooting step, and this volume defers to them by link rather than reproducing them.

What this volume does document is the part a user owns regardless of device: what the installer is and what it does, the order of operations, how to confirm a healthy first boot, the three ways to reach the on-device web UI, how recordings are stored, and the configuration surface that decides how loud, how visible, and how connected the detector is. Volume 3 (the sibling-authored supported-hardware table) is the reference for which device; this volume assumes one of those devices is already in hand and known to be rootable.

Scope note. Rayhunter is a passive detector. Nothing in this volume — or anywhere in this dive — describes building, configuring, or operating a cell-site simulator, or any cellular-attack technique. The subject is the detector and its operator.

6.2 The prerequisite nobody skips: a verified-rootable unit

Rayhunter installs a Rust daemon onto the hotspot’s own Linux environment and arranges for it to start on boot. Getting the daemon onto the device requires a privileged (“root”) shell over the device’s debug interface, and whether that shell is reachable depends on the exact hardware revision and the exact firmware version shipped on the unit.

The practical consequence for anyone buying a used device: the model name alone is not enough. Two outwardly identical Orbic RC400L units can differ in whether the documented install path works, because of the firmware they shipped with or were updated to. The buying discipline is to acquire a unit on a firmware revision that EFF’s install guide lists as known-good, and to keep the device off the carrier network afterward so a carrier over-the-air update cannot silently move it to a firmware that closes the install path.

Table 1 — 2. The prerequisite nobody skips: a verified-rootable unit

Device (per Vol 3)	Region	Role in the install story
Orbic RC400L (also sold as Kajeet RC400L)	Americas	The reference device; the best-documented install path
TP-Link M7350	Africa, Europe, Middle East	Recommended alternate; needs a FAT-formatted SD card for recordings
Wingtech CT2MHS01, T-Mobile TMOHS1, Moxee, FY UZ801	Mixed	Functional; follow the device’s own page
TP-Link M7310 / M7200	Africa, Europe, Middle East	Functional
PinePhone / PinePhone Pro	Global	Functional (a Linux phone, not a hotspot)

Defer here, always. The rooting/shell step for every device lives in EFF’s official install documentation at efforg.github.io/rayhunter (Installation → the per-device page for your unit). Use it as written. This dive does not reproduce those steps because they are version-sensitive and getting them from the canonical source is the only safe path.

6.3 What the installer actually is

The recommended install path uses a prebuilt, platform-specific installer binary that EFF ships in each release — not a shell script, and not something the user compiles. The release archive on GitHub contains an installer executable built for each host OS and CPU (Linux, macOS, Windows, across the common architectures). The source-tarball that GitHub auto-generates does not contain this binary; the platform zip is the one to download.

Two build paths exist, and the difference is only in where the daemon binary comes from:

Table 2 — Two build paths exist, and the difference is only in where the daemon binary comes from

Path	What the user runs	When to use it
Install from release (recommended)	The prebuilt `installer` from the release zip	Almost everyone — no toolchain needed
Install from source	The Rust toolchain (`cargo`) builds the daemon and installer, then installs	Developers, or to run an unreleased commit

The from-source path is where the Rust toolchain enters the picture: Rayhunter’s daemon and its tooling are written mostly in Rust, so building from source means a working cargo/rustup install and a cargo-driven build. For a user who only wants a working detector, the release path skips all of that — download the zip, run one binary.

The installer, once run, connects to the powered-on device over the debug/USB (or tethered-network) interface, pushes the Rayhunter daemon and its default configuration onto the device’s storage, registers it to start on boot, and triggers a reboot. The user’s side of this is a single command with a device argument; the mechanics of the privileged handoff are handled inside the installer and documented per-device by EFF.

6.4 The install workflow, end to end

The following is the shape of the release-path install. It is deliberately high-level: every line that touches the device’s privileged interface is owned by EFF’s per-device guide.

STEP 1  Confirm the unit is a supported model on a known-good firmware rev   (Vol 3 + EFF guide)
STEP 2  Download the platform-specific release zip for your host OS/arch     (GitHub releases)
           - NOT the auto-generated "Source code" tarball — it has no installer
STEP 3  (TP-Link only) Insert a FAT-formatted SD card for recordings
STEP 4  Extract the zip; open a terminal in that folder
           - Windows: open PowerShell in the folder
           - macOS:  clear the quarantine attribute so the binary may run
STEP 5  Power on the device; connect the host over Wi-Fi or USB tethering
           - You are on the right network when the device admin page loads:
               Orbic    http://192.168.1.1
               TP-Link  http://192.168.0.1
STEP 6  Run the installer with the device argument  (see EFF's per-device page)
           - Orbic needs the device admin password (and username/IP if changed from default)
           - TP-Link needs no password
STEP 7  Wait — the installer reports completion, then the device reboots itself
STEP 8  Verify: a green line flashes across the device display; the web UI loads

┌────────────┐     prebuilt installer      ┌──────────────────────┐
│  Your host │ ──  over debug / tether  ──▶ │  Hotspot (Qualcomm)   │
│  (terminal)│                             │  • daemon installed    │
│            │ ◀──  "done", reboots    ──  │  • starts on boot      │
└────────────┘                             │  • green line on boot  │
                                           └──────────────────────┘

Pre-flight checklist (install). ☐ Unit is a model in the Vol 3 table, on a firmware rev EFF lists as rootable ☐ Correct platform zip downloaded (not the source tarball) ☐ (TP-Link) FAT-formatted SD card inserted ☐ Device powered on; host confirmed on the device’s network (admin page loads) ☐ (Orbic) admin password to hand; (macOS) quarantine attribute cleared ☐ A second USB cable/port/hub available in case the first connection is flaky

6.5 First boot — what a healthy install looks like

After the installer finishes and the device reboots on its own, Rayhunter starts automatically. It is designed to run whenever the device is powered on, with no manual start. Two signs confirm a healthy install:

The green line. A green line flashes/appears across the top of the device’s small display. Green is the “running and recording, no warnings” state. (If Colorblind Mode is enabled, the no-warning state shows blue instead of green — see §8.)
The web UI loads. Reaching http://<device>:8080 in a browser returns the Rayhunter interface (§6).

Rayhunter records continuously while it runs. There is no “arm” step — from first boot, it is capturing the modem’s control-plane log into a recording and applying the analyzers (Vol 5) to that stream in real time. The warning line on the display is the device’s at-a-glance status; the web UI is the detailed view.

Note on the display’s role. The on-device line is a status light, not an analysis console. It tells the operator, without unlocking a phone or opening a laptop, whether anything has tripped. The reasoning behind a warning lives in the web UI and in the recording itself (Vol 8).

6.6 Reaching the on-device web UI

The web UI is served by the daemon on port 8080. It is plain HTTP — Rayhunter does not implement HTTPS, so browsers will warn that the connection is “not secure.” On the local device link that warning is expected and can be accepted; the same applies to “insecure download blocked” prompts when exporting recordings. There are three ways in.

Table 3 — 6. Reaching the on-device web UI

Access path	How	Address
Wi-Fi (AP mode)	Join the device’s own Wi-Fi network, then browse to its admin IP on :8080	Orbic `http://192.168.1.1:8080` · TP-Link `http://192.168.0.1:8080`
USB (Orbic)	Install ADB on the host; forward the port, then browse locally	`adb forward tcp:8080 tcp:8080` → `http://localhost:8080`
USB (TP-Link)	Use USB tethering for a network connection; ADB can be enabled on the device by the user (the installer doesn’t)	device IP on :8080

Finding the device Wi-Fi password:

Orbic: device menu → 2.4 GHz WIFI Info → Enter.
TP-Link: device menu → Advanced → Wireless → Basic Settings.

With Wi-Fi-client mode enabled (§9), the hotspot joins an existing network instead of (or alongside) serving its own, and the UI is reached at http://<device-ip>:8080 from any host on that shared network.

The web UI’s functions are deliberately small:

Start / stop recordings — begin a fresh capture or end the current one.
Download captures — export a recording as QMDL / PCAP for off-device review (Vol 8).
Delete captures — clear recordings off the device (Vol 7 covers between-trip hygiene).
View heuristic analyses — see, per recording, which analyzers fired and at what severity (Vol 5 explains the analyzers; Vol 8 explains reading the exported files).

6.7 Recording storage: flash and SD logging

Rayhunter writes its recordings to the device’s own storage. How much room there is, and whether an SD card is involved, depends on the device:

Orbic RC400L records to internal flash; it also has a microSD slot that can extend capacity.
TP-Link M7350 uses a FAT-formatted SD card for recordings — inserting one is a step in that device’s install path (§4, Step 3). Without the card there is nowhere to store captures.

The practical rule is the same across devices: recordings accumulate, so storage is finite, and a long-running or repeatedly-restarted detector will eventually need its older recordings cleared. Between-trip clearing is both a storage-hygiene and a privacy practice and is covered in Volume 7 (§on clearing recordings). The web UI’s delete control, and starting a fresh recording, are the tools for this.

Optional: off-device upload. The configuration file supports a [webdav] table (§8) that, when present, runs a background worker uploading eligible recordings to a WebDAV server on a schedule. This is how a user keeps an archive off the hotspot without manual downloads. It is off unless the [webdav] section is present.

6.8 The configuration file — a guided tour

The daemon reads a TOML configuration at /data/rayhunter/config.toml on the device. The shipped default lives in the repo at dist/config.toml.in. Most options are also exposed in the web UI, so day-to-day users rarely edit the file by hand; a few (notably [webdav]) are file-only. Editing the file directly requires a shell on the device, obtained per EFF’s per-device page.

The configuration surface, grouped by what it controls:

Table 4 — The configuration surface, grouped by what it controls

Group	Option	What it does
Display	Device UI Level	How visible the status is: Invisible · Subtle (colored status line) · Demo (an orca GIF plus the line) · EFF logo · High visibility (full-screen status color)
	Colorblind Mode	Shows blue instead of green for the “no warnings” state
Input	Device Input Mode	Disable button control, or double-tap the power button to stop and restart recording (the double-tap action exists since 0.3.3; disabled by default since 0.4.0 — turn it on here)
Clock	Clock Sync	Prompt (default) · Autosync (corrects drift over 30 s, in memory only) · Off
Updates	Auto update check	Periodically checks Rayhunter’s GitHub releases for a newer version
Notifications	ntfy URL	A notification endpoint pushed to on detection
	Enabled Notification Types	Warnings (at most once per 5 min) · Low Battery (device-dependent) · Software Updates (needs update checks on)
Analyzers	Analyzer Heuristic Settings	Turn each heuristic (Vol 5) on or off individually
Location	GPS Settings	Disabled (default) · a fixed latitude/longitude · or an API Endpoint that enables `POST /api/gps` so an external source can supply position
Network	Wi-Fi Client Mode	Join an existing network — Orbic/Moxee/UZ801/TMOHS1/Wingtech only (§9)
Upload	`[webdav]` table	File-only; background upload of recordings to a WebDAV server

The [webdav] table (edited only in the file):

Table 5 — The [webdav] table (edited only in the file)

Key	Required	Default	Purpose
`url`	yes	—	WebDAV server base URL
`username`	no	—	HTTP Basic auth username
`password`	no	—	Basic auth password (rejected without a username)
`upload_timeout_secs`	no	300	Per-request upload timeout
`poll_interval_secs`	no	3600	How often to scan for eligible entries
`min_age_secs`	no	86400	Minimum entry age before it may upload
`delete_on_upload`	no	false	Delete the local copy after a successful upload

Without a [webdav] section, no upload worker runs at all.

Picking a UI Level for your threat model. High visibility or Demo make the detector obvious — good for a demo table, bad if the point is to not advertise that you carry one. Invisible or Subtle keep it discreet; pair Invisible with ntfy notifications if the operator wants to be told about a warning without the device showing anything. The right choice is a function of who might see the screen.

6.9 Wi-Fi-client mode

By default a hotspot serves its own Wi-Fi network (AP mode) — that is its job as a hotspot. Wi-Fi-client mode instead has the device join an existing Wi-Fi network as a client. For Rayhunter, the point is convenience of access: with the device on the same network as a laptop or phone, the web UI is reachable at http://<device-ip>:8080 without first disconnecting from everything else to join the hotspot’s own AP.

Wi-Fi-client mode is available on a subset of devices: Orbic, Moxee, FY UZ801, T-Mobile TMOHS1, and Wingtech CT2MHS01. Its settings (in the web UI / config): enable Wi-Fi, select the network by scan or by typing an SSID, a password (stored separately in wpa_sta.conf, not in config.toml), and DNS servers (defaulting to the Quad9 pair 9.9.9.9 / 149.112.112.112).

Operational caution. Wi-Fi-client mode changes how the device is reached, not what it is. The detector still records only the cellular control plane; joining a Wi-Fi network is an access convenience. Volume 10 covers the OPSEC point that the Rayhunter hotspot is an instrument, not the device through which sensitive traffic should be routed.

6.10 When the install fails: first-pass triage

The single most common install failure is a flaky host-to-device connection, and EFF’s guidance leads with the physical layer for exactly that reason.

Table 6 — 10. When the install fails: first-pass triage

Symptom	First things to check
Installer can’t find / reach the device	Is the device powered on? Does its admin page load (`192.168.1.1` Orbic / `192.168.0.1` TP-Link)? If not, you’re not on its network yet
Connection drops mid-install	Try a different USB cable, a different port, or skip the hub — a marginal cable is the usual culprit
macOS won’t run the installer	Clear the quarantine attribute on the binary first (per the macOS note in EFF’s guide)
Orbic install rejects credentials	Supply the device admin password; if the username/IP were changed from default, pass those too
Wrong download — no installer in the folder	You grabbed the auto-generated Source code tarball; download the platform-specific zip instead
Rooting/shell step won’t complete	This is device- and firmware-specific — return to EFF’s per-device install page; do not improvise

Escalate to the source, not to workarounds. If the privileged-shell step itself fails, the answer is the device’s official install page and the project’s support channels (the Mattermost community linked from the docs), not an undocumented rooting method found elsewhere. A detector built on an unknown firmware hack is a detector you cannot trust.

Volume 7 takes the now-running detector into the field: power-on order, establishing a clean baseline, reading the warning line, and what an operator actually does when it goes yellow, orange, or red.

Rayhunter Volume 6 — Installing & First Run