Diagnostisera Sophos Firewall Wireless Controller via CLI

Kör system wireless-controller i 4. Device Console på SFOS 22. Läs felsökningsloggar separat i 5. Device Management > 3. Advanced Shell. Börja med skrivskyddade kontroller och aktivera Remote Packet Capture först när problemet har avgränsats till en accesspunkt och en testklient.

⚠️ Integritet och drift: En trådlös capture kan innehålla användartrafik, IP-adresser, DNS-frågor samt autentiserings- och sessionsdata. Använd ett snävt filter, fånga ett kort reproducerbart test och skydda den exporterade filen. Anteckna det exakta utgångsvärdet före varje ändring.

Kontrollera syntaxen och den faktiska utdata på den installerade versionen.

Öppna rätt konsol

CLI är tillgängligt lokalt med en konsolkabel, på distans via SSH eller via admin > Console i WebAdmin. För SSH ska SSH tillåtas för den aktuella zonen under Administration > Device access > Local service ACL. admin > Console kräver HTTPS-åtkomst för zonen. Begränsa om möjligt administrationen till behöriga värdar med en Local service ACL exception rule.

Efter inloggning väljs 4. Device Console. Där visar ? de stödda argumenten och deras beskrivningar för ett delvis inmatat kommando. system wireless-controller är ett Device Console-kommando. Advanced Shell är en separat miljö som nedan endast används för dokumenterad, skrivskyddad granskning av loggar; den kan inte ersätta Device Console.

Dokumentera utgångsläge och symptom

Kontrollera först vilka kommandogrenar som finns i den installerade versionen och läs av aktuella värden:

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

Ersätt <AP_serial_number> med serienumret för berörd AP och skriv inte vinkelparenteserna. Anteckna även SFOS-version, AP-modell och firmware, SSID, band, kanal, kanalbredd, testklientens MAC- och IP-adress, tidpunkt och ett exakt reproducerbart symptom. I ett HA-par antecknas även vilken nod inloggningen skedde på. Upprepa inte diagnostiken slentrianmässigt på båda noderna efter en failover.

Normal status för styrenheten bekräftar endast kontrollplanet. Den visar inte att klientanslutning, DHCP, DNS, autentisering eller datavägen fungerar.

Kontrollera WebAdmin och relevanta loggar först

Kontrollera under Wireless > Access points att AP:n är aktiv och att modell och serienummer stämmer. Sophos Firewall hanterar åtkomstpunkter över port 2712. Om en AP saknas eller är inaktiv kontrolleras först zon, VLAN, switchport, adressering och nätverksvägen till porten. Att acceptera en okänd AP är inte ett diagnostiskt steg: bekräfta dess modell, serienummer, plats och hanteringsnätverk före Accept.

SFOS 22-dokumentationen kopplar följande loggfiler till trådlösa problem:

• awed.log: kommunikation mellan AP eller APX och brandväggen
• wc_remote.log: trådlös klientkommunikation med AP eller APX
• hostapd.log: SSID-händelser för LocalWifi
• hotspotd.log: hotspot-händelser

SFOS 22 dokumenterar officiellt tail -f, grep och less för läsning av felsökningsloggar i 5. Device Management > 3. Advanced Shell. Den generella dokumenterade syntaxen stöder följande avgränsade exempel:

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

Ersätt varje platshållare med en enda exakt identifierare och utelämna vinkelparenteserna. Kör endast tail -f under den korta reproduktionen och avsluta med Ctrl+C; lämna less med q. Varje kommando läser en relevant fil och ersätter inte Device Console-kommandona ovan. Tjänståtgärderna start, stop och restart samt debugåtgärder ändrar systemets tillstånd. Använd dem inte som generell diagnostik: de kräver ett behov för det specifika fallet, ett dokumenterat utgångsläge och en uttrycklig återställningsplan. Om kontrollerna inte räcker aktiveras tidsbegränsad åtkomst under Diagnostics > Support access och åtkomst-ID skickas via den överenskomna supportkanalen.

Kör Remote Packet Capture på en enda AP

remote_pktcap skickar AP-paket till en Packet Capture som körs samtidigt på brandväggen. Sophos kräver ett globalt ap_debuglevel på minst 4. Debug-nivån är global, medan fångstkommandot riktar sig till ett specifikt AP-serienummer.

