NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. New stack: /interface wifi registration-table print — signal, tx/rx rate, uptime.
2. Legacy stack: /interface wireless registration-table print
3. GUI: WiFi → Registration or Wireless → Registration tab.
4. Live signal for one client: /interface wireless monitor wlan1 and the *Snooper* tool (/interface wireless snooper) for channel occupancy.

Gotchas & notes

• The registration table is a snapshot with no history — a client that disconnected is simply gone, so intermittent problems are hard to catch. Log the table on a scheduler if you need history.
• signal-strength is in dBm: better than −65 is good, worse than −75 is trouble. RouterOS also shows signal-to-noise, which is often the more useful number.
• Wireless → Snooper scans the band and shows other networks and channel utilisation — the best free site-survey tool on this list, though it takes the radio off-channel while running.
• With CAPsMAN, look at the CAPsMAN registration table on the controller rather than per-AP.

Steps

1. GUI: WiFi & Switch Controller → WiFi Clients — SSID, AP, signal strength, band, and rate.
2. Also Dashboard → WiFi widgets for per-AP client counts.
3. CLI: diagnose wireless-controller wlac -c sta (station list) and diagnose wireless-controller wlac -d sta for detail.
4. AP health: diagnose wireless-controller wlac -c wtp

Gotchas & notes

• Only shows clients on FortiAPs managed by this FortiGate; an AP in standalone mode does not report in.
• The diagnose wireless-controller wlac command family is the detailed view — signal, SNR, MCS rate, and channel — and is far richer than the GUI table.
• Rogue AP and interference data lives under WiFi & Switch Controller → WIDS/Rogue AP and needs the feature enabled first; it is off by default.
• Client history is tied to logging; without disk or FortiAnalyzer, you get the current snapshot only.

Steps

1. Clients → filter to wireless → each row shows AP, SSID, signal, experience score, and rate.
2. Click a client for its history: connection events, roaming between APs, signal over time.
3. Devices → <AP> → Clients for per-AP association lists, and the AP's RF Environment tab for channel utilisation.
4. Insights → WiFi Experience for site-wide problem clients.

Gotchas & notes

• UniFi's per-client history and roaming timeline is the best of the six for diagnosing intermittent wireless — it shows which AP a device moved between and when, which a snapshot table cannot.
• The *Experience* percentage is a Ubiquiti-computed composite, not a standard metric. Treat it as a triage hint and look at signal, retries, and TX rate for the real story.
• RF Environment per AP shows channel utilisation and neighbouring networks — check it before blaming clients for slow Wi-Fi.
• 'Forgetting' a client deletes its history along with its name and fixed IP, so avoid that during an investigation.
• History retention depends on controller storage; a Cloud Key with a full disk quietly loses it.

Steps

1. A switch/router has no wireless clients to show. On the switch you can see the AP's MAC and port: show mac address-table interface Gi1/0/10.
2. On a Catalyst 9800 WLC: show wireless client summary, and show wireless client mac-address <mac> detail for signal/SNR/rate.
3. On AireOS: show client summary / show client detail <mac>.
4. PoE check for the AP: show power inline Gi1/0/10

Gotchas & notes

• The wireless client list lives on the controller, not the switch. From the switch side the useful checks are the AP's PoE draw, the port's error counters, and whether the AP's VLAN is correct.
• show wireless client mac-address <mac> detail on a C9800 is very detailed (RSSI, SNR, MCS, capabilities, policy tag) and is the equivalent of the other vendors' client view.
• An AP that keeps rebooting is often a PoE budget problem — show power inline on the switch is the first check, not a wireless issue at all.

Steps

1. No wireless, so no client list.
2. You can see wireless users' traffic in Monitor → Traffic by their VLAN/zone, and identify them by username if User-ID is integrated with the wireless controller's RADIUS or syslog.
3. Use the wireless vendor's own tooling for signal and association data.

Gotchas & notes

• Setting up User-ID against the wireless controller is the valuable integration here: it turns IP-based logs into named users, which makes wireless troubleshooting via firewall logs far more useful.
• The firewall can tell you what a wireless client did on the network, never why its signal is poor.

