Sophos Firewall Wireless Controller per CLI diagnostizieren

system wireless-controller wird in SFOS 22 unter 4. Device Console ausgeführt. Troubleshooting-Logs liest man separat unter 5. Device Management > 3. Advanced Shell. Mit lesenden Prüfungen beginnen und Remote Packet Capture erst aktivieren, wenn das Fehlerbild auf einen bestimmten Access Point und einen Testclient eingegrenzt ist.

⚠️ Datenschutz und Betrieb: Ein Wireless Capture kann Nutztraffic, IP-Adressen, DNS-Anfragen sowie Authentifizierungs- und Sitzungsdaten enthalten. Einen engen Filter verwenden, nur einen kurzen reproduzierbaren Test erfassen und die exportierte Datei schützen. Vor jeder Änderung den exakten Ausgangswert notieren.

Die Befehle gelten für SFOS 22. Syntax und Ausgabe vor der Verwendung mit dem installierten Build abgleichen.

In die richtige Konsole wechseln

Die CLI ist lokal über ein Konsolenkabel, per SSH oder über admin > Console im WebAdmin erreichbar. Für SSH muss unter Administration > Device access > Local service ACL der Dienst SSH für die benötigte Zone freigegeben sein. Für admin > Console benötigt die Zone HTTPS-Zugriff. Den Verwaltungszugriff möglichst mit einer Local service ACL exception rule auf Administrationshosts beschränken.

Nach der Anmeldung wählt man 4. Device Console. Dort zeigt ? die Argumente eines angefangenen Befehls mit Beschreibung. system wireless-controller ist ein Device-Console-Befehl. Die Advanced Shell ist ein separater Ausführungsort, der unten nur für dokumentierte, lesende Logabfragen verwendet wird; sie ist nicht mit der Device Console austauschbar.

Ausgangszustand und Fehlerbild erfassen

Zuerst prüfen, welche Zweige der installierte Build anbietet, und die vorhandenen Werte auslesen:

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

<AP_serial_number> durch die Seriennummer des betroffenen AP ersetzen; die spitzen Klammern werden nicht eingegeben. Zusätzlich SFOS-Build, AP-Modell und -Firmware, SSID, Band, Kanal, Kanalbreite, MAC- und IP-Adresse des Testclients, Uhrzeit und ein exakt reproduzierbares Symptom notieren. In einem HA-Verbund hält man auch fest, an welchem Node die Anmeldung erfolgt ist. Die Diagnose nach einem Failover nicht ungeprüft auf beiden Nodes wiederholen.

Ein unauffälliger Controllerstatus belegt nur den Steuerungszustand. Er beweist weder eine erfolgreiche Client-Assoziation noch DHCP, DNS, Authentifizierung oder den Datenpfad.

Erst WebAdmin und die passenden Logs prüfen

Unter Wireless > Access points kontrollieren, ob der AP als aktiv erscheint und ob Modell sowie Seriennummer stimmen. Sophos Firewall verwaltet Access Points über Port 2712. Fehlt ein AP oder bleibt er inaktiv, zuerst Zone, VLAN, Switchport, Adressierung und den Pfad zu diesem Port prüfen. Die Annahme eines unbekannten AP ist keine Diagnosemassnahme: Modell, Seriennummer, Standort und Managementnetz müssen vor Accept stimmen.

Die SFOS-22-Hilfe ordnet Wireless-Fehlern diese Logdateien zu:

• awed.log: Kommunikation zwischen AP beziehungsweise APX und der Firewall
• wc_remote.log: Kommunikation eines Wireless-Clients mit AP beziehungsweise APX
• hostapd.log: SSID-Ereignisse für LocalWifi
• hotspotd.log: Hotspot-Ereignisse

SFOS 22 dokumentiert tail -f, grep und less offiziell zum Lesen von Troubleshooting-Logs unter 5. Device Management > 3. Advanced Shell. Die allgemeine dokumentierte Syntax unterstützt diese gezielt begrenzten Beispiele:

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

Jeden Platzhalter durch genau eine Kennung ersetzen und die spitzen Klammern weglassen. tail -f nur während des kurzen Reproduktionstests beobachten und mit Ctrl+C beenden; less verlässt man mit q. Diese Befehle lesen jeweils eine relevante Datei und ersetzen nicht die Device-Console-Befehle oben. Serviceaktionen wie start, stop und restart sowie Debugaktionen verändern den Systemzustand. Sie werden nicht als allgemeine Diagnose eingesetzt, sondern nur bei fallspezifischem Bedarf, mit dokumentiertem Ausgangswert und eindeutigem Rollback-Plan. Genügen diese Prüfungen nicht, unter Diagnostics > Support access einen zeitlich begrenzten Zugang aktivieren und die Access ID über den vereinbarten Supportkanal übermitteln.

Remote Packet Capture auf genau einem AP

remote_pktcap leitet AP-Pakete in ein gleichzeitig laufendes Packet Capture der Firewall ein. Sophos verlangt dafür einen globalen ap_debuglevel von mindestens 4. Der Debuglevel ist global, der Capture-Aufruf verwendet dagegen eine konkrete AP-Seriennummer.

Voraussetzung vor Schritt 1: Mit system wireless-controller remote_pktcap show <AP_serial_number> den Erfassungszustand dieses AP und unter Diagnostics > Packet capture den bestehenden Firewall-Capture-Zustand prüfen und dokumentieren. Ist eine der beiden Erfassungen bereits aktiv oder ihr Zustand unklar, weder Filter noch Erfassungszustand noch globalen Debuglevel ändern. Verantwortliche und Zweck klären und diesen Ablauf aussetzen, bis ein ausdrücklich freigegebener, auf beiden Seiten inaktiver Ausgangszustand vorliegt. Eine fremde Diagnose darf nicht übernommen oder beendet werden.

1. system wireless-controller global show auslesen und den exakten Wert von ap_debuglevel notieren. Liegt er bereits bei 4 oder höher, bleibt er unverändert.

2. Liegt er unter 4, temporär auf 4 setzen und den Zustand erneut auslesen:

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

3. Diagnostics > Packet capture öffnen, einen engen Filter für den Testclient, das Ziel, den Port oder das Protokoll setzen und Packet Capture starten.

4. Die AP-Erfassung aktivieren und den Status kontrollieren:

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

5. Genau den dokumentierten Testflow erzeugen. Packet Capture zeigt unter anderem ein- und ausgehende Schnittstelle, Status, Reason sowie Firewall Rule ID. Diese Angaben helfen zu unterscheiden, ob der Frame den AP erreicht, die Firewall ihn verarbeitet oder eine Policy ihn verwirft.

6. Nur die von diesem Ablauf aus dem bestätigten inaktiven Ausgangszustand gestarteten Erfassungen beenden: zuerst die eigene AP-Erfassung mit den folgenden Befehlen, danach das eigene Packet Capture im WebAdmin. Nicht gestartete oder fremde Erfassungen unverändert lassen:

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

7. Falls ap_debuglevel geändert wurde, den zuvor notierten Wert wiederherstellen und prüfen:

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

<saved_ap_debuglevel> durch den exakten Vorwert ersetzen. Die dokumentierte Wireless-Controller-Syntax bietet für diesen Parameter keinen reset-Zweig; ein vermuteter Default ist deshalb kein sicherer Rollback.

Andere Parameter nicht als Sammelfix verwenden

Die Device Console führt weitere globale Parameter auf. Ihre Zahlenbereiche sind dokumentiert, ihre betriebliche Wirkung aber nicht in jedem Fall ausreichend erklärt:

• ap_localdebuglevel: 0 bis 15; aktueller Wert mit get, Änderung mit set
• log_level: 0 bis 7; Meldungen ab dem konfigurierten Level werden geschrieben. Eine höhere Zahl bedeutet daher nicht pauschal „mehr Logging“.
• ap_autoaccept, stay_online und store_bss_stats: 0 aus, 1 ein
• tunnel_id_offset: 0 bis 65535

Diese Werte nicht vorsorglich ändern und keinen Block mit mehreren Änderungen ausführen. Insbesondere entfernt ap_autoaccept den bewussten Kontrollpunkt bei der AP-Annahme. Für stay_online, store_bss_stats und tunnel_id_offset nennt die Befehlsseite nicht genug Kontext für eine allgemeine Troubleshooting-Empfehlung. Diese Parameter nur mit einer fallspezifischen Sophos-Support-Anweisung verwenden, den Vorwert mit global show sichern und danach genau diesen Wert wiederherstellen.

RADIUS Accounting Start gezielt verzögern

radius_accounting_start_delay ist nur für ein belegtes Reihenfolgeproblem gedacht: Der 802.1X Accounting Start trifft ein, bevor DHCP dem Client eine Adresse zugeteilt hat. Wi-Fi SSO kann dann keine brauchbare Framed-IP-Address aus der Accounting-Start-Nachricht übernehmen. Der dokumentierte Bereich beträgt 0 bis 60 Sekunden; Sophos zeigt in KBA-000006795 ein Beispiel mit 30 Sekunden.

Der von Sophos dokumentierte Ablauf gilt für SFOS-verwaltete APX-Modelle mit einer WPA/WPA2-Enterprise-SSID. Für AP6 oder beliebige Drittanbieter-Controller belegt die KBA diesen SSO-Pfad nicht.

Vor einer Änderung die Reihenfolge mit RADIUS-Logs und einem Capture belegen und den aktuellen Wert mit global show sichern. Der vollständige Ablauf steht unter RADIUS SSO und Accounting prüfen. Nach dem Test mit system wireless-controller global radius_accounting_start_delay <saved_delay> den exakten Vorwert setzen und erneut mit global show kontrollieren.

Kanalbreite ist Konfiguration, nicht Diagnose

Sophos dokumentiert für 2,4 GHz Kanalbreiten von 20 und 40 MHz sowie für 5 GHz 20, 40 und 80 MHz. Die CLI-Seite schreibt an einer Stelle irrtümlich 2.5GHz. Diesen Token nicht blind kopieren. Der dokumentierte CLI-Zweig zeigt zudem keinen separaten Lese- oder Reset-Befehl für die Kanalbreite. Deshalb eignet er sich ohne gesicherten Ausgangswert und bestätigte Syntax nicht als Copy-and-paste-Diagnoseschritt.

Die Kanalbreite im normalen Wireless-Network-Setup im WebAdmin planen. Kanalbelegung, Nachbarnetze, Signal, Retransmits, Clientfähigkeiten und Standortdichte entscheiden, ob eine breitere Einstellung überhaupt hilft.

AP-Konfiguration und XML-API-Antworten einordnen

Wurde der AP automatisiert geändert, zusätzlich das gespeicherte Objekt WirelessAccessPoint prüfen. Die XML-Referenzen für SFOS 22 und 23 zeigen dieselbe Feldbeschreibung; das ist kein Nachweis der Hardware-Unterstützung auf jedem Build. ID ist die verpflichtende String-Kennung des AP, nicht Label, SSID oder eine frei gewählte Gruppenbezeichnung. Update Access Point nennt zusätzlich Label, Country und Band als Pflichtfelder; Delete Access Point nennt ID. Eine Löschung ist keine Diagnose oder Aufhebung einer SSID-Zuweisung und benötigt eine bewusst freigegebene Stilllegung.

Die Abhängigkeiten gehören zur Prüfung: Group wählt die AP-Gruppe, WirelessNetworks/Network die WLAN-Zuweisungen. Für 2,4 GHz stehen Channel2.4GHz, DynChan, TimeBasedScan, ScanTime/Time, TXPower und ChannelWidth; für 5 GHz die entsprechenden Channel5GHz, DynChan5GHz, TimeBasedScan5GHz, ScanTime5GHz/Time, TXPower5GHz und ChannelWidth11a. Den Zeitplan nur mit aktivierter zeitbasierter Suche und diese nur mit dynamischer Kanalwahl im jeweiligen Band zuordnen. VLANTagging und das davon abhängige APVLANID betreffen den Managementpfad; APVLANID hat den dokumentierten Bereich 1–4094. Gruppe, SSIDs, Management-VLAN, Interface und Switchpfad gemeinsam mit dem Wireless-Setup abgleichen. AP6 bleibt ausserhalb der SFOS-Verwaltung.

Kein kopierfertiger Schreib-Request: Das Referenzbeispiel verwendet für Role den Wert RootAccessPoint, die Feldbeschreibung dagegen point/portal. Für die Scan-Schalter zeigt das Beispiel Enable, während die Beschreibung nur t zulässt; auch einzelne Bandbeschreibungen sind inkonsistent. Nicht eigenmächtig normalisieren. Vor einer Änderung die exakten Eltern-Tags, Werte und Operation in API help des installierten Builds bestätigen; bleibt die Zuordnung unklar, nicht schreiben und Support hinzuziehen.

Die folgenden Zuordnungen sind XML-API-Status und ungelöste Referenzsymbole, keine HTTP-Codes oder belegten Laufzeit-Meldungstexte. Jeder aufgeführte Code gehört zur genannten Operation und zum angegebenen 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

Aus einem Symbol allein keinen Grenzwert, Fehlergrund oder sicheren Retry ableiten. Vor jedem erneuten Schreibversuch Antwort und tatsächlich gespeicherten AP-, Gruppen-, WLAN- und VLAN-Zustand vergleichen, auch bei 216; danach Clientverbindung und Datenpfad prüfen. Zugriffsschutz, explizite Operation, Teilresultate und Rückbau erläutert die zentrale XML-API-Sicherheitsanleitung.

Ergebnis bewerten und sauber abschliessen

Nach der Diagnose AP-Status, Client-Assoziation, DHCP-Lease, DNS-Auflösung, Authentifizierung, erwartete Firewall Rule ID, Paketverlust, Latenz und die betroffene Anwendung prüfen. Bei RADIUS gehören Accounting Start, Framed-IP-Address und Benutzerzuordnung zur Abnahme.

Der Abschluss ist erst vollständig, wenn die eigenen temporären Erfassungen beendet sind: Für die in diesem Ablauf gestartete AP-Erfassung muss remote_pktcap show den inaktiven Zustand bestätigen, für das hier gestartete Packet Capture die Anzeige im WebAdmin. Andere Diagnosen bleiben unverändert; wurde der Ablauf wegen einer bereits aktiven Erfassung ausgesetzt, ist deren Beendigung keine Abschlussbedingung. global show muss die gesicherten Debug- und Parameterwerte zeigen. Bleibt die Ursache offen, Uhrzeit, AP-Seriennummer, Testclient, Capture und relevante Lognamen für Sophos Support sichern, statt weitere globale Werte auszuprobieren.

FAQ