Troubleshooting

Fixes for the messages ARRF shows, grouped by where they appear. If none of these resolves it, contact support or email support+arrf@support.neuralconfig.com.

”Can’t reach your APs”

Full message: “None of the APs answered an SSH probe. Check that this iPhone is on the same Wi-Fi network as your APs.” ARRF probes SSH (TCP 22) on each AP before a survey.

Confirm the iPhone is on the same local network as the APs.
Confirm each AP IP is correct in Settings → Integrations → RUCKUS → APs.
If a management ACL or firewall limits SSH access to the APs, permit the test iPhone.

If only some APs answer, you’ll see “Some APs didn’t answer” and can Start anyway — offline APs are skipped.

Mid-survey, an AP that stops answering shows as “AP unreachable”. In the Toolbox the headline is Couldn’t reach the AP: “Is this iPhone on the AP’s network? Also check Settings ▸ Privacy & Security ▸ Local Network and make sure ARRF is allowed."

The AP was reachable but turned down the SSH username or password. The Toolbox shows Login rejected; the survey HUD shows “login rejected”. (Behind Details, the log line reads “rkscli login failed (bad credentials?)” or, mid-survey, “rkscli login failed after credential refetch”.)

Manual surveys: re-enter the AP’s admin password under Settings → Integrations → RUCKUS → APs, and check the Username there (blank means admin).
RUCKUS One venues: passwords are fetched automatically and rotate roughly every two days; ARRF refetches once on a login failure. If it persists, check the API client’s role (next section), then run Test connection in RUCKUS One account to confirm the tenant is reachable.

If the Survey lobby warns “No saved AP passwords — the SSH login will fail. Save them in Settings ▸ Integrations ▸ RUCKUS ▸ APs, or pick a RUCKUS One venue.” before you start, no password is saved for any of your manual APs. The pre-flight probe only checks that port 22 answers, so it can report every AP reachable while every login still fails.

The RUCKUS One API client is probably read-only. Use an admin (read-write) API client instead. RUCKUS One hands a read-only client a masked AP password: GET /venues/{venueId}/aps/{serial}/passwords returns HTTP 200 with apPassword set to ********** (verified live on 2026-10-16). ARRF can’t tell the mask from a real password, so it logs in with it, every AP rejects the login, and the refetch returns the same mask.

In RUCKUS One, create (or pick) an API client with an admin (read-write) role, under Administration → Account Management.
In ARRF, open Settings → Integrations → RUCKUS and enter that client’s ID and secret under RUCKUS One account.
Run Test connection, then start the survey or Toolbox tool again.

”No password saved”

ARRF has no SSH password for that AP. The Toolbox shows No password saved; the survey HUD shows “no password saved”. Add it under Settings → Integrations → RUCKUS → APs — RUCKUS One venues fetch it automatically. If a RUCKUS One venue can’t supply one, the HUD shows “couldn’t get password from RUCKUS One”: run Test connection to see why.

”SSID not on this AP”

An AP has no up WLAN broadcasting your Target SSID. The Toolbox shows SSID not on this AP; the survey HUD shows ““Your SSID” not on this AP”. (The log line behind Details reads “no up WLAN broadcasting …”.) Choose the SSID you’re surveying in the Survey lobby or in Settings → Integrations → RUCKUS → Connection — the SSID picker lists what each AP actually broadcasts. See Connecting to your RUCKUS APs.

”AP refused the connection”

“The AP answered but refused SSH. Make sure SSH is enabled on the AP and nothing blocks port 22.” The AP is on the network but its SSH port is closed. Enable SSH on the AP, or remove the rule blocking TCP 22.

”The AP stopped answering” or “Connection dropped”

Headline	Message	Fix
The AP stopped answering	”The AP didn’t respond in time — it may be busy or rebooting. Try again in a moment.”	Wait, then retry.
Connection dropped	”The AP closed the SSH session — it may have too many sessions open, or be rebooting. Try again in a moment.”	Close other SSH sessions to the AP, or wait for the reboot.
Connection dropped	”The connection to the AP closed unexpectedly. Try again in a moment.”	Retry.

The AP’s host key changed

The Toolbox and the survey HUD show AP identity changed (the log line behind Details reads “host key for … changed”). ARRF pinned this AP’s SSH identity on the first connection and the AP is now presenting a different key, so ARRF refuses to connect. It will keep refusing until you clear the pin — there is no inline “trust it anyway”, because a changed key can indicate a man-in-the-middle.

If you replaced or factory-reset that AP, its identity legitimately changed and you can recover:

Confirm the hardware on that IP is what you expect. If the key changed and you didn’t change anything, stop and investigate instead.
Open Settings → Integrations → RUCKUS → Trusted APs. Each row is a pinned AP.
Swipe the row and tap Forget.
Reconnect. The next connection trusts and re-pins whatever key that AP now presents.

If the reset also changed the AP’s admin password, update it under Settings → Integrations → RUCKUS → APs too (see Login rejected). The pre-flight only checks that port 22 answers, so it still reports the AP reachable while every login fails.

See Host-key trust and Trusted APs.

”RUCKUS One rejected my credentials”

Under Test connection, and anywhere else a RUCKUS One call fails, ARRF reports the specific reason:

Message	Fix
”Enter the region, tenant ID, client ID and secret in Settings ▸ Integrations ▸ RUCKUS.”	Fill in all four fields.
”RUCKUS One rejected these credentials — check the region, tenant ID, client ID and secret.”	Re-copy the API credentials from RUCKUS One → Administration → Account Management, and check the region.
”This API client lacks permission (needs venue/AP read and AP password access).”	Give the API client those permissions.
”RUCKUS One couldn’t find that account — check the region and tenant ID.”	Correct the region or tenant ID.
”RUCKUS One is rate-limiting requests — try again in a minute.”	Wait and retry.
”RUCKUS One is having trouble (HTTP …) — try again shortly.”	A RUCKUS One server error; retry later.
”Can’t reach RUCKUS One — check your internet connection.”	The tenant lookup needs internet; confirm the iPhone is online.
”RUCKUS One sent a response ARRF didn’t understand — try again, or contact support if it persists.”	Retry, then contact support.

Test connection only lists the tenant’s venues, so a read-only API client can pass it while every AP login is still rejected — see Why is every login rejected with a RUCKUS One venue?

Identify My Phone can’t confirm

“Didn’t feel the wave…” — hold the phone firmly and swing it side to side; waving isn’t available in the iOS Simulator.
“More than one device moved…” — have others hold still and try again.
“That device didn’t answer the probe…” — you likely picked the wrong client; try IP auto-match or pick again.
Readings stopped mid-survey — iOS may have rotated your private Wi-Fi address. The AR view raises “Can’t see your phone — its private address may have rotated.” with an Identify button; tap it to re-find the target without ending the survey. See Identify My Phone.

Why is the Toolbox greyed out?

The free trial hasn’t started, or it has ended without an unlock. The top of the Toolbox shows Start the free trial to use Toolbox or Unlock ARRF to use Toolbox, with a status line such as “Trial ended (14 days)” or “Trial ended (3 surveys used)”. Tap it to start the trial or unlock. See sample results stays open. See Free trial and unlock.

If the trial is running but a RUCKUS tool is still greyed out, no APs are loaded: pick a RUCKUS One venue in the Survey lobby or add AP IPs in Settings.

Network Test: “The router isn’t answering”

“The router isn’t answering. If you declined Local Network access, allow it in Settings ▸ ARRF — the edge and burst tests still work without it.” Tap Allow Local Network in Settings and turn on Local Network for ARRF. If it’s already on, enter your router’s address under Settings → Experience → Manual gateway. The call test needs the router to answer ICMP: otherwise it reports “The router didn’t answer the call probes (ICMP), so a call couldn’t be simulated.”

Network Test: “Tests run over Wi-Fi only”

“Tests run over Wi-Fi only — cellular results never count.” Join a Wi-Fi network and run the test again.

Speed test: “The cloud test allowance is used up”

“The cloud test allowance is used up for now; it frees up gradually over the week. A local iperf3 server still works.” (ARRF 1.0 words it “Today’s cloud test allowance is used up (resets at midnight UTC)…”.) Each install has a fair-use data allowance on the test server, counted over a rolling 7 days — see Limits and quotas. In 1.1 and later, a survey notice says when tests resume. Wait until then, or set Settings → Experience → Local iperf3 server to test over your own network.

“The test server is busy — try again in a few seconds.” is the short-term rate limit; wait a few seconds and retry.

What if the test server is unreachable?

If the test server is unreachable, gateway tests carry on. Router latency, jitter, loss, and the call to the router keep running; only the tests that use the test server (internet edge, Internet call, and cloud speed bursts) go without results. With Internet tests turned off, ARRF never contacts it — see Internet tests and privacy.

Camera paused during a survey

“Camera paused — capture resumes when it’s back.” A phone call or Control Center interrupted ARKit. Capture resumes on its own when the camera returns; if tracking struggles afterward, follow the on-screen hints (“Move slower”, “Point at detail”).

”AR stopped: …”

A fatal ARSession error — the camera became unavailable, or tracking failed unrecoverably. The banner offers Restart AR (a fresh AR session, same survey) or Stop & save (end normally). Readings already collected are kept either way, so neither choice loses data. If restarting fails repeatedly, stop and save, then start a new survey.

Cubes are dropping more slowly than usual

Look for a slowed ×2 or slowed ×4 chip at the top of the survey screen. The iPhone is thermally throttling, and ARRF has deliberately halved or quartered its polling rate to match. Let the phone cool — take it out of direct sun, out of a case, or off charge — and full rate returns on its own. See Long walks and hot phones.

”Survey not saved”

The walk finished but writing it to storage failed — usually a full device. ARRF does not discard the data: choose Retry after freeing space, or Open anyway to reach the Results screen and export the report by hand before you leave it. See When a survey can’t be saved.

”Couldn’t open survey”

A History row whose document is missing from storage or damaged and can’t be opened. ARRF never deletes a file it failed to read, so a copy restored from a backup still opens. See When a saved survey won’t open.

The packet capture never arrives

The AP TFTPs the pcap to your iPhone, so the return path matters as much as SSH. Check that ARRF has Local Network permission, that nothing blocks UDP 69 inbound to the phone, and that client isolation isn’t preventing the AP from reaching it. If you captured on the radio your phone is associated to, ARRF warned you for this reason — capture a different band or a different AP. See Packet capture.

No floor plan on the Results screen

Floor-plan reconstruction needs a LiDAR iPhone and the Floor-plan reconstruction toggle on (Settings → Survey & capture, on by default), and it takes effect on the next survey. Non-LiDAR devices produce no plan. See LiDAR floor plan.

Still stuck?

Contact support, or email support+arrf@support.neuralconfig.com.