IAPViewer Documentation

This page is the screen-by-screen user guide. For installation, contact, and FAQ-style troubleshooting see the Support page.

Feature overview

IAPViewer gives you a live, read-only view of your Aruba Instant cluster — channels, clients, RF neighbours, and spectrum health — and, for the changes you might actually want to make (blocking or disconnecting a client, rebooting an AP), it prepares copy-and-paste CLI scripts that you apply yourself. The highlights below are each described in detail later on this page.

Highlights

Platform-native navigation

• iPad and Apple Silicon Mac: persistent sidebar with three sections (Monitor, Tools, App).
• iPhone in portrait: native tab bar with five tabs (Clients & APs, Channels, RF Neighbors, Settings, Disconnect).
• On Mac, IAPViewer runs as the iPad app via "Designed for iPad".

Channel View (Channels tab)

• A WiFi-Explorer-style cluster spectrum view of every AP radio across 2.4 / 5 / 6 GHz.
• Bar position = channel, width = bonded block (20–160 MHz), height = TX power.
• Foreign and rogue SSIDs detected by your APs are overlaid as translucent ghost bars on a second RSSI scale.
• Tap any ghost bar to open a Foreign SSID Detail card scoped to the specific BSSID you tapped.
• Hidden foreign SSIDs that broadcast on randomized MAC addresses are vendor-attributed by cross-referencing their broadcast siblings within the cluster.

Channel Detail

• Bonded sub-channel picker — for any 40 / 80 / 160 MHz channel, a chip row breaks the bond down into its 20 MHz blocks and tints each by per-block quality so you can see which sub-channel is dragging the score.
• Spectrum panel — SNIR bar, WiFi vs interference utilisation split, non-WiFi interference breakdown by type (Bluetooth, microwave, cordless, etc.), active interferer list, and recent spectrum alerts.
• Spectrum alerts are band-aware — a 2.4 GHz microwave's alert won't leak into a 5 GHz channel card.

Per-client diagnostics

• Separate Down Speed and Up Speed bars in Client Detail, with speed-asymmetry detection (down vs up ≥ 3× triggers a dedicated reason instead of generic "Slow Speed").
• "Mgmt?" detection — when a client's recorded speed falls below its SSID's configured minimum, the bar is labelled amber "Mgmt?" instead of red "Poor", since the snapshot is almost certainly a management frame rather than real data throughput. Suppresses false alerts on IoT devices that rarely receive downlink data.
• Signal-stability bar between Signal and Noise Floor — the range the client's signal covered over the last few minutes, rated by its worst sample so an unstable client is visible even when the current reading looks fine; noise floor comes from the AP's own channel measurements.

Fast, layered loads

• Layered load bar — the core and detail stages always run; spectrum, BLE, and UCC stages run only when their toggle is on.
• Per-AP client-table fetching keeps a typical 12-AP refresh to around 86 API calls and full loads to roughly 11 seconds.
• Per-AP monitor-list aggregation surfaces 5/6 GHz neighbours the VC's own scanning radio can't see, merging them into the RF Neighbors tree.
• Core Haptics drive the load-bar feedback, kept in step with the bar.

Resilience and diagnostics

• Fallback VC IP — each site can carry an optional secondary VC address. IAPViewer silently retries against it when the primary fails (typical after the Aruba floating-IP rebind failure following a cluster reboot). On a successful connect the app auto-fills an empty fallback with the conductor AP's real IP — a hand-entered value is never overwritten. Two consecutive fallback connects prompts a swap.
• Test API button in the site editor — a self-contained pre-login REST probe that captures the raw request/response transcript for login, show version, and logout. Copy log puts the whole thing on the clipboard for support.
• Connection failures produce four cause-specific dialogs — session timeout, network unreachable, VC refused, or unsupported firmware — with plain-English login errors ("Username or password is wrong" rather than HTTP codes).

Settings and presentation

• Settings organised by purpose: Appearance, Data Loading, Filters & Thresholds, Client History, Site Setup, Session & API, and Reference Data.
• Four colour palettes — Default, Colour Blind Safe, High Contrast, and Monochrome — with five distinct semantic colours per palette, so status always reads clearly.
• Text size follows the iOS system Text Size setting (Settings → Display & Brightness on your device) — there is no separate in-app font control.
• Customisable client-icon rules: define keywords that map hostnames to symbols in the topology tree.

Getting connected

Sites

IAPViewer organises every cluster you connect to as a site. The site stores the Virtual Controller address, the optional fallback address, the username, and per-site preferences (RSSI cutoffs, client history retention, API call gap, fallback prompt state). Passwords are held in the iOS Keychain, not in the site record.

From the login screen:

• Tap the site row to open the site list. Add a new site with the + button, or tap any saved site to edit it.
• Edit Site fields: name, icon, VC host:port, username, fallback VC host:port (optional), password (writes to Keychain), and Test API.
• Swipe a site left in the list to delete it.
• "Try Demo" enters a demo site with sample Acme Corp data — useful for inspecting every feature without hardware.

Test API

The site editor includes a Test API button that runs a pre-login REST probe against the configured VC and, if present, the fallback. The probe runs POST /rest/login, then read-only show version and show aps queries via GET /rest/show-cmd, then POST /rest/logout, and displays each step with the raw request and response.

