Diagnose Sophos Firewall Wireless Controller from CLI

Run system wireless-controller commands in 4. Device Console on SFOS 22. Read troubleshooting logs separately in 5. Device Management > 3. Advanced Shell. Start with read-only checks, and only enable Remote Packet Capture after narrowing the issue down to one access point and one test client.

⚠️ Privacy and operations: A wireless capture can contain user traffic, IP addresses, DNS queries, authentication data, and session data. Use a narrow filter, capture one short reproducible test, and protect the exported file. Record the exact initial value before every change.

The commands apply to SFOS 22. Confirm the syntax and output for the installed build before use.

Open the correct console

The CLI is accessible locally with a console cable, remotely through SSH, or through admin > Console in WebAdmin. For SSH, allow SSH for the required zone under Administration > Device access > Local service ACL. admin > Console requires HTTPS access for the zone. Where possible, use a Local service ACL exception rule to limit management access to administration hosts.

After signing in, select 4. Device Console. There, ? shows the supported arguments and their descriptions for a partly entered command. system wireless-controller is a Device Console command. Advanced Shell is a separate execution context used below only for documented, read-only log inspection; it isn’t interchangeable with Device Console.

Record the baseline and symptom

First check which branches are available on the installed build and read the current values:

system wireless-controller ?
system wireless-controller ap_localdebuglevel get
system wireless-controller global show
system wireless-controller remote_pktcap show <AP_serial_number>

Replace <AP_serial_number> with the affected AP’s serial number; don’t enter the angle brackets. Also record the SFOS build, AP model and firmware, SSID, band, channel, channel width, test client’s MAC and IP address, time, and an exactly reproducible symptom. In an HA pair, record which node the session is on. Don’t repeat the diagnostics indiscriminately on both nodes after a failover.

A normal controller status only confirms the control state. It doesn’t prove client association, DHCP, DNS, authentication, or the data path.

Check WebAdmin and the relevant logs first

Under Wireless > Access points, verify that the AP is active and that its model and serial number match. Sophos Firewall manages access points over port 2712. If an AP is missing or inactive, first check the zone, VLAN, switch port, addressing, and path to this port. Accepting an unknown AP isn’t a diagnostic step: confirm its model, serial number, location, and management network before clicking Accept.

The SFOS 22 help maps these log files to wireless issues:

• awed.log: communication between AP or APX and the firewall
• wc_remote.log: wireless client communication with AP or APX
• hostapd.log: SSID events for LocalWifi
• hotspotd.log: hotspot events

SFOS 22 officially documents tail -f, grep, and less for reading troubleshooting logs in 5. Device Management > 3. Advanced Shell. The generic documented syntax supports these narrowly scoped examples:

tail -f /log/awed.log
grep '<AP_serial_number>' /log/awed.log
grep '<client_MAC_address>' /log/wc_remote.log
less /log/hostapd.log

Replace each placeholder with one exact identifier and omit the angle brackets. Observe tail -f only during the short reproduction, then stop it with Ctrl+C; leave less with q. These commands read one relevant file and don’t replace the Device Console commands above. Service start, stop, restart, and debug actions change system state: don’t use them as general diagnostics. They require a case-specific need, a recorded baseline, and an explicit rollback plan. If these checks aren’t sufficient, enable time-limited access under Diagnostics > Support access and send the access ID through the agreed support channel.

Run Remote Packet Capture on one AP

remote_pktcap feeds AP packets into a packet capture running at the same time on the firewall. Sophos requires a global ap_debuglevel of at least 4. The debug level is global, whereas the capture command targets a specific AP serial number.

Precondition before step 1: Check and record this AP’s capture state with system wireless-controller remote_pktcap show <AP_serial_number> and the existing firewall capture state under Diagnostics > Packet capture. If either capture is already active or its state is unclear, do not change the filter, capture state, or global debug level. Establish its owner and purpose and suspend this procedure until an explicitly approved baseline with both captures inactive is available. Never take over or stop someone else’s diagnostics.

1. Run system wireless-controller global show and record the exact ap_debuglevel. If it is already 4 or higher, don’t change it.

2. If it is below 4, temporarily set it to 4 and read the state again:

   system wireless-controller global ap_debuglevel 4
   system wireless-controller global show
   

3. Open Diagnostics > Packet capture, configure a narrow filter for the test client, destination, port, or protocol, and start Packet capture.

4. Enable AP capture and check its status:

   system wireless-controller remote_pktcap enable <AP_serial_number>
   system wireless-controller remote_pktcap show <AP_serial_number>
   

5. Generate only the documented test flow. Packet capture shows details including the incoming and outgoing interface, status, reason, and firewall rule ID. These fields help determine whether the frame reaches the AP, the firewall processes it, or a policy drops it.

6. Stop only captures started by this procedure from the confirmed inactive baseline: first your AP capture using the commands below, then your Packet capture in WebAdmin. Leave captures you did not start and other operators’ captures unchanged:

   system wireless-controller remote_pktcap disable <AP_serial_number>
   system wireless-controller remote_pktcap show <AP_serial_number>
   

7. If ap_debuglevel was changed, restore the value recorded before the test and verify it:

   system wireless-controller global ap_debuglevel <saved_ap_debuglevel>
   system wireless-controller global show
   

Replace <saved_ap_debuglevel> with the exact previous value. The documented Wireless Controller syntax has no reset branch for this parameter, so an assumed default isn’t a safe rollback.

Don’t use other parameters as a blanket fix

Device Console lists additional global parameters. Their numeric ranges are documented, but the operational effect isn’t explained sufficiently in every case:

• ap_localdebuglevel: 0 to 15; read with get, change with set
• log_level: 0 to 7; messages at or above the configured level are written, so a higher number doesn’t simply mean “more logging”
• ap_autoaccept, stay_online, and store_bss_stats: 0 off, 1 on
• tunnel_id_offset: 0 to 65535

Don’t change these values pre-emptively or run a block containing several changes. In particular, ap_autoaccept removes the deliberate AP acceptance checkpoint. The command page doesn’t give enough context to make general troubleshooting recommendations for stay_online, store_bss_stats, or tunnel_id_offset. Use them only with case-specific instructions from Sophos Support, save the previous value with global show, and restore that exact value afterward.

Delay RADIUS Accounting Start only for a proven cause

radius_accounting_start_delay is intended only for a confirmed ordering problem: 802.1X Accounting Start arrives before DHCP assigns an address to the client. Wi-Fi SSO then can’t obtain a usable Framed-IP-Address from the Accounting Start message. The documented range is 0 to 60 seconds; Sophos uses 30 seconds in KBA-000006795.

The Sophos-documented workflow applies to SFOS-managed APX models on a WPA/WPA2 Enterprise SSID. The KBA does not establish this SSO path for AP6 or arbitrary third-party controllers.

Before changing the value, prove the sequence with RADIUS logs and a capture and save the current value with global show. The full workflow is in Check RADIUS SSO and Accounting. After the test, run system wireless-controller global radius_accounting_start_delay <saved_delay> with the exact previous value and verify it with global show.

Channel width is configuration, not diagnostics

Sophos documents channel widths of 20 and 40 MHz for 2.4 GHz and 20, 40, and 80 MHz for 5 GHz. The CLI page incorrectly says 2.5GHz in one place. Don’t copy this token blindly. The documented CLI branch also provides no separate read or reset command for channel width. It isn’t a safe copy-and-paste diagnostic step without a saved baseline and confirmed syntax.

Plan channel width through the normal Wireless Network setup in WebAdmin. Channel use, neighboring networks, signal, retransmissions, client capabilities, and site density determine whether a wider setting helps at all.

Interpret AP configuration and XML API responses

If automation changed the AP, also inspect the saved WirelessAccessPoint object. The SFOS 22 and 23 XML references have the same field descriptions; this does not prove hardware support on every build. ID is the mandatory string identifier of the AP, not Label, the SSID, or an arbitrary group name. Update Access Point also lists Label, Country, and Band as mandatory; Delete Access Point lists ID. Deletion is neither a diagnostic step nor removal of an SSID assignment and requires deliberately approved retirement.

Check the dependencies: Group selects the AP group and WirelessNetworks/Network the wireless assignments. For 2.4 GHz, the fields are Channel2.4GHz, DynChan, TimeBasedScan, ScanTime/Time, TXPower, and ChannelWidth; for 5 GHz, the corresponding fields are Channel5GHz, DynChan5GHz, TimeBasedScan5GHz, ScanTime5GHz/Time, TXPower5GHz, and ChannelWidth11a. Assign a schedule only with time-based scanning enabled, and enable that only with dynamic channel selection on the respective band. VLANTagging and its dependent APVLANID concern the management path; the documented range for APVLANID is 1–4094. Compare the group, SSIDs, management VLAN, interface, and switch path with the wireless setup. AP6 remains outside SFOS management.

Not a ready-to-send write request: The reference example uses RootAccessPoint for Role, but the field description lists point/portal. The example uses Enable for scan switches, whereas the descriptions allow only t; some band descriptions are also inconsistent. Do not normalize these yourself. Before a change, confirm the exact parent tags, values, and operation in API help on the installed build; if the mapping remains unclear, do not write and consult Support.

These mappings are XML API statuses and unresolved reference symbols, not HTTP codes or verified runtime message text. Each listed code belongs to the named operation and symbol:

• Update Access Point — 200, 216 — Message.WPAPkUpdateSuccessfully
• Update Access Point — 500, 541, 543, 545, 544 — Message.WPAPUpdateFail
• Update Access Point — 523 — Message.WPNetworkGroupMax
• Update Access Point — 524 — Message.WPAccessPointMax
• Update Access Point — 542 — Message.WPAccessPointMesh
• Update Access Point — 547 — Message.WPAPUpdateFailVLANGroup
• Update Access Point — 548 — Message.WPA3IsNotSupported
• Delete Access Point — 200 — Message.WPAccessPointDeleteSuccess
• Delete Access Point — 500 — Message.WPAccessPointDeleteFail

Do not infer a limit, root cause, or safe retry from a symbol alone. Before any repeat write, compare the response with the actual saved AP, group, wireless, and VLAN state, including for 216; then test client connectivity and the data path. The central XML API safety guide explains access protection, explicit operations, partial results, and rollback.

Evaluate the result and close the session cleanly

After diagnostics, verify AP status, client association, DHCP lease, DNS resolution, authentication, expected firewall rule ID, packet loss, latency, and the affected application. For RADIUS, also verify Accounting Start, Framed-IP-Address, and user mapping.

The workflow is complete only when its own temporary captures have ended: remote_pktcap show must confirm the inactive state for the AP capture started here, and WebAdmin must confirm it for the Packet capture started here. Leave unrelated diagnostics unchanged; if this procedure was suspended because a capture was already active, stopping that capture is not a completion requirement. global show must contain the saved debug and parameter values. If the cause remains unclear, retain the time, AP serial number, test client, capture, and relevant log filenames for Sophos Support instead of trying more global settings.

FAQ