Förutsättning före steg 1: Kontrollera och dokumentera fångststatusen för denna AP med system wireless-controller remote_pktcap show <AP_serial_number> och brandväggens befintliga fångststatus under Diagnostics > Packet capture. Om någon av fångsterna redan är aktiv eller statusen är oklar ska du inte ändra filtret, fångststatusen eller den globala debugnivån. Fastställ ansvarig och syfte och pausa denna procedur tills ett uttryckligen godkänt utgångsläge med båda fångsterna inaktiva finns. Ta inte över eller stoppa någon annans diagnostik.

1. Kör system wireless-controller global show och anteckna det exakta värdet för ap_debuglevel. Om det redan är 4 eller högre ska det inte ändras.

2. Om det är lägre än 4 ställs det tillfälligt in på 4 och statusen läses av igen:

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

3. Öppna Diagnostics > Packet capture, konfigurera ett smalt filter för testklienten, destinationen, porten eller protokollet och starta Packet capture.

4. Aktivera AP-fångsten och kontrollera statusen:

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

5. Skapa endast det dokumenterade testflödet. Packet capture visar bland annat inkommande och utgående gränssnitt, Status, Reason och Firewall Rule ID. Uppgifterna visar om ramen når AP:n, behandlas av brandväggen eller nekas av en regel.

6. Stoppa endast fångster som denna procedur startade från det bekräftade inaktiva utgångsläget: först din egen AP-fångst med kommandona nedan, därefter din egen Packet capture i WebAdmin. Lämna fångster som du inte startade och andra operatörers fångster oförändrade:

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

7. Om ap_debuglevel ändrades, återställ och verifiera värdet som antecknades före testet:

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

Ersätt <saved_ap_debuglevel> med det exakta tidigare värdet. Den dokumenterade syntaxen för Wireless Controller har ingen reset-gren för parametern, så ett antaget standardvärde ger ingen säker återställning.

Använd inte andra parametrar som en generell lösning

Device Console listar ytterligare globala parametrar. Deras numeriska intervall dokumenteras, men den operativa effekten förklaras inte tillräckligt i varje fall:

• ap_localdebuglevel: 0 till 15; läs med get, ändra med set
• log_level: 0 till 7; meddelanden på eller över den konfigurerade nivån skrivs till loggen, så ett högre värde betyder inte automatiskt ”mer loggning”
• ap_autoaccept, stay_online och store_bss_stats: 0 off, 1 på
• tunnel_id_offset: 0 till 65535

Ändra inte dessa värden i förebyggande syfte och kör inte ett block med flera ändringar. I synnerhet tar ap_autoaccept bort den avsiktliga kontrollpunkten när en AP accepteras. Kommandosidan ger inte tillräckligt med sammanhang för generella felsökningsrekommendationer om stay_online, store_bss_stats eller tunnel_id_offset. Använd dem endast enligt fallspecifika instruktioner från Sophos Support, spara det tidigare värdet med global show och återställ exakt detta värde efteråt.

Fördröj RADIUS Accounting Start endast vid en bevisad orsak

radius_accounting_start_delay är endast avsett för ett bekräftat ordningsproblem: 802.1X Accounting Start anländer innan DHCP tilldelar klienten en adress. Wi-Fi SSO kan inte få en användbar Framed-IP-Address från Accounting Start-meddelandet. Det dokumenterade intervallet är 0 till 60 sekunder; Sophos använder 30 sekunder i KBA-000006795.

Det arbetsflöde som Sophos dokumenterar gäller SFOS-hanterade APX-modeller med ett WPA/WPA2 Enterprise-SSID. KBA:n bekräftar inte denna SSO-väg för AP6 eller godtyckliga styrenheter från tredje part.

Före en ändring ska ordningsföljden beläggas med RADIUS-loggar och en fångst och det aktuella värdet sparas med global show. Det fullständiga arbetsflödet finns i Kontrollera RADIUS SSO och Accounting. Efter testet, kör system wireless-controller global radius_accounting_start_delay <saved_delay> med exakt tidigare värde och verifiera det med global show.

Kanalbredd är konfiguration, inte diagnostik

