Diagnosticar Wireless Controller de Sophos Firewall por CLI

En SFOS 22, ejecutar system wireless-controller en 4. Device Console. Consultar los logs de diagnóstico por separado en 5. Device Management > 3. Advanced Shell. Empezar con comprobaciones de solo lectura y activar Remote Packet Capture únicamente después de aislar el fallo en un punto de acceso y un cliente de prueba.

⚠️ Privacidad y operación: Una captura Wi-Fi puede contener tráfico de usuarios, direcciones IP, consultas DNS y datos de autenticación o sesión. Utilizar un filtro estrecho, capturar una prueba breve y reproducible y proteger el archivo exportado. Anotar el valor inicial exacto antes de cada cambio.

Confirma la sintaxis y la salida de los comandos en el build instalado antes de utilizarlos.

Abrir la consola correcta

Se puede acceder a la CLI mediante cable de consola, por SSH o desde admin > Console en WebAdmin. Para SSH, permitir SSH para la zona necesaria en Administration > Device access > Local service ACL. admin > Console requiere acceso HTTPS para esa zona. Siempre que sea posible, limitar el acceso de administración a hosts concretos mediante una Local service ACL exception rule.

Después de iniciar sesión, seleccionar 4. Device Console. Allí, ? muestra los argumentos admitidos y su descripción para un comando empezado. system wireless-controller pertenece a Device Console. Advanced Shell es un entorno distinto, que se usa más abajo solo para consultar logs mediante comandos documentados de solo lectura; no es intercambiable con Device Console.

Registrar el estado inicial y el síntoma

Comprobar primero las ramas disponibles en el build instalado y leer los valores actuales:

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

Sustituir <AP_serial_number> por el número de serie del AP afectado, sin escribir los signos angulares. Registrar también el build de SFOS, modelo y firmware del AP, SSID, banda, canal, ancho de canal, MAC e IP del cliente de prueba, hora y un síntoma reproducible. En HA, anotar en qué nodo se ha iniciado sesión. Tras un failover, no repetir el diagnóstico sin criterio en ambos nodos.

Un estado normal del controlador solo confirma el plano de control. No demuestra asociación del cliente, DHCP, DNS, autenticación ni funcionamiento de la ruta de datos.

Comprobar primero WebAdmin y los logs adecuados

En Wireless > Access points, confirmar que el AP está activo y que coinciden modelo y número de serie. Sophos Firewall gestiona los AP por el puerto 2712. Si falta un AP o aparece inactivo, revisar primero zona, VLAN, puerto de switch, direccionamiento y ruta hacia ese puerto. Aceptar un AP desconocido no es una prueba: verificar modelo, serie, ubicación y red de administración antes de pulsar Accept.

La ayuda de SFOS 22 asigna estos archivos a los problemas Wi-Fi:

• awed.log: comunicación entre AP o APX y el firewall
• wc_remote.log: comunicación de clientes Wi-Fi con AP o APX
• hostapd.log: eventos de SSID para LocalWifi
• hotspotd.log: eventos de hotspot

SFOS 22 documenta oficialmente tail -f, grep y less para leer logs de diagnóstico en 5. Device Management > 3. Advanced Shell. La sintaxis genérica documentada permite estos ejemplos acotados:

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

Sustituir cada marcador por un único identificador exacto y omitir los signos angulares. Ejecutar tail -f solo durante la reproducción breve y detenerlo con Ctrl+C; salir de less con q. Estos comandos leen un solo archivo relevante y no sustituyen los comandos de Device Console anteriores. Las acciones de servicio start, stop y restart, así como las acciones de debug, cambian el estado del sistema: no utilizarlas como diagnóstico general. Requieren una necesidad específica del caso, un estado inicial registrado y un plan explícito de rollback. Si estas comprobaciones no bastan, habilitar acceso temporal en Diagnostics > Support access y enviar la Access ID por el canal de soporte acordado.

Ejecutar Remote Packet Capture en un solo AP