The VC's REST API must be enabled before the first connect — it's off by default on Instant firmware. The connection screen shows the steps in the app, and the support FAQ covers them in full, including the Aruba Central–managed case.

• Failed steps expand automatically so the diagnostic is in front of you on open.
• Re-run in the toolbar replays the probe.
• Copy log puts the whole transcript onto the clipboard for pasting into a support email.
• Email log to support opens a pre-filled message with the transcript attached.
• Open support site opens https://iapviewer.bdlfoundry.dev in Safari.

Sending that email (or opening the support site) doesn't log you out — see Keep session on switch under Settings.

Fallback VC IP

Each site can carry an optional secondary VC address. When the primary fails to bootstrap because of a network or VC-refusal error, IAPViewer silently logs in against the fallback and shows a notice once you're connected. Details:

• The auto-retry only fires for network-level failures, not for incorrect credentials or unsupported firmware.
• The site needs a stored Keychain password for the silent retry to work — biometric-protected credentials qualify.
• After two consecutive successful connects via the fallback, the app prompts to swap the primary and fallback addresses (the swapping VC has clearly become the more reliable one).
• Sites without a fallback get one automatically: on a successful connect the app fills the empty fallback field with the conductor AP's real IP — exactly the address that keeps answering when the floating VC IP fails to rebind. A hand-entered fallback is never overwritten, the auto-fill is skipped when the primary already is the conductor's address, and the event log records it when it happens.

Login errors

Every connection failure now produces a cause-specific dialog rather than the old generic "Firmware Version Error":

• Session timeout — VC sign-out after 15 minutes of inactivity. Log in again to continue.
• Network unreachable — couldn't reach the VC at all. Check Wi-Fi, VPN, and routing to the VC IP.
• VC refused the request — the VC is reachable but rejecting REST API calls. Usually REST API isn't enabled, or there's an auth issue.
• Firmware not supported — VC firmware is outside IAPViewer's tested range. Dialog links to this site for the supported-firmware list.

Login-screen errors are translated into plain English ("Username or password is wrong", "Couldn't reach the VC in time. Check your network and the address, then try again.") rather than HTTP codes.

Navigation

The navigation surface adapts to the device:

iPad & Apple Silicon Mac ("Designed for iPad")

A persistent sidebar runs down the left, organised into three sections:

• Monitor — Clients & APs, Channel View, RF Neighbors, UCC
• Tools — Channel Quality, Deny List, Config, Logs, VSG Check, Firmware, Exports
• App — Settings, Disconnect

In portrait orientation the sidebar is hidden by default and swipes out from the left edge.

iPhone Pro / Max in landscape

Same sidebar; hidden by default and swipes out from the left edge.

iPhone in portrait

A native tab bar runs along the bottom with five tabs:

• Clients & APs — the hierarchical tree
• Channels — Channel View
• RF Neighbors
• Settings — also surfaces the tools (Channel Quality, UCC, Deny List, Config, Logs, VSG Check, Firmware, Exports — plus an Offline AP Cleanup Script entry whenever an AP is offline) as pushed screens
• Disconnect — turns amber with a warning triangle when your VC session is less than two minutes from timing out

Loading indicators

A thin progress strip runs along the top of the screen during loads. Each stage has its own colour and fills in turn; a light haptic pulses once per completed call, in step with the bar. The two core stages always run; the rest only run when their toggle is enabled in Settings.

1. Core — light blue. 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 info.
3. Spectrum — amber. Per-AP spectrum scans for Channel View and Channel Detail. 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), and a quick final pass.

The optional-stage colours are mirrored as a small dot next to each toggle in Settings, so the colour on the bar tells you which feature is loading. You can navigate freely while loading — views populate as their data arrives.

Clients & APs (hierarchical tree)

The primary monitoring surface. The cluster is shown as a tree:

Site
  ├── AP
  │     ├── Radio (band, channel, width)
  │     │     ├── Client
  │     │     └── Client
  │     └── Wired Interface
  │           └── LLDP Neighbour
  ├── AP …
  └── Offline AP (italicised + dimmed)

What it shows

• Site row — site pill with a cluster-health glyph, AP count, and client count, tinted by the worst state currently present in the cluster. Always visible.
• AP rows — name, a "VC" badge on the conductor, and online state. Offline APs are italicised with an "Offline" tag. Per-AP client counts and band summaries live on the cluster dashboard, keeping the rows clean.
• Radio rows — a radio marker coloured by mode (green = serving clients, orange = monitoring), then the band, channel, and width in the band's colour — e.g. "5 GHz · ch 36E · 80 MHz". Monitor-mode radios carry a MON badge; a radio whose wireless networks are all disabled carries an OFF badge instead of masquerading as "monitoring".
• Wired Interface rows — port name, plus a blue advisory info-circle when the negotiated speed is ≤100 Mbps.
• Client rows — device icon (matched from your icon rules, tinted by band), name, and a severity glyph when the client is currently flagged: amber triangle for degraded conditions, blue info-circle for advisories.
• LLDP neighbour rows — appear under each wired port with the neighbour's system name; switches get a distinct icon. The full LLDP detail (port, IP, capabilities, PoE) lives on the wired-port card.
• Ghost rows — clients that have just roamed away appear italicised and dimmed with their move destination, so you can trace a roam in real time.

What you can do