Steps

1. Only if pfSense itself runs a wireless interface (uncommon): Status → Interfaces shows the wireless status, and Status → Wireless lists associated clients.
2. Otherwise use the AP vendor's interface.
3. Status → DHCP Leases and Diagnostics → ARP Table identify wireless devices by IP/MAC/hostname regardless of who runs the radio.

Gotchas & notes

• In any sane pfSense deployment the APs are separate, so the answer is 'look at the AP'. pfSense's job is DHCP, DNS, and the firewall rules for the wireless VLAN.
• Status → DHCP Leases is still useful for identifying which devices are on the wireless VLAN and whether they got addresses — the first check for 'connected but no internet'.
• The Status → Wireless page only exists when a wireless interface is assigned.

Steps

1. MANAGE → Connectivity → Wireless → Station Status lists every associated client across all managed APs: MAC address, SSID/VAP, associated AP, radio/band (2.4GHz vs 5GHz), channel, signal (RSSI in dBm), noise, and current rate.
2. Filter or search the Station Status table by AP or SSID if you have more than a couple of access points, since the list is flat and not grouped per-AP by default.
3. Cross-reference MANAGE → Connectivity → Wireless → Access Points for per-AP radio load (client count, channel utilization) if the issue looks like AP-side congestion rather than one client's signal.
4. For anything beyond a live snapshot — roaming history, past disconnects, long-term signal trend — you need the separate cloud-hosted SonicWall WiFi Cloud Manager / Wireless Network Manager subscription; the on-box GUI does not retain history.

Gotchas & notes

• Station Status is a live poll, not a log — closing and reopening the page just re-fetches current associations; there's no on-box timeline of when a client roamed between APs or dropped and reconnected, unlike a UniFi controller's per-client history.
• The SonicOS CLI has no wireless client visibility at all — you can't see stations over SSH; it's GUI (or SNMP polling) only.
• Signal is reported in raw dBm rather than a bars/percentage abstraction, so someone used to UniFi's signal-strength percentage or MikroTik's signal-to-noise display needs to re-calibrate what 'good' looks like (roughly -65dBm or better for a solid connection).
• With multiple SonicWave/SonicPoint APs sharing one SSID, a weak client can be sitting on a far AP because SonicOS's own band-steering/roaming assist didn't kick it to a closer one — check which AP the client is actually associated to before assuming it's a driver or client-side problem.

Steps

1. Insight portal: Location → Devices, select the Orbi Pro AP or Insight router, then open its Clients (or Connected Devices) tab.
2. Alternatively Location → Clients gives a flat list of every wireless (and wired) client across the whole site, filterable by AP/SSID.
3. Each client entry shows signal strength (RSSI in dBm), connected band (2.4/5/6GHz), negotiated link rate, connected SSID, and which specific AP it's on.
4. Click into an individual client for its detail view, which includes a timeline of roaming/association events — which AP it was on and when it switched, since Insight is a true cloud controller tracking this history.
5. Mobile app: Location → Clients, same core fields in a simplified list/detail view.
6. No CLI path exists — Insight-managed APs and routers have no CLI, so there is no SSH/console way to pull client tables for these radios.

Gotchas & notes

• Roaming history is genuinely one of Insight's stronger points versus a flat snapshot — because it's a real controller, you can see the client hop between APs, which is useful for diagnosing sticky-client problems that a single-AP view would hide.
• The client list is not truly real-time — it's polled over the cloud link, so there's a noticeable lag (often 30-60+ seconds) compared to a local controller like UniFi's.
• If internet/cloud connectivity to the Location drops, you lose visibility into clients entirely on most Orbi Pro/router models — there's no local no-cloud client page to fall back on.
• Signal is reported as raw RSSI (dBm), not a normalized SNR or percentage bar in most views — coming from platforms that show a simple signal-quality percentage, expect to interpret dBm yourself.
• This is purely an Insight (cloud/app) feature — it has nothing to do with the Smart Switch Lite CLI or the M4200/M4300 IOS-style CLI, since neither of those device families has a radio.