IAPViewer Support

What devices are supported?

• iPhone — iOS 16 or later
• iPad — iPadOS 16 or later
• Mac — Apple Silicon (M1 or later), running the iPad app via "Designed for iPad"

IAPViewer is an iOS/iPadOS app, supporting iOS 16 and later. It runs natively on iPhone and iPad, and on Apple Silicon Macs via "Designed for iPad" — install it from the App Store on your Mac and it runs as the iPad app inside a Mac window.

IAPViewer is a single iPadOS codebase — there is no separate native macOS version. On Mac it runs as the iPad app via "Designed for iPad", which keeps the experience consistent across all platforms and focuses development on features rather than two parallel UIs.

What's the oldest device IAPViewer runs on?

IAPViewer targets iOS 16 as its minimum, which covers iOS devices back to roughly 2015 — including the first-generation iPad Pro 12.9" and iPhone 6s. The load is dominated by the Virtual Controller answering the app's sequential API calls, so even the oldest supported hardware stays perfectly usable — a full load takes roughly twice as long as on current hardware, and the app becomes usable as soon as the core data lands, well before the full load completes.

For reference, a full load against a production cluster of 12 APs with 98 clients (167 API calls) takes:

• 54.5 seconds on a 2015 iPad Pro (A9X)
• 36.1 seconds on an iPhone X (A11)
• 29.6 seconds on an iPhone 15 (A16)

If you have older hardware sitting unused — an old iPad in a drawer, a spare iPhone — it's a perfectly viable dedicated IAPViewer device. A cheap eBay purchase of a first-generation iPad Pro is enough to run the app indefinitely.

Does this work with HPE InstantOn?

No. IAPViewer only works with Aruba IAP clusters running AOS 8 (versions 8.6–8.13). HPE InstantOn uses a completely different infrastructure and is not supported.

Does this work with Campus Controllers or Mobility Conductors?

Not yet. The current version supports Aruba Instant APs (IAP) only. Campus Controller support is potentially planned for a future release with no ETA.

Do I need an Aruba Central subscription?

No. IAPViewer connects directly to your Virtual Controller over your local network and has no cloud dependencies. It works with both locally-managed and Central-managed clusters.

How do I connect to my Virtual Controller?

Enter your VC's IP address, username, and password in the site editor. IAPViewer stores credentials securely in your system Keychain. You can optionally add a fallback VC IP for resilience — see the relevant FAQ entry below.

What is the Test API button?

The site editor includes a Test API button that runs a pre-login REST probe against your Virtual Controller and shows the raw exchange — login, read-only show version and show aps calls, and logout, with full request and response capture for each step. If you've configured both a primary and a fallback IP, it tests them side by side.

Use it to validate VC reachability and REST API configuration before the main app even touches the site. The Copy log button puts the full transcript onto the clipboard — paste it into a support email and most diagnoses become a five-minute job.

How do I enable the REST API on my Virtual Controller?

IAPViewer talks to the VC exclusively through its REST API, which is disabled by default on Instant firmware. The app shows these same steps on its connection screen. SSH into the VC and run:

configure terminal
allow-rest-api
end
commit apply
exit

The setting applies cluster-wide and survives reboots. Once it's on, the Test API button in the site editor is the quickest way to confirm the API answers before a full connect.

What is the fallback VC IP?

Each site can carry an optional secondary VC address. If the primary IP doesn't respond — for example after a cluster reboot, a floating-IP rebind failure, or a brief network blip — IAPViewer silently retries against the fallback and shows a brief notice once you're connected.