Sophos dokumenterar kanalbredderna 20 och 40 MHz för 2,4 GHz samt 20, 40 och 80 MHz för 5 GHz. CLI-sidan säger felaktigt 2.5GHz på ett ställe. Kopiera inte detta värde utan att kontrollera det. Den dokumenterade CLI-grenen ger inte heller något separat läs- eller återställningskommando för kanalbredd. Det är inte ett säkert copy-and-paste diagnostiskt steg utan en sparad baslinje och bekräftad syntax.

Planera kanalbredden i den vanliga Wireless Network-konfigurationen i WebAdmin. Kanalanvändning, grannnätverk, signal, retransmissioner, klientfunktioner och platsdensitet avgör om en bredare inställning hjälper alls.

Tolka AP-konfiguration och XML API-svar

Om automatisering har ändrat AP:n ska du även kontrollera det sparade objektet WirelessAccessPoint. XML-referenserna för SFOS 22 och 23 har samma fältbeskrivningar; det bevisar inte hårdvarustöd på varje version. ID är AP:ns obligatoriska identifierare av typen string, inte Label, SSID eller ett godtyckligt gruppnamn. Update Access Point anger även Label, Country och Band som obligatoriska; Delete Access Point anger ID. Borttagning är varken diagnostik eller borttagning av en SSID-tilldelning och kräver en uttryckligen godkänd avveckling.

Kontrollera beroendena: Group väljer AP-gruppen och WirelessNetworks/Network WLAN-tilldelningarna. För 2,4 GHz finns Channel2.4GHz, DynChan, TimeBasedScan, ScanTime/Time, TXPower och ChannelWidth; för 5 GHz motsvarande Channel5GHz, DynChan5GHz, TimeBasedScan5GHz, ScanTime5GHz/Time, TXPower5GHz och ChannelWidth11a. Tilldela ett schema endast när tidsstyrd skanning är aktiverad och aktivera den endast med dynamiskt kanalval på respektive band. VLANTagging och dess beroende APVLANID gäller hanteringsvägen; det dokumenterade intervallet för APVLANID är 1–4094. Jämför grupp, SSID, hanterings-VLAN, gränssnitt och switchväg med Wi-Fi-konfigurationen. AP6 förblir utanför SFOS-hanteringen.

Ingen skrivbegäran som är klar att skicka: Exemplet använder RootAccessPoint för Role, men fältbeskrivningen anger point/portal. Skanningsalternativen visar Enable i exemplet, medan beskrivningen endast tillåter t; vissa bandbeskrivningar är också inkonsekventa. Normalisera inte värdena själv. Bekräfta före en ändring de exakta överordnade taggarna, värdena och åtgärden i API help på den installerade versionen; om kopplingen förblir oklar ska du inte skriva utan kontakta Support.

Dessa kopplingar är XML API-statusvärden och olösta referenssymboler, inte HTTP-koder eller verifierade meddelandetexter vid körning. Varje angiven kod hör till den namngivna åtgärden och symbolen:

• 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

Dra inte slutsatser om en gräns, orsak eller säker upprepning från enbart symbolen. Jämför före varje nytt skrivförsök svaret med det faktiskt sparade AP-, grupp-, WLAN- och VLAN-tillståndet, även för 216; testa därefter klientanslutningen och datavägen. Den centrala säkerhetsguiden för XML API förklarar åtkomstskydd, uttryckliga åtgärder, delresultat och återställning.

Utvärdera resultatet och avsluta sessionen korrekt

Efter diagnostiken kontrolleras AP-status, klientassociation, DHCP-lease, DNS-upplösning, autentisering, förväntat Firewall Rule ID, paketförlust, latens och den berörda applikationen. För RADIUS kontrolleras även Accounting Start, Framed-IP-Address och användarmappning.

Arbetsflödet är klart när dess egna tillfälliga fångster har avslutats: remote_pktcap show ska bekräfta inaktiv status för AP-fångsten som startades här, och WebAdmin för Packet capture som startades här. Övrig diagnostik lämnas oförändrad; om proceduren pausades på grund av en redan aktiv fångst är det inte ett avslutningskrav att stoppa den. global show ska visa de sparade debug- och parametervärdena. Om orsaken fortfarande är oklar sparas tidpunkt, AP-serienummer, testklient, fångst och relevanta loggfilnamn för Sophos Support i stället för att prova fler globala inställningar.

FAQ