• Type into the search field (iPhone landscape / iPad) or use the rotate-to-search hint on iPhone portrait — matches against APs, radios, and clients and narrows the whole tree.
• Use the expand-all / collapse-all chevrons at the top.
• Tap an AP row to open AP Detail. Offline APs are tappable too: their card shows the AP's last-known identity, when it was last seen online, and — when the app knows the switch port it was plugged into — a "where to look" section with that port highlighted, so you can walk to the right cable.
• Tap a radio row to open AP Detail focused on that radio's parent AP.
• Tap a wired interface row to open the wired-port detail panel — link state, speed and duplex, Power, and the LLDP neighbour, including the simulated switch front panel where possible. Full detail and the supported-switch table in Wired ports & LLDP neighbours.
• Tap a client row to open Client Detail.
• Tap the site pill to open the cluster dashboard.
• Pull down to refresh the cluster.

Performance flagging

A warning triangle appears inline on client rows that meet your configured retry threshold or signal limits — the same conditions the cluster dashboard's Issue Breakdown counts. Tapping into Client Detail from a flagged client leads with its Performance Impact card.

Wired ports & LLDP neighbours

Tapping a wired interface row in the tree opens the wired-port detail panel: link state, speed and duplex, a Power section on the port that powers the AP (draw, PoE granted vs requested, power status), and the LLDP neighbour — the switch on the other end of the cable, with its port, IP, capabilities, and allocated PoE. A port negotiating ≤100 Mbps also gets a Slow Wired Link advisory card explaining what's capped and what to check.

Simulated switch front panels

When the neighbour is a recognised switch, the card draws a miniature front panel of that switch with the port the AP is plugged into highlighted — so "port 14 of 48" is something you can see, not just read. The drawing only ever asserts what LLDP proves: if a switch doesn't share enough information to draw it honestly, the card says so instead of guessing.

CX and FS switches share only a model identifier over LLDP, so each model's port layout is entered individually — sourced from HPE's official product data, and hardware-verified where units are available. Instant On and AOS-S describe their own port counts over LLDP, which is why every model in those families works.

Don't see your switch — or stuck on "Not yet"? You can supply the evidence yourself, straight from the app: turn on Verbose Logging (Settings → Session & API), load your cluster once, then open View Event Log and tap Email log to support. The log records the raw LLDP data your switch broadcasts about itself — exactly the evidence needed to add the model and draw its front panel in a future update.

Wired topology overlay

Per-AP port speed/duplex and a single cluster-wide LLDP fetch are pre-fetched automatically in the background after the critical-path load. The information is then available wherever a wired port or LLDP neighbour appears.

Cluster dashboard

Tap the site pill at the top of Clients & APs to open the cluster dashboard — a NOC-style summary of the cluster's current health. The pill is the doorway: its glyph and tint always reflect the worst state currently present in the cluster, and when the cluster first enters a critical state the app also raises a one-time alert, so you don't have to be watching the pill to catch it.