You usually don't need to set it up yourself: on a successful connect, IAPViewer fills the fallback in automatically with the conductor AP's real IP address (the address that keeps answering when the cluster's floating VC IP stops responding). It only ever fills an empty fallback — a value you entered by hand is never overwritten — and it skips the auto-fill when you already connect via the conductor's own address. The auto-fill is noted in the app's event log.

If the fallback is used on two consecutive sessions, the app will prompt to swap it with the primary.

What does the loading bar at the top of the screen mean?

IAPViewer fetches your cluster's data through a sequence of API calls to the Virtual Controller. While that's happening, a thin coloured progress strip is shown at the top of the screen.

The bar is layered — it runs in stages, each its own colour, and a light haptic pulses once per completed call so the rhythm matches the bar. The first two stages always run; the rest only run when their toggle is enabled in Settings:

1. Core — light blue. The data needed to populate the main views: cluster summary, firmware, clients, associations, and per-AP details. When this finishes the app is fully usable.
2. Detail — mid blue. Channel quality, per-AP statistics, RF neighbours, performance metrics, wired-port data, and ancillary cluster info.
3. Spectrum — amber. Per-AP spectrum scans for Channel View and channel-detail cards. Optional (Load Spectrum Data, on by default).
4. BLE — blue. Per-AP Bluetooth discovery. Optional (Load BLE Data, off by default).
5. UCC — green. Voice/Video (Wi-Fi calling, meeting apps). Optional (Load UCC Data, off by default).

Once a stage completes its bar stays filled while the next grows over the top. The optional-stage colours match the dots shown next to their toggles in Settings, so the colour tells you which feature is loading. A full core+detail load completes in around 16 seconds on a healthy mid-sized cluster.

What is Clients & APs?

Clients & APs is a tree view of your cluster, ordered the way you'd reason about it physically: cluster at the top, APs underneath, radios under each AP, and clients under each radio. It's the quickest way to see at a glance which AP a client is on, which radio it's using, and the channel and bandwidth that radio is operating at.

Performance issues are flagged inline: a yellow warning triangle appears on any client row where the client meets the same thresholds used by the cluster dashboard's Issue Breakdown. Radios in monitor mode carry a monitor-mode indicator.

A wired topology overlay is also available, showing how each AP is connected back through your switching infrastructure where that information is visible to the VC.

What is Channel View?

Channel View presents a WiFi-Explorer-style view of every AP radio in your cluster, drawn across the 2.4, 5, and 6 GHz bands. Each AP radio appears as a bar:

• Bar position — the channel the radio is operating on
• Bar width — the bonded channel width (20, 40, 80, or 160 MHz)
• Bar height — the transmit power in dBm
• Diagonal stripe — marks the primary 20 MHz channel within a bonded block

Sub-band shading along the top and baseline distinguishes ISM, UNII-1 through UNII-8, DFS channels, and 6 GHz PSC channels. Tap any bar to open the Channel Detail card, which shows utilisation, SNIR, noise floor, interference breakdown, and any neighbouring SSIDs on the same channel.

For bonded channels wider than 20 MHz, the Channel Detail card includes a sub-channel picker — a row of chips for each 20 MHz block within the bond, coloured by per-block quality so you can immediately see which sub-channel is dragging the overall channel down.

When Load Spectrum Data is enabled, foreign and rogue SSIDs detected by your APs are overlaid on the chart as translucent ghost bars on a separate RSSI scale on the right gutter. Footer chips let you filter the view to your own radios, foreign SSIDs only, or rogue SSIDs only.

On iPhone in portrait, this view is reached via the Channels tab in the bottom bar. On iPad and on iPhone in landscape, it's Channel View in the Monitor section of the sidebar.

What is the Spectrum data toggle in Settings?

Spectrum data is an additional set of API calls that IAPViewer makes against each online AP to retrieve detailed RF information — channel quality scores, SNIR, non-WiFi interference breakdown (Bluetooth, microwave, cordless phones, LTE-U, etc.), active interferers, and recent spectrum alerts.

This is the data that powers:

• The Spectrum sections in AP Detail
• The detailed metrics shown when tapping a channel in Channel View or Channel Quality
• Foreign and rogue SSID overlays in Channel View
• Spectrum-alert history in Channel Detail and AP Detail

It runs as a third loading stage after the rest of the cluster data is ready, so the app stays usable while it completes. On a 12-AP cluster it adds roughly 3–5 seconds to the overall load time.

What is Voice & Video (UCC)?

An optional view of the Unified-Communications sessions your cluster can see — Wi-Fi calls, FaceTime, and meeting apps like Teams, Zoom, and Meet. It groups them into Now (a call in progress), Registered (Wi-Fi calling is ready but idle), and Recent. IAPViewer distinguishes an active call from an idle registration by watching the encrypted tunnel's traffic counters between refreshes. It's off by default — enable Load UCC Data in Settings → Data Loading. The view loads as the green stage on the load bar.

What is BLE Discovery?

An optional Bluetooth Low-Energy scan: each AP reports the BLE radio it has plus the asset tags and beacons it currently hears. When enabled, every AP in the Clients & APs tree gains a BLE radio node, and a dedicated BLE Discovery browser aggregates every device the cluster hears (de-duplicated across APs, with vendor attribution). Enable Load BLE Data in Settings → Data Loading; it loads as the blue stage on the load bar.

What is the Event Log?

A per-site record of what happened during your sessions — connection events, API failures, why a session ended, which VC IP was used, and a per-load breakdown (call counts and timing). Open it from the site editor (next to Test API) or Settings → Session & API → View Event Log. If you ever hit an intermittent problem, this is the first thing to check — and you can email it to support in one tap. For the deepest detail, turn on Verbose Logging to record every call plus a per-AP health snapshot (firmware, uptime, reboot cause, Aruba Central / Activate status).

Why was I returned to the login screen?

For security, IAPViewer signs out of the controller when the app goes to the background. To avoid logging you out for a quick glance at another app, there's a grace period — Settings → Session & API → Keep session on switch (default 30 seconds). Come back within that window and your session is preserved; stay away longer and you'll need to log in again. Sending a support email or opening the support site does not log you out. The 14-minute inactivity timeout still applies regardless.

Why do some views return errors if I navigate too quickly after login?

IAPViewer runs every controller request strictly one-at-a-time across all background and on-demand work, so navigating through views (or opening the Voice/Video page) while the initial load is still running is safe — it won't drop data.

If you do still see API errors, this is almost always a sign that your Virtual Controller is struggling to keep up with the rate of requests. See Common Issues → Adjusting the API call gap below.

What do the connection-error dialogs mean?

IAPViewer surfaces connection problems through four cause-specific dialogs, each explaining exactly what went wrong:

• Session timeout — your VC session expired while the app was idle. Sign back in and continue. VC sessions time out after 15 minutes of inactivity.
• Network unreachable — your device couldn't reach the VC at all. Check Wi-Fi, VPN, and that you're on a network that can route to the VC IP.
• VC refused the request — the VC is reachable but rejecting REST API calls. Most commonly this means the REST API isn't enabled, or there's an authentication issue.
• Firmware not supported — the VC is running a firmware version IAPViewer can't work with. This dialog links to this support site.

Login-screen errors are shown in plain language too. Underlying HTTP and URL error codes are translated into readable text — for example, "Username or password is wrong" instead of "HTTP 401 from VC".

What does the orange warning triangle on Disconnect mean?

It means your VC session is about to time out. VC REST sessions expire after 15 minutes of inactivity, and the triangle is a heads-up that you're close to that limit.

Any activity in the app — refreshing data, navigating between views, or tapping into a detail card — resets the 15-minute timer. The triangle clears automatically once activity is detected.

On iPhone the warning is accompanied by a slim banner above the main content. On iPad and Mac it appears as an inline caption under the Disconnect row in the sidebar.

How accurate is RF Location?

RF Location is an experimental probability estimator, not a precision locator. Set it up once by placing your APs on the map in Settings → Site Setup → AP Placement; estimates then appear in the Location Estimate section of each foreign network's detail card in RF Neighbors. It does not put a pin on a neighbour AP or client the way GPS would. For each detected RF neighbour, it takes the RSSI values reported by your own APs and computes a range of likely distances and directions — a probable area, with a minimum and maximum bound, rather than a coordinate.

All results are derived entirely from data returned by the installed, online, and responding APs. IAPViewer has no other source of truth. Where multiple APs hear the same neighbour, their probability rings overlap; where the overlaps are tight, the estimate is tighter. Where they are loose, so is the answer.

What makes estimates better or worse

Accuracy depends almost entirely on your AP deployment, not on the app. Estimates improve when:

• More APs hear the same neighbour — two APs give a rough line, three or more begin to give a meaningful area
• Those APs are physically separated — neighbours heard only by APs clustered in one part of the building cannot be triangulated meaningfully, regardless of signal strength
• APs are installed uniformly — similar model family, similar mounting height, similar orientation. Mixed hardware and mixed mounting (ceiling vs. wall vs. desk vs. inside a closet) breaks the path-loss assumptions the calculation relies on

Most real-world installations were designed for client coverage, not RF geolocation. APs are commonly placed for convenient cable runs, mounted behind obstructions, oriented inconsistently, or spaced unevenly. All of this is perfectly fine for serving Wi-Fi, and all of it reduces the precision of RF Location results. Expect your own site to fall into this category — it is the norm, not the exception.

How to read the results

Treat probability areas as "this neighbour is more likely here than there," not as a fixed pin. A tight, well-defined peak means the geometry of your install happened to work in your favour for that particular neighbour. A broad, fuzzy area means the data simply does not support a tighter answer, and no amount of computation will change that.

What does RF Neighbors show?

RF Neighbors is the cluster's complete view of every other Wi-Fi network and device its radios can hear — your own SSIDs, foreign networks, and any APs that have been classified as rogue. It's organised by SSID, with each SSID expanding to show the individual BSSIDs detected and which of your own APs is hearing them.

The data is aggregated from every online AP in your cluster, not just from the Virtual Controller AP. This is important: a single AP's view of the RF environment is heavily biased toward whichever band it happens to be scanning on, and the VC's own radio is usually serving clients rather than monitoring. By gathering scan results from each AP and merging them — keeping the strongest signal where the same neighbour is heard by multiple APs — IAPViewer gives you a complete picture across 2.4, 5, and 6 GHz.

Does IAPViewer access my location?

On iOS and iPadOS, the app requests your device location to centre the RF Location map on your current position when you first open it. Permission can be granted or revoked at any time in Settings → Privacy & Security → Location Services → IAPViewer.

On Apple Silicon Macs running the app as "Designed for iPad", macOS may prompt for location permission depending on your system configuration. If it does, location is determined by macOS using available network signals rather than GPS hardware, and is used only to centre the map.

Your location is never stored on your device and never transmitted off the device.

What do the status symbols and colours mean?

IAPViewer speaks one severity language everywhere — the cluster dashboard, the tree, and every detail card. Each level pairs a distinct shape with its colour and a written label, so nothing is ever conveyed by colour alone (deliberately colour-blind-safe):

• Green circle with a check — all clear. Healthy rows, passing checks, "all reporting" status tiles.
• Blue circle with an "i" — ADVISORY. Worth knowing, not urgent: a client with poor signal, slow speed, or asymmetric RF; an AP's slow wired uplink; a configuration change while you were away; a power restriction that Intelligent Power Management is handling; an AP model at its firmware ceiling.
• Amber triangle — DEGRADED. Actively hurting performance: a client with poor SNR or a high retry rate; a power-restricted AP with nothing managing the trade-off; the app connected via the backup VC IP. The label next to the triangle always states which one.
• Red octagon — CRITICAL. Infrastructure problems only: an AP offline and not reporting to the VC, or — in Firmware Compatibility — an AP that cannot run the firmware you're evaluating. A struggling client is never critical: client health can't paint the cluster red.

Where you'll meet them: the cluster dashboard's Issue Breakdown lists every current issue with its severity tag and the clients or APs affected; the tree marks only flagged rows with a glyph (healthy rows stay clean); and detail cards lead with a Performance Impact card in the same language. One thing that is not part of this ladder: the Good / OK / Poor labels on metric bars (signal, speed, retry) grade that one measurement, not the device.

What is the Firmware Compatibility view?

Firmware Compatibility shows what firmware your fleet can run — before you commit to an upgrade or a purchase. On iPad and Mac it's the Firmware entry in the Tools section of the sidebar; on iPhone it's reached via Settings → Tools.

• Supported Firmware Window — the range of Instant versions every AP in your fleet supports, naming the models that set the floor and the ceiling
• At a Glance — one row per Instant version, with your current version tagged, supported / blocked counts, and what it would take to move to each version
• Evaluator — tap a version for the full picture: a Good / Bad / Excluded scorecard, per-AP rows explaining why a model fails, suggested replacement models, and include / exclude checkboxes for modelling a removal or replacement
• Consider a model — evaluate an AP model against your cluster before buying it, without it ever counting as part of your fleet

The compatibility data and replacement rules are bundled with the app and updated automatically in the background when a newer version is available; both can be inspected under Settings → Reference Data.

Offline Clients?

IAPViewer keeps a per-site record of wireless clients it has seen connected to your cluster. Clients that were previously online but are no longer present appear as dimmed rows in the Clients & APs tree, marked "offline" with how long ago they were last seen.

This is useful for tracking down devices that have left the network, investigating whether a specific device has ever connected, or identifying stale entries that are no longer relevant.

• Client history is stored only on your device and never transmitted
• The retention period is configurable in Settings → Client History (default 90 days)
• Settings → Client History → Clear Offline Client History removes every stored offline client for the site