remote_pktcap incorpora paquetes del AP a un Packet Capture que se ejecuta simultáneamente en el firewall. Sophos exige un ap_debuglevel global de al menos 4. El nivel de debug es global; el comando de captura usa un número de serie AP específico.

Requisito previo al paso 1: Comprueba y registra el estado de captura de este AP con system wireless-controller remote_pktcap show <AP_serial_number> y el estado de captura existente del firewall en Diagnostics > Packet capture. Si alguna captura ya está activa o su estado no está claro, no cambies el filtro, el estado de captura ni el nivel global de debug. Identifica al responsable y el propósito y suspende este procedimiento hasta disponer de un estado inicial expresamente aprobado con ambas capturas inactivas. No asumas el control ni detengas diagnósticos ajenos.

1. Ejecutar system wireless-controller global show y guardar el ap_debuglevel exacto. Si ya es 4 o superior, no cambiarlo.

2. Si es inferior a 4, establecerlo temporalmente en 4 y volver a leerlo:

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

3. Abrir Diagnostics > Packet capture, configurar un filtro estrecho para cliente, destino, puerto o protocolo e iniciar Packet capture.

4. Activar la captura del AP y comprobar su estado:

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

5. Generar solo el flujo documentado. Packet capture muestra, entre otros datos, interfaces de entrada y salida, Status, Reason y Firewall Rule ID. Sirven para determinar si la trama llega al AP, si el firewall la procesa o si una política la descarta.

6. Detén solo las capturas iniciadas por este procedimiento desde el estado inicial inactivo confirmado: primero tu captura del AP con los comandos siguientes y después tu Packet capture en WebAdmin. Deja intactas las capturas que no hayas iniciado y las de otros responsables:

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

7. Si se modificó ap_debuglevel, restaurar y verificar el valor guardado antes de la prueba:

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

Sustituir <saved_ap_debuglevel> por el valor anterior exacto. La sintaxis documentada de Wireless Controller no ofrece una rama reset para este parámetro; un valor predeterminado supuesto no es un rollback seguro.

No utilizar los demás parámetros como solución general

Device Console enumera otros parámetros globales. Sus rangos están documentados, pero no siempre hay contexto suficiente sobre sus efectos:

• ap_localdebuglevel: 0 a 15; lectura con get, cambio con set
• log_level: 0 a 7; se escriben mensajes con el nivel configurado o superior, por lo que un número mayor no significa simplemente «más logs»
• ap_autoaccept, stay_online y store_bss_stats: 0 desactivado, 1 activado
• tunnel_id_offset: 0 a 65535

No cambiar estos valores de forma preventiva ni ejecutar varios cambios juntos. ap_autoaccept elimina el control consciente al aceptar un AP. La página tampoco ofrece contexto suficiente para recomendar generalmente stay_online, store_bss_stats o tunnel_id_offset. Utilizarlos solo siguiendo instrucciones específicas de Sophos Support, guardar el valor con global show y restaurar después ese valor exacto.

Retrasar RADIUS Accounting Start solo con una causa demostrada

radius_accounting_start_delay solo corresponde a un problema de orden confirmado: 802.1X Accounting Start llega antes de que DHCP asigne una dirección. Wi-Fi SSO no puede obtener entonces una Framed-IP-Address útil. El rango documentado es de 0 a 60 segundos; Sophos utiliza 30 segundos en KBA-000006795.

El procedimiento documentado por Sophos se aplica a modelos APX administrados por SFOS con un SSID WPA/WPA2 Enterprise. La KBA no confirma esta ruta de SSO para AP6 ni para controladores de terceros genéricos.

Antes de cambiarlo, demostrar la secuencia con logs RADIUS y una captura y guardar el valor actual con global show. El procedimiento completo está en Comprobar RADIUS SSO y Accounting. Después de la prueba, ejecutar system wireless-controller global radius_accounting_start_delay <saved_delay> con el valor anterior exacto y comprobarlo con global show.

El ancho de canal es configuración, no diagnóstico

