Troubleshooting

Activation fails on first start

The probe activates once, on first start, using the single-use code. Common exact errors and what they mean:

Error in the probe logs	Cause / fix
not activated and no activation code provided (set ACTIVATION_CODE)	The container started with no code and no saved credentials. Use the dashboard’s Docker command, which sets ACTIVATION_CODE.
activation failed: HTTP <code>	The code was wrong, already used, or expired. Mint a New activation command from the probes list.
activation request: <err>	The probe can’t reach the engine. Check outbound internet from the host.
activation response missing required fields	The engine returned incomplete credentials — retry with a fresh code; contact support if it persists.
create data dir / write shared-secret / persist activation state	The data directory isn’t writable. Ensure the /var/lib/probe-mcp volume is mounted and writable.

Caution

The activation code is single-use. If you recreate the container without persisting the /var/lib/probe-mcp volume, its saved credentials are gone and re-activation fails. Always keep the volume; if it’s lost, re-activate with a new code.

The probe never shows Online

• Confirm the container is running (docker ps) and check its logs (docker logs probe-mcp).
• The tunnel is outbound — confirm the host has outbound internet.
• A probe stuck pending in the dashboard usually never finished activation — mint a new activation command and redeploy.

A probe moves through three states. It starts pending at enrollment, becomes online when it activates and sends its first heartbeat, and is flipped back to offline by a scheduled sweep once it has gone silent — heartbeats are sent every 60 seconds, three missed ones (180 seconds) count as silent, and the sweep runs every 5 minutes. A probe that recovers goes straight back to online on its next heartbeat, with no re-activation.

Online in the dashboard, but calls still fail

The status you see can lag reality by several minutes: silence has to last 180 seconds, and only the next 5-minute sweep writes the change. During that gap the dashboard still says Online while nothing is answering.

You can tell the two cases apart by the error Claude reports:

• probe_offline — the engine already knows the probe is down and refuses to proxy the call at all.
• probe_unreachable — the engine believed the probe was up, tried the tunnel, and found no healthy origin behind it. This is the lag window.

Both mean the same thing in practice. Check the container on the LAN host rather than trusting the dashboard’s status.

Ask the probe what’s wrong with it first

Before you go hunting, check probe_status. The probe reports faults about itself on every heartbeat, and the engine turns them into a findings list:

Using Probe MCP, run probe_status on my probe and tell me what findings it reports.

status: 'online' only means the probe is talking to us. A service inside it can be running and discarding every packet it receives, which is exactly what findings catches:

Finding	What it means
config_rejected	The probe refused part of the config it was sent and is still running its previous values for the named blocks. It repeats this every heartbeat until a valid document replaces it, so it is current, not historical
snmp_traps_discarded	The trap listener is receiving traps and accepting none. An empty trap history is the listener, not a quiet network — the community doesn’t match
snmp_traps_partially_discarded	Traps are being accepted, but some senders are rejected on community. Those devices’ events are missing from an otherwise healthy-looking history. The finding names the senders; read the community off those devices and add it to snmp_trap.communities
wal_backlog	Upload segments are queued and not draining. Steady state is 0; a figure that doesn’t fall across heartbeats means the tunnel is down or the drainer is wedged

Caution

An empty findings list is not a clean bill of health if reported_health is null. That means this probe build doesn’t report any of it — “does not say”, never “is fine”. Upgrade the container to get the signal.

No telemetry is arriving

• Wrong target — devices must send to the probe’s LAN IP (shown on the probes list), not to a controller.
• Collector off — syslog and SNMP traps are on by default, but sFlow and NetFlow are not. Enable flow_collector in the config before pointing exporters at 6343/2055.
• Wrong port — syslog is 514 (UDP and TCP), SNMP traps 162/UDP, sFlow 6343/UDP, NetFlow 2055/UDP. See Pointing your network at the probe.
• SNMP polling — the probe polls devices outbound on 161; the device must allow SNMP from the probe’s IP and the community/version must match.

The connector won’t authorize in Claude

• Redirect loop — a cookie problem on the Google hop. Use a normal (non- private) window and allow cookies for probe-mcp.lanpulse.com, then re-add the connector.
• “Not authenticated” on every call — the token was revoked or the connector was added before sign-in finished. Remove and re-add it. See Connecting to Claude.

code_mode times out or says a probe is offline

• { error: 'timeout' } — the run hit its 30-second budget. Ask for a narrower scope (one device, a shorter window) rather than everything at once.
• probe_offline — you asked for on-demand live data (SNMP, live syslog, topology, pcap, SSH) but the probe isn’t reachable. Stored rollups still work; the live queries need the probe Online. Bring the probe back up and retry.

See Limits and budgets for the full set of timeouts, row caps, and size caps a broad request can run into.

A function exists but says it’s disabled

Several probe services ship off and are enabled in the probe’s config. The function is always callable in code mode; it’s the probe that refuses. Set the key, restart the container, and retry.

Error	Enable	Affects
pcap disabled	pcap.enabled: true (plus the CAP_NET_RAW capability)	top_conns, search_conns, pcap_query
ssh proxy disabled	ssh.enabled: true	device_cli, ssh_send, ssh_read, ssh_close, run_device_cli
reach_through disabled	reach_through.enabled: true	https_forward
tftp disabled	tftp.enabled: true	serve_tftp, stop_tftp
flow collector not enabled	flow_collector.enabled: true	query_flows
lbs_disabled	Registered by R1-MCP, not set by hand — see Linking with R1-MCP	lbs_status, lbs_clients, lbs_airtime
discovery disabled	discovery.enabled: true (on by default)	inventory, topology

Error vocabulary

Every probe.* call returns a structured result rather than throwing, so a failure arrives as an error field your question comes back quoting. The ones worth recognizing:

Error	Means
probe_offline	The engine knows the probe is down and didn’t attempt the call
probe_unreachable	The tunnel has no healthy origin — the probe died and the status hasn’t caught up
probe_not_found	No probe with that id on your account. Re-check with list_probes
probe_error	The probe answered, but with a failure it didn’t classify
lbs_disabled	The RUCKUS One LBS receiver isn’t wired on this probe
search query has no searchable terms	A search_syslog term was all punctuation. See what the search accepts
timeout	The 30-second code_mode budget ran out
metrics_unavailable	The stored-aggregate query failed. Affects snmp_metrics, top_talkers, syslog_rollups
host_forbidden / endpoint_forbidden	The target isn’t a private LAN address, or isn’t on the reach-through allowlist
connection_not_found / connection_inactive	The connection id is wrong, or the connection has been deactivated
not_a_vault_connection	A vault operation was aimed at a cloud-mode connection
no_cloud_secret	A probe_vault connection was called while the probe was down, with no break-glass copy in place. See break glass
credential_not_found / credential_required	No SSH credential is stored for that device
session_not_found	The SSH session was closed, or was reaped after 600 seconds idle. Open a new one
serve_failed	A TFTP serve is already active. Call stop_tftp first
render_failed / storage_failed	The scorecard PDF couldn’t be rendered or stored

Still stuck?

Contact support with your probe’s site name and the exact error text from docker logs probe-mcp.