Troubleshooting

Read this first, in this order:

whisper status
whisper service status --sensor
journalctl -u whisper-sensor -n 3

The first says whether a key is in effect and which agent is selected. The second says whether the service is installed, running, and reporting under an address. The third says what the sensor itself thinks.

The service is running and nothing arrives

The journal says what is missing:

whisper: no bound /128 identity - summaries stay local until one is bound

The machine is collecting normally and holding everything locally, because it has no address to ship under. Bind it and restart:

whisper enroll
sudo -E whisper service restart --sensor

Then confirm you see reporting as with your address. This is the most common cause by a wide margin: active (running) only ever meant that the process started. Bind the host is the whole step.

The service starts with no identity even though you bound the host

You used sudo without -E. sudo resets HOME, and both your key and the bound marker live under your home directory, so root looked somewhere else and found neither. Re-run the install or the restart with the environment kept:

sudo -E whisper service install --now --sensor

The installer said the key was refused

The CLI is installed and usable; only the keyed part did not happen. Sign in and bind by hand:

whisper login --web
whisper enroll

The host appears twice in the roster

Binding ran twice under two different names, and each name gets its own address. whisper enroll is idempotent under one name, so bind under the name that is already registered:

whisper enroll --name <the-registered-name>

The duplicate keeps its address until you revoke it; contain an endpoint has that command, and it is permanent.

whisper is not on the PATH

The installer puts the binary in /usr/local/bin when it runs as root and in ~/.local/bin otherwise. Call it by its full path, or reinstall with WHISPER_DIR set to somewhere already on your PATH. This is also why an install step and a sudo step can disagree about where the binary is: give sudo the full path.

A configuration change had no effect

sensor.json is read when the service starts. Apply it:

sudo -E whisper service restart --sensor

Remember that the file can only narrow: a key is on unless it is explicitly false. See what the sensor detects.

DNS questions are missing from a host's activity

The sensor attributes the plain DNS the host itself sends. Name resolution the machine sends over an encrypted transport is answered by the Whisper resolver instead, so those questions, and the verdicts on them, arrive on the resolver's side rather than through on-host attribution:

whisper logs --kind dns

Encrypted DNS is how to point a host there deliberately.

A rule I added never fires

Check that the rule's log source maps to an event kind the collectors emit, that the condition is written against a single event rather than a sequence, and that the service was restarted after the file was copied in. Add your own rules has the mapping.

Windows: the service is not there

Install from an elevated PowerShell, under the same account that ran whisper enroll, since the marker lives in that account's profile. Then:

sc query whisper-sensor
whisper service status --sensor
Get-Content C:\ProgramData\Whisper\logs\whisper-sensor.log -Tail 20 -Wait

The console shows nothing

Each signed-in operator resolves to their own key and sees their own estate only, and an estate with nothing provisioned renders empty rather than failing. If a host you expect is missing, it is a binding question rather than a console one: start at the top of this page.

I need to prove a containment held

Read the action back rather than trusting the call that made it. The read-back of the firewall in contain an endpoint is the evidence for a hold, and the transparency log is the evidence for a cut.