Sophos documenta 20 y 40 MHz para 2,4 GHz, y 20, 40 y 80 MHz para 5 GHz. La página CLI indica por error 2.5GHz en un punto. No copiar ese token sin comprobarlo. La rama documentada tampoco ofrece comandos separados para leer o restablecer el ancho. Sin un estado inicial guardado y una sintaxis confirmada, no es un paso de diagnóstico para copiar y pegar.

Planificar el ancho desde la configuración normal de Wireless Network en WebAdmin. Ocupación de canales, redes vecinas, señal, retransmisiones, capacidades de clientes y densidad determinan si un canal más ancho ayuda.

Interpretar la configuración del AP y las respuestas XML API

Si la automatización modificó el AP, comprueba también el objeto guardado WirelessAccessPoint. Las referencias XML de SFOS 22 y 23 presentan la misma descripción de campos; esto no demuestra compatibilidad de hardware en todos los builds. ID es el identificador obligatorio de tipo string del AP, no Label, la SSID ni un nombre de grupo arbitrario. Update Access Point también enumera Label, Country y Band como obligatorios; Delete Access Point enumera ID. Eliminar no es una prueba de diagnóstico ni quitar una asignación de SSID: requiere una retirada aprobada expresamente.

Comprueba las dependencias: Group selecciona el grupo de AP y WirelessNetworks/Network las asignaciones WLAN. Para 2,4 GHz están Channel2.4GHz, DynChan, TimeBasedScan, ScanTime/Time, TXPower y ChannelWidth; para 5 GHz, los correspondientes Channel5GHz, DynChan5GHz, TimeBasedScan5GHz, ScanTime5GHz/Time, TXPower5GHz y ChannelWidth11a. Asigna un horario solo con el escaneo temporal activado, y activa este solo con selección dinámica de canal en esa banda. VLANTagging y su dependiente APVLANID afectan a la ruta de administración; el rango documentado de APVLANID es 1–4094. Contrasta grupo, SSID, VLAN de administración, interfaz y ruta del switch con la configuración Wi-Fi. AP6 queda fuera de la administración SFOS.

No es una solicitud de escritura lista para enviar: El ejemplo usa RootAccessPoint para Role, pero la descripción indica point/portal. Los interruptores de escaneo muestran Enable en el ejemplo y solo t en la descripción; algunas descripciones de banda también son incoherentes. No normalices estos valores por tu cuenta. Antes de cambiar nada, confirma etiquetas padre, valores y operación exactos en API help del build instalado; si la correspondencia sigue sin estar clara, no escribas y consulta a Support.

Estas correspondencias son estados XML API y símbolos de referencia sin resolver, no códigos HTTP ni textos de mensajes de ejecución verificados. Cada código listado pertenece a la operación y al símbolo indicados:

• 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

No deduzcas un límite, una causa ni un reintento seguro solo del símbolo. Antes de repetir una escritura, compara la respuesta con el estado realmente guardado del AP, grupo, WLAN y VLAN, también para 216; después prueba la conexión del cliente y la ruta de datos. La guía central de seguridad XML API explica protección de acceso, operaciones explícitas, resultados parciales y rollback.

Evaluar el resultado y cerrar correctamente

Después del diagnóstico, comprobar estado del AP, asociación, concesión DHCP, resolución DNS, autenticación, Firewall Rule ID esperada, pérdida, latencia y aplicación afectada. Para RADIUS, revisar también Accounting Start, Framed-IP-Address y asignación de usuario.

El proceso termina cuando sus propias capturas temporales han finalizado: remote_pktcap show debe confirmar el estado inactivo de la captura del AP iniciada aquí, y WebAdmin el de Packet capture iniciado aquí. Los demás diagnósticos quedan intactos; si el procedimiento se suspendió porque ya había una captura activa, detenerla no es un requisito de finalización. global show debe contener los valores de debug y parámetros guardados. Si la causa sigue sin estar clara, conservar hora, serie del AP, cliente, captura y nombres de logs para Sophos Support en vez de probar más parámetros globales.

FAQ