• Needs Attention — the current issues, one row each with its severity and a plain-language explanation. This includes infrastructure conditions as well as client problems: running on the fallback VC IP (degraded), an AP not receiving full PoE power (a blue advisory when Intelligent Power Management is managing the restriction, amber degraded when nothing is), an AP uplink stuck at 100 Mbps ("slow wired link" advisory), an AP whose wireless networks are all disabled — online but broadcasting nothing (blue advisory), or "Config changed" — the configuration changed while you were away from the app; tapping the row opens the Config screen's comparison. Infrastructure rows tap through to the relevant AP, port, or screen. Empty when the cluster is healthy.
• Status — two tiles: Access Points (online / total, with an "All reporting" or "N offline" read-out) and Clients (associated count and how many currently have issues), each with a segmented health bar.
• Issue Breakdown — every issue type with its severity tag and affected-client count, with an "updated … ago" read-out that resets whenever fresh numbers arrive (opening a client's detail card refreshes its whole AP, so the lists genuinely move). Expand a row to list the affected clients — worst first, each with its measured value (e.g. "19 dB", "62%"); tap a client to open its Client Detail. A client tripping more than one condition carries a small count next to its name, so meeting the same device in another list reads as one linked problem rather than a coincidence.
• Virtual Controller — VC name, VC IP, conductor IP, and management mode (locally managed vs Aruba Central).
• Firmware — running version (with a link to Aruba's release notes), uptime, last reboot, and reboot reason.
• Servers — the cluster's DNS, NTP, syslog, and RADIUS servers.

Channels (Channel View)

A WiFi-Explorer-style cluster spectrum view. The screen is reached from the Channels tab on iPhone, or Monitor → Channel View in the sidebar on iPad.

The chart

One band at a time (2.4 / 5 / 6 GHz, selected from the segmented band picker). Each AP radio in the cluster is drawn as a bar:

• Bar position — channel
• Bar width — bonded channel width (20, 40, 80, or 160 MHz)
• Bar height — TX power in dBm (left Y-axis)
• Diagonal stripe — the primary 20 MHz channel within the bonded block
• Sub-band shading — ISM, UNII-1..8, DFS, and 6 GHz PSC channels are colour-coded along the top and baseline of the chart

When spectrum data is enabled, foreign and rogue SSIDs detected by your APs are overlaid as translucent ghost bars on a separate RSSI scale shown on the right.

What you can do

• Use the band picker to switch between 2.4 / 5 / 6 GHz. Your last band is remembered.
• Tap a footer pill to filter to your own radios only, foreign SSIDs only, or rogue SSIDs only. Tap again to clear.
• Tap an own-cluster bar to open Channel Detail focused on that AP and channel.
• Tap a ghost bar to open Foreign SSID Detail for that specific BSSID.

Channel Detail

Opens from Channel View (tap a bar) or from Channel Quality (tap a row). Shows the full picture for one channel.

Sections, in order

1. Bonded sub-channels (only on bonded channels > 20 MHz) — one chip per 20 MHz block in the bond, tinted by per-block quality and marked "P" for the primary. Tap a chip to inspect that sub-channel's readings.
2. Channel Health — gauge ring with Quality score, stacked Utilization bar (WiFi vs Interference), Noise Floor, SNIR, Retry Rate. Each bar has a doc-icon button for an explainer sheet.
3. APs on This Channel — each AP's model, scanning state, client count, utilisation, and quality. The AP you tapped (if any) is highlighted with a SELECTED tag. A warning triangle appears on APs reporting non-WiFi interference.
4. Interfering SSIDs on this channel — foreign networks observed on this channel with manufacturer, PHY, width, AP type, RSSI.
5. Non-WiFi Interferers — Bluetooth / Microwave / Cordless Phone / Other breakdown, plus active interferers and the channel's spectrum-alert history.
6. Suggestions — contextual advice based on the readings (non-standard 2.4 GHz channel, DFS, high co-channel AP count, etc.).

Notes

• Spectrum-derived bars are hidden when every AP returned limited-scan sentinel zeros for the channel.
• Spectrum alerts are filtered to this band — alerts from other bands show as a "+ N more" footer line.
• The doc-icon buttons next to Channel Health, Non-WiFi, and Interfering SSIDs open explainer sheets covering what the metric means and how to interpret it.

Foreign SSID Detail

Opens from Channel View (tap a ghost bar). Scoped to the specific BSSID you tapped, not aggregated across all radios.

What it shows

• Title — ESSID (or "[Hidden network]") and the worst observed classification (Interfering / Rogue).
• Identity — signal, bandwidth, channel range, centre channel and frequency, BSSID, and manufacturer. When the vendor was inferred from a cluster sibling, an "Inferred from" row carries the anchor BSSID.
• Broadcasting Radios — every BSSID heard sharing this ESSID across the cluster, with band, channel, width, vendor (or "Vendor unknown — primary BSS not observed" for unresolvable randomised cases), RSSI, SNR, and client count. The tapped row carries a TAPPED chip.
• Classification — observed types, encryption modes, and PHY types.

RF Neighbors

The cluster's complete view of every other Wi-Fi network its radios can hear — your own SSIDs, foreign networks, and any APs classified as rogue.

Organised as a tree: SSID → BSSID → (expandable) clients on that BSSID.

• SSID rows — name, classification chip (rogue / interfering), BSSID count.
• BSSID rows — RSSI bar, MAC, manufacturer, channel badge (coloured by band), PHY badge, encryption badge.
• Client rows — MAC, manufacturer, channel, signal.

What you can do

• Type into the search field (iPhone landscape / iPad) to filter by SSID, BSSID, or manufacturer.
• Tap an SSID row to expand or collapse it.
• Tap the client-count row under an SSID to show or hide its clients.
• Use the expand-all / collapse-all chevrons.
• Pull down to refresh.

The RF RSSI Cutoff preference (Settings → Filters & Thresholds) hides BSSIDs and SSIDs whose signal is weaker than the configured threshold (Aruba's positive scale — higher = weaker).

Client Detail

The per-client card. Reached from Clients & APs, Clients, the cluster dashboard's Issue Breakdown, Search, and the Connected Clients list inside AP Detail.

Sections

• Performance Impact — leads the card. When a wireless client has issues, they are the first thing you see, using the same severity language as the cluster dashboard: the flagged issues (Slow Speed, Poor Signal, Poor SNR, High Retry, Asymmetric RF, Mgmt Frame) with doc-icon explainer sheets, plus the fast peers being harmed. A healthy client skips straight to Identity.
• Identity — name, IPv4 / IPv6, MAC, manufacturer, operating system.
• Connection — SSID, AP, BSSID, band, channel + width, PHY, role, association time. Wired clients show the wired interface here.
• Signal Health — Signal, Signal stability (the range covered over the last few minutes, drawn as a band on the scale — a narrow band means a steady link), Noise Floor, Down Speed, Up Speed, Last Uplink Signal, Last Downlink Signal, Retry Rate. Each bar carries a scaled fill with a Good / OK / Poor label, bold-coloured to match the value. If the client drops out of its AP's live table (asleep or just gone offline), the live rows are replaced by a note saying so.
• Current Throughput — live down / up.
• Security — auth type, type, detail, and a row of capability pills (WMM, 11k, 11v, PMF, 11r, SAE, etc.). Tap any pill for a sheet explaining that capability.
• Mobility Trail — recent roaming events.
• Recent Stats — timestamped snapshot rows with signal / link-rate / throughput.
• Roam Cache.
• Traffic Sessions — datapath sessions with source/destination, protocol, flag string, and DENY badge.
• Actions — closes the card (wireless clients only). Two amber-marked tools that generate CLI for you — the app never runs anything itself:
  • Disconnect client — two copyable terminal blocks: the SSH login for your Virtual Controller, then a disconnect-user command. A one-time kick; the client can rejoin immediately.
  • Add to Deny List — queues this client in the Deny List page's builder, then offers to jump straight there (or close the card and pick another client). Randomised MAC addresses carry a note that the device may return on a different address.

The Mgmt? label

When Down Speed is below the SSID's configured minimum TX rate (g-min-tx-rate / a-min-tx-rate), the bar is labelled amber "Mgmt?" instead of red "Poor". The snapshot is almost certainly a management frame rather than real data throughput, which is why IoT devices (cameras, smart switches, plugs) would otherwise misleadingly appear as Slow Speed. The doc-icon next to the row opens an explainer sheet.

What you can do

• Tap any capability pill or doc-icon to open an explainer sheet.
• Tap the refresh icon in the toolbar to re-poll live data.
• Pull down to retry on the rare load failure.

AP Detail

The per-AP card. Reached from any AP / radio row in Clients & APs.

Sections, in order

1. Identification — name, IP, model, serial, MAC, uplink port, Wi-Fi capability, status, uptime, mode.
2. Version Support — Instant minimum and maximum supported firmware for the model. A blue informational note appears when the model is capped before 8.13 — the ceiling is a property of the model, not a fault.
3. Power Management — current and average draw, power supply and status, per-port PoE (watts granted vs requested), per-radio power state, CPU throttle, and whether Intelligent Power Management (IPM) is enabled. When the AP reports a power restriction, a Power Restricted impact card leads the screen — a blue advisory if IPM is managing the trade-off, amber degraded if IPM is off and nothing is.
4. LED Status — System LED state, plus a composite Radio LED row with a per-radio breakdown on multi-radio APs.
5. Radios — one section per active radio: channel, TX Power, Channel Utilisation, and Noise Floor bars.
6. WLANs — BSSIDs grouped by ESSID, each with PHY, band, and bandwidth.
7. Spectrum — per-channel Quality, SNIR, WiFi utilisation, non-WiFi breakdown by type, active interferers grouped by band, and recent spectrum alerts. Doc-icon buttons open SNIR and non-WiFi explainer sheets.
8. Connected Clients — every client currently associated to the AP.
9. Actions — a red-marked Reboot this AP tool that generates CLI for you (the app never runs anything itself): two copyable terminal blocks — the SSH login for this AP's own address, then reload. The bullets beneath spell out the consequences: reload asks you to confirm (y), and every client on the AP drops while it restarts. On the Virtual Controller's own card an extra warning notes that rebooting it hands control to another AP in the cluster. Shown only while the AP is online.

What you can do

• Tap any client row to open Client Detail.
• Tap the refresh icon in the toolbar to re-poll LED status, BSSIDs, and spectrum.
• Tap the doc-icon next to a Spectrum section for the relevant explainer.

Generated CLI scripts

IAPViewer never changes your controller itself — but wherever a change is the natural next step, it writes the complete script for you: the Deny List builder, the Client Detail card's Disconnect and Add to Deny List actions, and the AP Detail card's Reboot action. The app presents them as copyable terminal blocks, exactly as shown below (values from the demo site). It has no SSH capability and never sends any of this — you review the script and run it on the VC CLI yourself.

The SSH login is always a separate block from the commands that run inside it — pasted together, the password prompt would swallow the commands. Copy and run the blocks in order.

Disconnect a client — Client Detail → Actions

Runs on the Virtual Controller. A one-time kick — the client drops and can rejoin immediately.

Block a client — Deny List → How to apply

Runs on the Virtual Controller. Applying blocks the client immediately; unblocking generates the matching no denylist-client lines instead. A caution line in the app states exactly what applying will do before you copy anything.

Reboot an AP — AP Detail → Actions

Runs on the AP itself — the SSH step targets that AP's own address, not the VC. reload asks for confirmation (y) and drops every client on that AP while it restarts. On the virtual controller's own card, the app adds a warning that rebooting it hands control to another AP in the cluster.

Voice & Video (UCC)

A live view of the Unified-Communications sessions your cluster can see — Wi-Fi calls, FaceTime, and meeting apps (Teams, Zoom, Meet). It's off by default; enable Load UCC Data in Settings → Data Loading to populate it. Reached from the sidebar (iPad) → Monitor → UCC, or iPhone Settings → Tools.

What it shows

Sessions are grouped into three sections:

• Now — an active call/session in progress. A green phone (or video) icon, the app/carrier, the serving AP, and a quality read-out ("audio good", etc.).
• Registered — Wi-Fi calling is set up and the IPsec tunnel is up, but no call is in progress. The device is ready to place a call over Wi-Fi; this state doesn't drain battery.
• Recent — recently classified UC clients that are now idle.

IAPViewer tells an active call from an idle registration by comparing the IPsec tunnel's traffic counters against the previous refresh, cross-checked with call-detail records and datapath sessions on the serving AP.

What you can do

• Tap a row to open its detail card (carrier/app, codecs where visible, the serving AP, and the underlying signals).
• Pull down to re-evaluate without a full cluster reload.

BLE Discovery

Surfaces the Bluetooth Low-Energy environment each AP can hear — asset tags and beacons. Off by default; enable Load BLE Data in Settings → Data Loading. When on, two things appear:

• In the Clients & APs tree, each AP gains a BLE radio node listing the beacon-class devices that AP currently hears.
• A dedicated BLE Discovery browser (Settings → Site Setup) aggregates every heard device across the whole cluster, de-duplicated by device address, with vendor attribution and the strongest-hearing AP.

Generic beacons that broadcast from rotating (private) addresses are attributed by their Bluetooth-SIG company ID rather than a hardware vendor; named asset tags (e.g. Aruba tags) are identified directly. The cluster's own AP radios are filtered out of the results.

Naming & icons (Customize)

Any client or BLE device detail card includes a Customize section that lets you pin a friendly name and an icon to that device. The topology tree picks the change up immediately.

• Name — type a label; it commits when you tap Done or leave the field (not per keystroke). Leave it blank to fall back to the auto-derived name.
• Icon — opens a sectioned icon grid; the choice applies straight away.
• Reset to default — clears the custom name and icon.

Channel Quality

Stacked-card list of every channel the cluster's APs are using, grouped by band. Reached from the sidebar (iPad) → Tools, or iPhone Settings → Tools. Each card shows channel number, an overlap warning ("Overlaps ch 1 & 6") on non-standard 2.4 GHz channels, Good / OK / Poor pill, a Quality bar, a stacked WiFi/Interference utilisation bar, a Noise Floor bar, and a horizontally scrollable row of AP pills. A warning triangle appears on AP pills that are reporting non-WiFi interference.

Tap any card to open Channel Detail.

RF Location & AP Placement

An on-demand probability estimator for foreign Wi-Fi sources, based on the RSSI readings your own APs report. It has two parts: a one-time AP Placement setup (Settings → Site Setup → AP Placement), and per-network Location Estimate results shown inside the foreign network's detail card in RF Neighbors.

Setup — AP Placement

Open Settings → Site Setup → AP Placement and place each of your APs on the map once. Placements are saved per site, on your device only.

• Tap the map to drop a pin; when several APs are unplaced, a sheet asks which AP the pin represents.
• Drag a pin to move it; remove it from its callout.

Reading an estimate

Open a foreign network's detail card from RF Neighbors. Its Location Estimate section computes a likely area from the RSSI each of your placed APs reports — a minimum-TX-power blob and a maximum-TX-power blob, with the overlap marking the highest-probability area.

What controls accuracy

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

• More of your APs hear the same neighbour.
• Those APs are physically separated.
• APs are installed uniformly — similar model, mounting height, and orientation.

Most production installs were designed for client coverage, not RF geolocation. Expect your own site to fall in that category — broad fuzzy areas are the norm, tight peaks the exception.

Tools

Reached from the sidebar (iPad) → Tools, or iPhone Settings → Tools.

Deny List

Every client the VC is currently denying — plus a builder that turns your intended block/unblock changes into copy-and-paste CLI. The app itself never changes the controller: you review the generated snippet and paste it into the VC yourself.

• Tiles across the top summarise the state at a glance: DENIED (current count), BLOCK and UNBLOCK (your pending changes), and SNIPPET (lines of generated CLI).
• Add from connected clients opens a picker of currently connected clients (filter by name, MAC, or AP; already-denied rows are marked). You can also type one or more MAC addresses manually, and optionally set a deny time in seconds — the cluster default is 3600 s (1 hour).
• Denied rows show the device name first when the app knows it, plus MAC, vendor (a locally-administered MAC with no vendor is labelled "Randomised address"), expiry countdown, and how many APs report the deny. A copy button on each row copies the MAC.
• Expanding a row shows the per-AP deny reason and timestamp, and automatically fetches the recent authentication events for that MAC.
• Status chips — DENIED, WILL BLOCK, WILL UNBLOCK — keep pending changes visible on every row. Unblock all / Keep all toggles the whole list at once.
• The How to apply card appears whenever changes are pending, with two terminal blocks: the SSH login for your Virtual Controller first, then the command snippet. Copy them with the side-by-side Copy SSH and Copy Snippet buttons (or tap a block directly). They are separate on purpose — pasted together, the SSH password prompt would swallow the commands. A caution line states exactly what applying will do.
• Pull down — or tap the refresh button in the list header — to re-fetch the deny list without a full reload.

Config

Read-only view of the cluster's running configuration — with automatic version history, a change summary, a two-version comparison, and a support export.

• Running Config — shown collapsed to the first 20 lines with a "Show all N lines" expander. Copy config always copies the whole config, regardless of the collapsed state.
• Changes — versions are saved automatically whenever the running config changes (the newest 30 are kept per site). The CHANGES card compares the live config against the version from when you connected: added / removed counts, a short preview of the changed lines, and a Full comparison button. If the config changed while you were away from the app, the cluster dashboard also raises a blue "Config changed" advisory that taps through to this screen.
• Version History — every saved version with its timestamp, line count, and firmware. Compare any two versions (or any version against "Live now"), or open a version to view, copy, or delete it.
• Comparison view — added and removed lines carry + / − markers and counts; unchanged lines can be shown in full or folded down to two lines of context. Secret values (keys, passphrases, communities) are masked and reported as "not comparable" — the VC re-encrypts them differently per AP, so their real values can't be compared from the config text.
• Support export — Copy support bundle copies a diagnostics bundle: a summary of every AP plus the running config with all keys, secrets, and passphrases replaced by a placeholder that says why they were removed. AP serial numbers are not included. Safe to paste into an email or ticket.

Logs

Live log viewer. Three pickers at the top:

• Target AP — defaults to the VC; switchable to any online AP.
• Log type — priority types listed first (debug, sapd, security, system, user, user-debug, wireless), plus 40+ others.
• Line count — 10, 25, 50, 100, or 200.

The running show log <type> <count> command appears as the section header. Each picker change re-runs the fetch after a short debounce. Long-press log lines to select and copy.

VSG Check

A best-practice rule check of the cluster's running config against Aruba's Validated Solutions Guide. Tap Fetch & Validate to pull a fresh running config and run the rule engine.

Results are split into per-SSID sections plus a Global Settings section. Each section carries a pass-percentage pill and "passed / failed / total" subtitle. Tap a check row to expand its What this means and How to fix explanations.

Attribution credits Aaron Scott's Central Automation Studio, which inspired the rule set. Flagged checks indicate deviation from the VSG — not confirmed misconfiguration.

Firmware Compatibility

Shows what firmware your fleet can run — before you commit to an upgrade or a purchase. A summary page answers the question at a glance; a full evaluator sits behind it for what-if analysis.

• Supported Firmware Window — the floor → ceiling range every AP in the fleet supports, naming the models that set each end. If no single version fits every AP, the card says so and names the blockers.
• At a Glance — one row per Instant version the capability matrix knows about, with your current version tagged, supported / blocked counts per version, and what it would take to move (replace capped models, or a minimum-version requirement). Older versions are collapsed behind a toggle.
• Evaluator — tap a version to evaluate it in full: a Good / Bad / Excluded scorecard, per-AP rows grouped by why they fail (minimum version not met vs maximum exceeded), suggested replacement models for capped APs, and per-AP include / exclude checkboxes for modelling a removal or replacement.
• Consider a model — check an AP model against this cluster before buying it. The considered model is evaluated alongside your fleet for this session only and is never counted as one of your APs.
• Source data — the toolbar button shows the raw capability-matrix JSON the screen derives everything from.

The capability database and the AP replacement rules are bundled with the app and refreshed automatically in the background when a newer version is published. Both can be inspected under Settings → Reference Data.

Event Log

A per-site record of what happened during your connection sessions — built for diagnosing intermittent problems after the fact. Open it from the site editor (next to Test API) or from Settings → Session & API → View Event Log. It keeps the current run plus the last few runs for the site.

What it captures

• Connection events — connecting, connected, and any fall-back to the secondary VC IP (with the reason the primary failed).
• API failures — each failed controller call with the operation, the error, the load stage, and the run-up to it.
• Logout reasons — why a session ended: you disconnected, the inactivity timeout, the VC ended the session, or the app went to the background.
• App background/foreground — so a session that ended because the device was set down is explained, not mysterious.
• Load complete — a per-load summary: total API calls, per-stage timing and call counts, and any taps you made while it was loading.

What you can do

• Pick a run from the picker (this run, last run, or an earlier one) and expand any entry for detail.
• Copy log puts the run's transcript on the clipboard; Email log to support opens a pre-filled message; Open support site opens this site.

Exports

Reports and CSV / script exports. Reached from the sidebar (iPad) → Tools → Exports, or from iPhone Settings → Tools → Exports.

Format picker

Choose Plain Text or PDF at the top. PDF renders in 8-point monospaced on A4 via the iOS share sheet.

Available exports

• Client List
• Access Points
• Channel Quality
• Performance
• RF Neighbors
• Deny List
• VSG Check
• Firmware Compatibility
• Running Config
• Offline AP Cleanup Script — .txt of CLI remove commands for every offline AP
• Denylist Cleanup Script — .txt of CLI remove commands for every denied client
• Export AP list for GreenLake (CSV) — serial, MAC, AP name, tag URL — formatted for HPE GreenLake import

Rows whose source data hasn't been loaded yet are dimmed with a "Visit the X tab to load data first" caption. Tap a row to render the report and open the iOS share sheet.

Search

Search lives inside the trees rather than as a separate screen. In Clients & APs, type into the search field (iPad, or iPhone in landscape — portrait shows a rotate-to-search hint) to match against client name, wired hostname, IP, MAC, and manufacturer; the tree narrows to the matches. Tap a result to open its detail. RF Neighbors has its own search field for SSIDs, BSSIDs, and manufacturers.

Settings

Reached from the sidebar (iPad) → App → Settings, or from the iPhone tab bar. On iPhone a Tools group sits at the top (see Tools). The sections below follow top to bottom. Every preference is saved per site.

Appearance

• Colour Palette — pick from the four bundled schemes (Default, Colour Blind Safe, High Contrast, Monochrome). Three preview swatches show the Good / OK / Poor colours each palette uses.
• Trees Start Collapsed — when on, the tree views open collapsed instead of fully expanded.

Data Loading

• Load Spectrum Data — on by default. When on, an additional set of per-AP API calls runs as a loading stage to retrieve channel quality, SNIR, non-WiFi breakdown, active interferers, and recent alerts. On a 12-AP cluster this adds roughly 3–5 seconds to load time. Disable to shave that time.
• Load UCC Data — off by default. Runs a final, quick set of calls to populate the Voice & Video view (Wi-Fi calls, meeting apps). Shows as the green stage on the load bar.
• Load BLE Data — off by default. Runs a per-AP Bluetooth discovery pass to populate BLE Discovery. Shows as the blue stage on the load bar.

Each optional-load toggle carries a small colour dot matching its segment on the load bar, so you can tell at a glance which stage a colour represents.

Filters & Thresholds

• RF RSSI Cutoff — hides signals weaker than this value from RF Neighbors. Aruba positive scale; higher = weaker. Range 70–110 dBm, default 75.
• BLE RSSI Cutoff — the same idea for BLE Discovery: hides Bluetooth devices heard weaker than this value (range 70–110).
• Airtime Warning Threshold — flags clients whose retry rate exceeds this value (range 10–200%).
• Channel View — Strongest / Weakest RSSI — two sliders controlling the foreign-SSID ghost-bar scale on the spectrum chart. Neighbours stronger than the top clamp to the top of the scale; neighbours weaker than the bottom fade to invisible.

Client History

• Client History — how long to keep records of clients that have left the network. 10 / 30 / 90 / 180 days / 1 year. Tightening shows a confirmation with the number of entries that would be removed.
• Clear Offline Client History — removes every offline client currently stored for this site.

Site Setup

• AP Placement — place your APs on the map once for RF Location (see RF Location & AP Placement).
• Device Icon Rules — the hostname-keyword → icon rule editor (below).
• BLE Discovery — the cluster-wide Bluetooth browser (see BLE Discovery).

Device Icons

Tap Device Icon Rules to open the rule editor. Each rule maps a hostname keyword to an SF Symbol; the first match wins. Rules sort alphabetically. In the editor:

• Tap a row to edit it.
• Tap + to add a new rule.
• Tap Edit to drag-reorder, or swipe a row left to delete.
• Tap Reset and confirm to restore the built-in defaults.
• The icon picker is a paged grid; the current selection is highlighted.

Session & API

• Keep session on switch — how long IAPViewer keeps your session alive when you briefly leave the app (switch apps, glance at a notification) before logging out for security. 10 sec / 30 sec / 1 min / 2 min / 5 min, default 30 sec. The app's own 14-minute inactivity logout — kept just inside the VC's 15-minute session timeout — still applies.
• API Call Gap — minimum delay between consecutive API calls, 0–150 ms in 50 ms steps. Saved per site. Default 0 ms — most clusters run cleanly there. 50 ms is automatically applied for Aruba Central-managed clusters. Increase if you're seeing errors in the Event Log.
• Verbose Logging — when on, records extra detail in the Event Log: every API call (not just failures), per-radio band details, the raw LLDP data from each AP's switch, and a per-AP health snapshot (firmware version, uptime, last reboot cause, Aruba Central / Activate status). Use it when chasing an intermittent problem or when support asks for diagnostics; noisy, so off by default. Warnings are always logged, verbose or not.
• View Event Log — opens the per-site Event Log (above), showing the live error count for this session. When errors are present, a "Why am I seeing errors?" link appears with guidance.

Reference Data

The last Settings section shows the downloadable datasets the app relies on — inspectable in shipping builds, so you can always check whether your copy is current. Each card shows what's bundled with the app, what's been downloaded, and when.

• AP Reference Data — the AP capability matrix (per-model Instant firmware floors and ceilings) and the AP replacement rules, which together drive the Firmware Compatibility screen. Includes a check-for-updates button, coverage of your current fleet, and a browsable list of every model in the matrix.
• Vendor Databases — how the app knows who made a device: the three IEEE MAC registries (MA-L, MA-M, MA-S) behind Wi-Fi manufacturer names, and the Bluetooth SIG company-ID list used by BLE Discovery. Includes a live MAC Vendor Lookup and a searchable company-ID list. Refreshed automatically about once a week; manual checks are logged.

Quick reference

Where each tool lives

If something goes wrong

Most operational issues — load stalls, API errors, intermittent failures on Central-managed clusters, the fallback IP rebind scenario — are covered in detail on the Support page under Common Issues. The short version:

• Run Test API from the site editor first. It tells you exactly where the problem is: network, REST, auth, or firmware.
• Check Settings → Session & API → View Event Log — if it shows API errors, increase the API Call Gap in 50 ms steps until the load is clean. The log also records logout reasons and fallback use, and can be emailed to support.
• If the VC IP stops responding entirely after a cluster reboot, you've probably hit the Aruba floating-IP rebind failure. Configure a fallback VC IP on the site, or temporarily switch the site address to any individual AP's DHCP IP.

Contact

We are a small team. Support is provided on a best-effort basis with no guaranteed response time.

Email: support@bdlfoundry.dev
Support site: https://iapviewer.bdlfoundry.dev
Typical response: 1–2 weeks for non-critical issues

IAPViewer is developed independently and is not affiliated with, endorsed by, or sponsored by HPE, Aruba Networks, or any of their subsidiaries.
Aruba and Aruba Networks are registered trademarks of Hewlett Packard Enterprise.
Apple, App Store, iPhone, iPad, and TestFlight are trademarks of Apple Inc.
IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc.