Diagnostiquer le Wireless Controller du Sophos Firewall en CLI

Sous SFOS 22, exécuter system wireless-controller dans 4. Device Console. Consulter séparément les logs de dépannage dans 5. Device Management > 3. Advanced Shell. Commencer par des contrôles en lecture seule et n’activer Remote Packet Capture qu’après avoir isolé le problème sur un point d’accès et un client de test.

⚠️ Confidentialité et exploitation : Une capture Wi-Fi peut contenir trafic utilisateur, adresses IP, requêtes DNS et données d’authentification ou de session. Utiliser un filtre étroit, capturer un seul test court et reproductible, puis protéger le fichier exporté. Noter la valeur initiale exacte avant chaque changement.

Ce guide repose sur l’aide publique de SFOS 22. Confirmer la syntaxe et le résultat observé sur le build installé.

Ouvrir la bonne console

La CLI est accessible localement par câble console, à distance par SSH ou via admin > Console dans WebAdmin. Pour SSH, autoriser SSH pour la zone requise sous Administration > Device access > Local service ACL. admin > Console exige l’accès HTTPS pour cette zone. Si possible, limiter l’administration aux postes prévus avec une Local service ACL exception rule.

Après connexion, choisir 4. Device Console. Dans ce contexte, ? affiche les arguments disponibles et leur description pour une commande commencée. system wireless-controller est une commande de Device Console. Advanced Shell est un environnement distinct, utilisé ci-dessous uniquement pour la consultation documentée des logs en lecture seule; il n’est pas interchangeable avec Device Console.

Relever l’état initial et le symptôme

Vérifier d’abord les branches proposées par le build installé, puis lire les valeurs actuelles :

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

Remplacer <AP_serial_number> par le numéro de série de l’AP concerné, sans saisir les chevrons. Relever également le build SFOS, le modèle et le firmware AP, le SSID, la bande, le canal, sa largeur, les adresses MAC et IP du client de test, l’heure et un symptôme exactement reproductible. Dans un cluster HA, noter le nœud auquel la connexion a été établie. Après un failover, ne pas répéter aveuglément le diagnostic sur les deux nœuds.

Un état normal du contrôleur confirme uniquement le plan de contrôle. Il ne prouve ni l’association du client, ni DHCP, DNS, l’authentification ou le chemin de données.

Contrôler d’abord WebAdmin et les bons logs

Sous Wireless > Access points, vérifier que l’AP est actif et que son modèle et son numéro de série correspondent. Sophos Firewall gère les AP sur le port 2712. Si un AP est absent ou inactif, contrôler d’abord zone, VLAN, port de switch, adressage et chemin vers ce port. Accepter un AP inconnu n’est pas un test : confirmer modèle, numéro de série, emplacement et réseau de management avant Accept.

L’aide SFOS 22 associe les fichiers suivants aux incidents Wi-Fi :

• awed.log : communication entre AP ou APX et firewall
• wc_remote.log : communication d’un client Wi-Fi avec AP ou APX
• hostapd.log : événements SSID pour LocalWifi
• hotspotd.log : événements de hotspot

SFOS 22 documente officiellement tail -f, grep et less pour lire les logs de dépannage dans 5. Device Management > 3. Advanced Shell. La syntaxe générique documentée permet ces exemples volontairement ciblés :

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

Remplacer chaque paramètre fictif par un seul identifiant exact, sans saisir les chevrons. N’exécuter tail -f que pendant la courte reproduction, puis l’arrêter avec Ctrl+C; quitter less avec q. Ces commandes lisent chacune un fichier pertinent et ne remplacent pas les commandes Device Console ci-dessus. Les actions de service start, stop et restart, ainsi que les actions de debug, modifient l’état du système : ne pas les utiliser comme diagnostic général. Elles nécessitent un besoin propre au cas, un état initial consigné et un plan de rollback explicite. Si ces contrôles ne suffisent pas, activer un accès limité dans le temps sous Diagnostics > Support access et transmettre l’Access ID par le canal convenu.

Exécuter Remote Packet Capture sur un seul AP

remote_pktcap injecte les paquets de l’AP dans un Packet Capture exécuté simultanément sur le firewall. Sophos exige un ap_debuglevel global d’au moins 4. Le niveau de debug est global, tandis que la capture cible un numéro de série AP précis.

Prérequis avant l’étape 1 : Vérifiez et consignez l’état de capture de cet AP avec system wireless-controller remote_pktcap show <AP_serial_number> ainsi que l’état de capture existant du firewall sous Diagnostics > Packet capture. Si l’une des captures est déjà active ou si son état est incertain, ne modifiez ni le filtre, ni l’état de capture, ni le niveau global de debug. Identifiez son responsable et son objectif, puis suspendez cette procédure jusqu’à disposer d’un état initial explicitement approuvé où les deux captures sont inactives. Ne reprenez ni n’arrêtez un diagnostic appartenant à un autre intervenant.

1. Exécuter system wireless-controller global show et noter exactement ap_debuglevel. S’il vaut déjà 4 ou davantage, ne pas le modifier.

2. S’il est inférieur à 4, le passer temporairement à 4, puis relire l’état :

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

3. Ouvrir Diagnostics > Packet capture, définir un filtre étroit sur le client, la destination, le port ou le protocole, puis lancer Packet capture.

4. Activer la capture AP et contrôler son état :

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

5. Générer uniquement le flux de test documenté. Packet capture affiche notamment interfaces entrante et sortante, Status, Reason et Firewall Rule ID. Ces champs indiquent si la trame atteint l’AP, est traitée par le firewall ou rejetée par une règle.

6. Arrêtez uniquement les captures lancées par cette procédure depuis l’état initial inactif confirmé : d’abord votre capture AP avec les commandes ci-dessous, puis votre Packet capture dans WebAdmin. Laissez inchangées les captures que vous n’avez pas lancées et celles des autres intervenants :

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

7. Si l’on a modifié ap_debuglevel, restaurer et vérifier la valeur relevée avant le test :

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

Remplacer <saved_ap_debuglevel> par l’ancienne valeur exacte. La syntaxe documentée de Wireless Controller ne propose pas de branche reset pour ce paramètre : une valeur par défaut supposée n’est donc pas un rollback sûr.

Ne pas employer les autres paramètres comme remède global

Device Console liste d’autres paramètres globaux. Leurs plages sont documentées, mais leur effet opérationnel n’est pas toujours suffisamment expliqué :

• ap_localdebuglevel : 0 à 15, lecture avec get, modification avec set
• log_level : 0 à 7; les messages au niveau configuré ou supérieur sont écrits, donc une valeur plus haute ne signifie pas simplement « davantage de logs »
• ap_autoaccept, stay_online et store_bss_stats : 0 désactivé, 1 activé
• tunnel_id_offset : 0 à 65535

Ne pas modifier ces valeurs préventivement et ne pas exécuter un bloc de changements. ap_autoaccept, notamment, supprime le contrôle volontaire lors de l’admission d’un AP. La page ne donne pas assez de contexte pour recommander généralement stay_online, store_bss_stats ou tunnel_id_offset. Les utiliser seulement sur instruction spécifique de Sophos Support, sauvegarder la valeur avec global show et restaurer ensuite cette valeur exacte.

Retarder RADIUS Accounting Start uniquement si la cause est prouvée

radius_accounting_start_delay ne répond qu’à un problème d’ordre confirmé : 802.1X Accounting Start arrive avant l’attribution DHCP. Wi-Fi SSO ne peut alors reprendre aucune Framed-IP-Address exploitable du message. La plage documentée est de 0 à 60 secondes; Sophos utilise 30 secondes dans KBA-000006795.

La procédure documentée par Sophos s’applique aux modèles APX gérés par SFOS avec un SSID WPA/WPA2 Enterprise. La KBA ne confirme pas ce chemin SSO pour AP6 ni pour des contrôleurs tiers quelconques.

Avant toute modification, prouver la séquence par les logs RADIUS et une capture, puis sauvegarder la valeur avec global show. La procédure complète figure dans Contrôler RADIUS SSO et Accounting. Après le test, exécuter system wireless-controller global radius_accounting_start_delay <saved_delay> avec l’ancienne valeur exacte, puis la vérifier avec global show.

La largeur de canal est une configuration, pas un diagnostic

Sophos documente 20 et 40 MHz pour 2,4 GHz, puis 20, 40 et 80 MHz pour 5 GHz. La page CLI écrit par erreur 2.5GHz à un endroit. Ne pas copier ce token aveuglément. La branche CLI documentée ne fournit pas non plus de commande de lecture ou de reset distincte. Sans état initial sauvegardé et syntaxe confirmée, ce n’est pas une étape de diagnostic à copier-coller.

Planifier la largeur de canal dans la configuration Wireless Network normale de WebAdmin. Occupation des canaux, réseaux voisins, signal, retransmissions, capacités client et densité du site déterminent si une largeur supérieure est utile.

Interpréter la configuration AP et les réponses XML API

Si une automatisation a modifié l’AP, inspectez aussi l’objet enregistré WirelessAccessPoint. Les références XML SFOS 22 et 23 donnent les mêmes descriptions de champs ; cela ne prouve pas la compatibilité matérielle sur chaque build. ID est l’identifiant obligatoire de type string de l’AP, et non Label, le SSID ou un nom de groupe arbitraire. Update Access Point indique également Label, Country et Band comme obligatoires ; Delete Access Point indique ID. Une suppression n’est ni un diagnostic ni le retrait d’une affectation SSID : elle exige une mise hors service expressément approuvée.

Vérifiez les dépendances : Group sélectionne le groupe AP et WirelessNetworks/Network les affectations WLAN. Pour 2,4 GHz, les champs sont Channel2.4GHz, DynChan, TimeBasedScan, ScanTime/Time, TXPower et ChannelWidth ; pour 5 GHz, les champs correspondants sont Channel5GHz, DynChan5GHz, TimeBasedScan5GHz, ScanTime5GHz/Time, TXPower5GHz et ChannelWidth11a. Affectez un horaire uniquement si le scan temporel est activé, et activez celui-ci uniquement avec la sélection dynamique du canal sur la bande concernée. VLANTagging et son dépendant APVLANID concernent le chemin de management ; la plage documentée d’APVLANID est 1–4094. Comparez groupe, SSID, VLAN de management, interface et chemin du switch avec la configuration Wi-Fi. AP6 reste hors de la gestion SFOS.

Ce n’est pas une requête d’écriture prête à envoyer : L’exemple utilise RootAccessPoint pour Role, alors que la description indique point/portal. Les options de scan affichent Enable dans l’exemple, mais seulement t dans la description ; certaines descriptions de bandes sont également incohérentes. Ne normalisez pas ces valeurs vous-même. Avant toute modification, confirmez les balises parentes, les valeurs et l’opération exactes dans API help du build installé ; si la correspondance reste incertaine, n’écrivez pas et consultez Support.

Ces correspondances sont des statuts XML API et des symboles de référence non résolus, pas des codes HTTP ni des textes de messages d’exécution vérifiés. Chaque code indiqué appartient à l’opération et au symbole nommés :

• 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

Ne déduisez ni limite, ni cause, ni nouvelle tentative sûre d’un symbole seul. Avant de répéter une écriture, comparez la réponse avec l’état réellement enregistré de l’AP, du groupe, des WLAN et du VLAN, y compris pour 216 ; testez ensuite la connexion client et le chemin de données. Le guide central de sécurité XML API explique la protection d’accès, les opérations explicites, les résultats partiels et le rollback.

Évaluer le résultat et terminer proprement

Après le diagnostic, vérifier état AP, association du client, bail DHCP, résolution DNS, authentification, Firewall Rule ID attendue, pertes, latence et application concernée. Pour RADIUS, contrôler aussi Accounting Start, Framed-IP-Address et l’affectation utilisateur.

La procédure est terminée lorsque ses propres captures temporaires sont arrêtées : remote_pktcap show doit confirmer l’état inactif de la capture AP lancée ici, et WebAdmin celui de Packet capture lancé ici. Les autres diagnostics restent inchangés ; si la procédure a été suspendue à cause d’une capture déjà active, l’arrêt de celle-ci n’est pas une condition de clôture. global show doit contenir les valeurs de debug et des paramètres sauvegardées. Si la cause reste inconnue, conserver heure, numéro de série AP, client, capture et noms de logs pour Sophos Support au lieu d’essayer d’autres paramètres globaux.

FAQ