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.

This guide is based on the public SFOS 22 help. The commands were not run on a Sophos Firewall for this article, so confirm the syntax and observed output on the installed build.

Open the correct console

You can access the CLI 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 you are signed in to. 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.

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 AP capture first, then stop Packet capture in WebAdmin:

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

7. If you changed ap_debuglevel, 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.

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.

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 remote_pktcap show reports no active capture for the AP, Packet capture is off in WebAdmin, and global show contains 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.

Official sources

• SFOS 22: Wireless-controller commands
• SFOS 22: Accessing Command Line Console
• SFOS 22: Device console
• SFOS 22: Packet capture
• SFOS 22: Log files for troubleshooting
• SFOS 22: View troubleshooting log lines
• SFOS 22: Access points
• Sophos KBA-000006795: SSO for APX Wi-Fi users with RADIUS

FAQ