Risoluzione dei problemi di interoperabilità dei client wireless con CUWN
Sommario
Introduzione
Questo documento descrive i problemi di interoperabilità che si verificano con la soluzione Cisco Unified Wireless Network (CUWN).
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Cisco Wireless AP
- WLC (Wireless LAN Controller)
- Dispositivi di rete correlati
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Può essere comune trovare che dato i vari dispositivi client che esistono e continuano a essere sviluppati. È possibile che sorgano diversi problemi relativi alla creazione, alla manutenzione o semplicemente al raggiungimento del massimo dalla connessione alla rete wireless e al supporto dell'infrastruttura.
Questo spesso si riduce a un semplice problema di configurazione da parte del dispositivo client e/o dell'infrastruttura wireless stessa. Tuttavia, in alcuni casi ciò può essere attribuito a un problema di interoperabilità relativo a uno specifico dispositivo client e ai componenti che lo supportano (supplicant, scheda WLAN, driver wireless, ecc.) e/o agli access point in questione. In qualità di tecnici wireless, tali problemi di interoperabilità offrono l'opportunità di identificare, risolvere e risolvere problemi potenzialmente complessi.
Questo documento descrive in dettaglio le informazioni che devono essere raccolte inizialmente per indagare e risolvere in modo efficace questi problemi di interoperabilità wireless quando si presentano con la soluzione Cisco Unified Wireless Network (CUWN). La necessità di un tale approccio globale diventa sempre più importante con l'aumento costante del numero e delle combinazioni di dispositivi client wireless e radio dei punti di accesso.Potrebbero essere richieste ulteriori informazioni su quanto delineato in questo articolo, che dovrebbero essere raccolte caso per caso, dato il numero illimitato di variabili che potrebbero dettare tali requisiti. Tuttavia, le informazioni qui riportate rappresentano una linea guida generica per risolvere eventuali problemi di interoperabilità dei client wireless.
I. Definizione del problema
Il primo passo per affrontare in modo efficace qualsiasi problema con l'intento di ottenere una soluzione, è quello di definire accuratamente il problema in questione. A tal fine, assicurarsi che almeno queste domande vengano poste e che le loro risposte siano chiaramente documentate:
- Il problema è limitato a uno specifico modello di access point e/o tipo radio (2,4 GHz rispetto a 5 GHz)?
- Il problema è stato rilevato solo su una o più versioni specifiche del software WLC?
- Il problema si verifica solo con versioni specifiche di tipi di client e/o software (versione del sistema operativo, versione del driver WLAN, ecc.)?
- Esistono altri dispositivi wireless che non rilevano questo problema? In caso affermativo, quali?
- Il problema è riproducibile quando il client è connesso a un'installazione wireless semplificata, ad esempio un SSID aperto, con una larghezza di canale di 20 MHz e 802.11ac disabilitato? in altre parole, il problema si verifica solo in modalità 802.11n rispetto alla modalità 802.11ac?
- Se il problema non è riproducibile con un SSID aperto, a quale configurazione di protezione minima è associato il problema? (PSK o 802.1X sulla WLAN).
- Quali erano le precedenti versioni software e di configurazione valide?
II. Configurazione WLC e registri generali
Run-Config
Senza eccezioni, è assolutamente necessario raccogliere la configurazione WLC per un'analisi dettagliata delle funzionalità utilizzate dal cliente, della loro configurazione specifica e di altri dettagli simili. A tal fine, è necessario stabilire una sessione Telnet/SSH sui WLC in questione e salvare l'output di questi comandi CLI in un file di testo:
config paging disable show run-config
L'uscita di configurazione di esecuzione completa è sempre preferibile, in quanto include informazioni dettagliate relative agli access point collegati e alle informazioni RF associate. Tuttavia, in alcuni casi e situazioni, ad esempio quando si lavora inizialmente con un WLC con un numero elevato di AP aggiunti (8510 WLC con oltre 2500 AP). Inizialmente, si potrebbe preferire raccogliere solo la configurazione del WLC senza tali informazioni sull'access point per poterla esaminare rapidamente, in quanto il completamento della configurazione di esecuzione completa potrebbe richiedere 30 minuti o più, dato il numero di access point. Tuttavia, potrebbe essere necessario raccogliere l'output completo della configurazione di esecuzione in un secondo momento.
A tale scopo, è possibile raccogliere facoltativamente l'output di questi comandi CLI in un file di testo:
config paging disable show run-config no-ap show wlan apgroups
File di configurazione WLC
Oltre all'output show run-config o show run-config no-ap, si consiglia di raccogliere anche un backup completo della configurazione WLC. Ciò è utile, se il ricreazione di un laboratorio deve essere eseguita sia da TAC/HTTS che da Escalation BU, per cercare di riprodurre il problema in un ambiente lab Cisco. Un backup del WLC può essere raccolto tramite la GUI o la CLI del WLC in questione, con l'uso del TFTP o dell'FTP per salvare il file di configurazione sul server TFTP/FTP esterno. L'esempio mostra come usare sia la GUI sia la CLI per salvare un backup del WLC, con l'uso del TFTP:
GUI
Comandi > Carica file > Configurazione > Carica come mostrato nell'immagine.
CLI
transfer upload datatype config
transfer upload mode tftp transfer upload serverip <TFTP-Server_IP-address> transfer upload path / transfer upload filename <desired-filename> transfer upload start
Syslog dal WLC
A questo punto, si desidera anche raccogliere i log correnti dal WLC per un'ulteriore revisione, se necessario. Idealmente, si desidera raccogliere questi log subito dopo il test con un client wireless in cui il problema segnalato viene riprodotto. Se il cliente esporta i log WLC in un server syslog esterno, è possibile recuperarli da tale server. In caso contrario, è possibile salvare il file msglog e il traplog correntemente archiviati nel WLC salvando l'output di questa sessione CLI in un altro file di testo:
config paging disable show msglog show traplog
III. Dettagli e informazioni sul dispositivo client
Il passo successivo consiste nel raccogliere quante informazioni e specifiche sui dispositivi client in uso possano presentare un potenziale problema di interoperabilità wireless. Tali informazioni devono comprendere, tra l'altro:
- Tipo di client (tablet, smartphone, notebook, ecc.)
- Marca e modello del dispositivo
- Versione del sistema operativo
- Modello scheda WLAN
- Versione driver scheda WLAN
- Supplicant used (Windows Zero Config / Auto Config, Intel PROSet,...)
- Sicurezza configurata per l'utilizzo da parte del client wireless e della WLAN (Open, PSK, EAP-PEAP/MSCHAPv2,...)
- Prendere nota di eventuali parametri client modificati rispetto alle impostazioni predefinite fornite dal fornitore in questione (stato di sospensione, parametri di roaming, U-APSD,...).
IV. Topologia della rete
Per accelerare ulteriormente le operazioni di risoluzione dei problemi e il processo RCA (Root Cause Analysis), si consiglia sempre di fornire un diagramma della topologia di rete dettagliato e completo. Il diagramma della topologia di rete non deve solo includere dettagli sulla rete e sull'infrastruttura wireless, ma deve anche fornire informazioni dettagliate sui dispositivi wireless in questione che operano all'interno della rete (stampanti/scanner, VLAN client in uso, ecc.) e sulla loro posizione relativa l'una all'altra.
Per creare un diagramma di rete di questo tipo è possibile utilizzare diversi strumenti (Microsoft Visio, draw.io,...) e diversi stili. L'aspetto importante è semplicemente garantire che le informazioni corrette siano chiaramente riportate nel diagramma fornito per la revisione da parte di tutte le parti coinvolte e dei fornitori. Topologia di rete di esempio che acquisisce informazioni di base ma utili relative sia all'infrastruttura che ai dispositivi client, come mostrato nell'immagine.
V. Registrazione dei dettagli aggiuntivi e delle specifiche
Garantire che le informazioni appropriate vengano raccolte al momento di qualsiasi test con i dispositivi client in cui gli utenti finali riscontrano problemi. Si consiglia di creare preventivamente un foglio di calcolo o un modulo simile per registrare tutti i problemi del client e i relativi dettagli osservati al momento del test, come nell'esempio seguente:
| Indirizzo MAC | Username | Descrizione del sintomo segnalato | Ora in cui l'utente finale ha osservato il sintomo | Eseguire il ping del gateway predefinito S/N | Stato del segnale WiFi (connesso/tentativo di connessione) | Record ipconfig /all (o equivalente) |
| xxyy.aabb.0011 | utente_test1 | Si disconnette in modo intermittente dal punto di accesso. | Connettività di rete e associazione wireless interrotte da AP3. | N | Tentativo di connessione in corso | ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 etere xx:yy:aa:bb:00:11 inet6 fe80::848:cb8f:881a:4cbf%en0 prefisso 64 ambito protetto 0x4 inet 192.168.10.237 netmask 0xffff00 broadcast 192.168.10.255 nd6 options=201<PERFORMNUD,DAD> supporti: selezione automatica stato: attivo |
L'obiettivo di questo esercizio è quello di documentare e determinare un modello di interesse comune, nonché di ottenere un'immagine accurata dei problemi in questione. Una volta preparato il foglio di calcolo per la raccolta dei dati, è possibile iniziare i test. Di seguito sono riportate alcune considerazioni aggiuntive ma importanti.
VI. WLC - Comandi Show e Debug
Quando si eseguono test per riprodurre e risolvere potenziali problemi di interoperabilità dei client wireless, è indispensabile raccogliere i debug e i registri aggiuntivi dall'infrastruttura wireless in uso. Nelle due sezioni vengono descritti in dettaglio i log specifici e l'output del debug iniziale raccolti rispettivamente dal WLC e dall'AP.
Comandi di debug WLC
config sessions timeout 0
debug client <MAC_address> debug dhcp message enable
Per quanto riguarda la natura del problema in questione, è possibile aggiungere questi debug WLC caso per caso:
- debug aaa detail enable: da utilizzare in caso di problemi di autenticazione con il server AAA
- debug aaa events enable - da utilizzare in caso di problemi di autenticazione con il server AAA
- debug aaa all enable: utilizzare questo comando per problemi di autenticazione. L'output di questo debug è dettagliato, quindi utilizzarlo solo quando assolutamente necessario (per casi di override AAA,...)
- debug mobility handoff - da utilizzare in caso di problemi di roaming tra WLC
Una volta che il problema è stato riprodotto con il client wireless in questione, e tutte le informazioni descritte nelle sezioni precedenti e successive a questo sono state raccolte e documentate. Per eseguire questi comandi CLI, è necessario disabilitare i debug sul WLC.
debug disable-all
Comandi Show WLC
config paging disable show time show client detail <MAC_address> ping <client_IP-address> <repeat count [1-100]>
Come accennato in precedenza, accertarsi di eseguire i debug WLC in una sessione Telnet/SSH e di raccogliere l'output di questi comandi show in un'altra sessione Telnet/SSH sul WLC. Lo stesso deve essere fatto per raccogliere i debug dell'access point e visualizzare l'output dei comandi descritto in questa sezione.
VII. AP - Comandi Show e Debug
Access point Cisco IOS® lightweight
Prima di avviare il debug sui Cisco IOS® Lightweight Access Point coinvolti nel test, come i Cisco 2600, 2700, 3700 o i Cisco Access Point del modello precedente. È necessario eseguire questi comandi CLI sull'access point per evitare un timeout al momento di una sessione Telnet/SSH/console sugli access point in questione quando il client esegue i test:
debug capwap console cli config t line vty 0 4 exec-timeout 0 session-timeout 0
È inoltre possibile seguire questa procedura per utilizzare la connessione della console e sostituire l'istruzione line vty 0 4 con la console 0, in modo da disabilitare di conseguenza i timeout di esecuzione e di sessione per una connessione seriale/console.
- line console 0 - utilizzare per modificare i parametri di timeout della sessione seriale
- line vty 0 4 - utilizzare per modificare i parametri di timeout della sessione Telnet/SSH
Comandi Show AP
Prima di iniziare il test, è necessario raccogliere un esempio di questi comandi show sull'access point. Raccogliere l'output di questi comandi show almeno due volte per ogni test che coinvolge il client wireless in questione, sia prima che dopo il completamento del test.
term len 0 show clock show tech show capwap client mn show int do1 dfs show logging more event.log show trace dot11_rst display time format local show trace dot11_rst show trace dot11_bcn display time format local show trace dot11_bcn
Comandi di debug AP
Dopo aver raccolto l'output iniziale dei comandi show sopra menzionati, è possibile abilitare i debug sullo stesso punto di accesso in una sessione Telnet/SSH separata, come mostrato. Assicurarsi di salvare l'intero output in un file di testo.
debug dot11 {d0|d1} monitor addr <client_MAC-address>
debug dot11 {d0|d1} trace print clients mgmt keys rxev txev rcv xmt txfail ba
term mon
| Contrassegna | Descrizione |
| d0 | Radio da 2,4 GHz (slot 0) |
| d1 | Radio 5 GHz (slot 1) |
| gestione | Pacchetti di gestione traccia |
| baccano | Informazioni ACK blocco di traccia |
| rcv | Traccia pacchetti ricevuti |
| tasti | Chiavi set di traccia |
| rxev | Traccia eventi ricevuti |
| txev | Traccia eventi di trasmissione |
| txrad | Trasmissione di traccia alla radio |
| xmt | Traccia pacchetti di trasmissione |
| txfail | Errori di trasmissione di traccia |
| tariffe | Rileva modifiche velocità |
Per disabilitare i debug sull'access point una volta completati il processo di test e raccolta dei dati, è possibile eseguire questo comando CLI sull'access point:
u all
Access point AP-COS
per access point compatibili con lo standard 802.11ac wave 2 e versioni successive, ad esempio i modelli 1800, 2800 e 3800. I nuovi modelli di access point introducono un sistema operativo completamente nuovo per le piattaforme di access point note come AP-COS. Di conseguenza, non tutti i comandi precedentemente utilizzati sui tradizionali access point basati su Cisco IOS® lightweight sono ancora validi. Se la risoluzione di un problema implica l'interoperabilità con diversi dispositivi STA client e punti di accesso modello AP-COS, le informazioni devono essere raccolte dai punti di accesso AP-COS interessati dal test equivalente.
Prima di avviare il debug su uno o più access point AP-COS coinvolti nel test. È necessario eseguire questi comandi CLI sull'access point per evitare un timeout al momento di una sessione Telnet/SSH/console sugli access point in questione quando il client esegue i test:
exec-timeout 0
Comandi Show AP-COS
Prima di iniziare il test, è necessario raccogliere un esempio di questi comandi show sull'access point. Raccogliere l'output di questi comandi show almeno due volte per ogni test che coinvolge il client wireless in questione, sia prima che dopo il completamento del test.
term len 0
show clock show tech
show client statistics <client_MAC-address>
show cont nss status
show cont nss stats
show log
Serie 1800 | Comandi di debug AP-COS
Questi debug sono specifici della serie 18xx di access point. Ciò è dovuto al fatto che i chipset utilizzati per la serie 1800 di access point sono diversi da quelli trovati nei punti di accesso serie 2800/3800, quindi in questo scenario è necessario eseguire un set di debug diverso. I bug corrispondenti ai access point serie 2800/3800 sono illustrati nella sezione successiva.
Dopo aver raccolto l'output iniziale dei comandi show menzionati, è necessario abilitare i debug sugli stessi punti di accesso 1800 in una sessione Telnet/SSH separata, come mostrato. Assicurarsi di salvare l'intero output in un file di testo.
debug dot11 client level events addr <client_MAC-address> debug dot11 client level errors addr <client_MAC-address> debug dot11 client level critical addr <client_MAC-address> debug dot11 client level info addr <client_MAC-address> debug dot11 client datapath eapol addr <client_MAC-address> debug dot11 client datapath dhcp addr <client_MAC-address> debug dot11 client datapath arp addr <client_MAC-address>
In alcuni casi, potrebbe essere necessario abilitare anche i debug aggiuntivi sull'access point 18xx per risolvere ulteriormente i problemi di interoperabilità dei client. Tuttavia, questa operazione deve essere eseguita solo se/come richiesto da un tecnico Cisco TAC per una richiesta/un caso di assistenza corrispondente.
Poiché i debug aggiuntivi potrebbero non solo essere molto più dettagliati nell'output, ma possono anche introdurre un carico aggiuntivo sull'access point, pertanto è necessario più tempo per un'analisi corretta. Il che, in determinate condizioni, può potenzialmente interrompere il servizio se molti dispositivi client tentano di connettersi allo stesso punto di accesso durante il test o a variabili simili.
Per disabilitare i debug sul punto di accesso della variante AP-COS, su un access point serie 1800 o 2800/3800, una volta completato il processo di test e raccolta dei dati, è possibile eseguire questo comando CLI sull'access point:
config ap client-trace stop
Serie 2800/3800 | Comandi di debug AP-COS
Dopo aver raccolto l'output iniziale dei comandi show menzionati, è necessario abilitare i debug sugli stessi access point serie 2800/3800 in una sessione Telnet/SSH separata, come mostrato. Assicurarsi di salvare l'intero output in un file di testo.
config ap client-trace address add <client_MAC-address>
config ap client-trace filter all enable
config ap client-trace output console-log enable
config ap client-trace start
term mon
Per disabilitare i debug sull'access point serie 1800/2800/3800 al termine del processo di test e raccolta dei dati, è possibile eseguire questo comando CLI sull'access point:
config ap client-trace stop
VIII. Acquisizioni pacchetti lato client
Dal dispositivo client in uso, se si tratta di un notebook, MacBook o simile, è necessario raccogliere l'acquisizione del pacchetto in modalità promiscua dall'interfaccia wireless del dispositivo client utilizzato per riprodurre il problema. Utilità comuni come Netmon 3.4 (solo Windows) o Wireshark possono essere facilmente scaricate e utilizzate per raccogliere questa cattura e salvarla in un file *.pcap. Dipende dal dispositivo, ci potrebbero essere anche mezzi per raccogliere un tcpdump o simile dal client in questione, quindi potrebbe essere necessario consultare il produttore del dispositivo client per assistenza a questo proposito.
Di seguito è riportato un esempio di configurazione di un'acquisizione Wireshark per l'interfaccia wireless su un MacBook Pro:
Come per qualsiasi acquisizione di pacchetti, indipendentemente dall'utilità utilizzata per raccoglierli, assicurarsi di salvare il file in un formato pcap (*.pcap, *.pcapng, *.pkt,...). In questo modo, non solo i tecnici Cisco di un reparto possono visualizzare facilmente i file di acquisizione dei pacchetti, ma anche i tecnici di altri fornitori e organizzazioni (Intel, Apple,...). Ciò consente un processo di cooperazione e collaborazione più fluido, che facilita ulteriormente sia Cisco che i fornitori di dispositivi client a collaborare meglio tra loro per individuare e risolvere eventuali problemi di interoperabilità.
IX. Acquisizioni pacchetti OTA (Over-the-Air)
Per risolvere efficacemente eventuali problemi di interoperabilità wireless, è fondamentale raccogliere un pacchetto OTA di qualità per l'acquisizione del problema. Ciò consente l'analisi dettagliata della comunicazione wireless 802.11 effettiva tra il client wireless e le radio del punto di accesso in questione, oltre a fornire un'ulteriore prospettiva dei registri lato client e dell'infrastruttura wireless, e dei debug. Si tratta di un passo fondamentale che deve essere compiuto per ogni test di un potenziale problema di interoperabilità wireless, senza eccezioni.
Tuttavia, spesso il cliente finale non è adeguatamente attrezzato o preparato per raccogliere le acquisizioni di pacchetti OTA. Si tratta di un ostacolo comune che i tecnici wireless spesso devono affrontare e devono collaborare con il cliente per superarlo in diversi modi. Questo articolo dei forum del supporto Cisco può essere un buon punto di partenza per guidare e formare il cliente a riguardo:
sniffing wireless 802.11 / acquisizione pacchetti
È di fondamentale importanza che le acquisizioni di pacchetti OTA vengano raccolte in un formato di file pcap (*.pcap, *.pcapng, *.pkt,...) e includano metadati 802.11 (RSSI, canale, velocità dei dati,...). Lo sniffer OTA deve inoltre essere sempre tenuto in prossimità del dispositivo client in questione durante le prove, per garantire una prospettiva accurata del traffico inviato e ricevuto dal/dal dispositivo client sottoposto a prova.
Il motivo è che le acquisizioni aggregate di pacchetti con l'uso di questa utility vengono attualmente salvate in un formato di file proprietario e non in un formato di tipo pcap che possa essere visualizzato facilmente in Wireshark o altre utility simili. Assicuratevi che il file di acquisizione dei pacchetti OTA sia in un formato non proprietario, in modo che tutte le parti coinvolte e i fornitori coinvolti possano esaminare rapidamente tutti i file di acquisizione in qualsiasi momento e, in ultima analisi, velocizzare qualsiasi tentativo di risoluzione.
Di seguito sono riportati alcuni metodi comuni per raccogliere un'acquisizione di pacchetti OTA:
- AirPCAP con Wireshark
- MacBook Pro
- OmniPeek Professional, OmniPeek Enterprise,...
- Assistente remoto OmniPeek (ORA)
- Cisco AP in modalità Sniffer
Acquisizioni 802.11n
Per le acquisizioni di pacchetti OTA che coinvolgono client wireless 802.11n, al momento c'è una maggiore flessibilità e facilità d'uso. Ciò è dovuto a una più ampia varietà di adattatori WLAN USB wireless disponibili che possono essere facilmente utilizzati con una serie di strumenti, come OmniPeek e altri.
Prendere nota di come le funzionalità delle schede di rete wireless specifiche utilizzate per raccogliere un'acquisizione OTA 802.11n siano paragonabili a quelle del chipset WLAN effettivamente utilizzato dai dispositivi client che si sta tentando di risolvere. Ad esempio, se il dispositivo client presenta un potenziale problema di interoperabilità wireless che utilizza un chipset 802.11n compatibile con 2 stream spaziali (2SS). Si consiglia quindi di assicurarsi che la scheda di rete wireless utilizzata per raccogliere un pacchetto OTA sia anche una scheda 2S o di livello superiore, con specifiche 802.11n o successive.
Acquisizioni OTA 802.11ac
Per le acquisizioni di 3 stream spaziali (3SS) 802.11ac, potete utilizzare le funzionalità di sniffing nativo di un MacBook Pro modello 2014 o successivo con Mac OS X 10.10.x o superiore. In caso di risoluzione di un dispositivo client 802.11ac a 2 stream spaziali, potete anche utilizzare un MacBook Air per le clip 802.11ac. Il modello Air di MacBooks utilizza chipset WLAN 2SS solo al momento della stesura di questo documento. È possibile fare riferimento all'articolo dei forum di supporto Cisco elencati per istruzioni su come raccogliere le acquisizioni di pacchetti OTA con l'uso di Mac OS X, tramite una varietà di metodi:
Sniffing wireless con Mac OS X 10.6+
È inoltre possibile utilizzare una serie 2702/2802/3702/3802 o un access point simile in modalità sniffer per raccogliere un'acquisizione corretta del pacchetto 802.11ac con 3SS. È inoltre possibile fare riferimento alla risorsa elencata per un elenco aggiornato delle schede di rete wireless 802.11ac disponibili. Alcuni di essi sono potenzialmente in grado di essere utilizzati con strumenti comuni come OmniPeek e altri per raccogliere un pacchetto di acquisizione 802.11ac (chipset da Ralink, Atheros,...):
https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters
È inoltre possibile utilizzare una serie 2702/2802/3702/3802 o un access point simile in modalità sniffer per raccogliere un'acquisizione corretta del pacchetto 802.11ac con 3SS. Per comodità, le istruzioni dettagliate su come configurare un Cisco AP in modalità sniffer e raccogliere un'acquisizione pacchetto OTA sono disponibili nell'articolo dei forum di supporto Cisco:
Per la risoluzione dei problemi di roaming con un dispositivo client wireless, il problema più comune è raccogliere in modo efficace un pacchetto OTA acquisito su più canali. Questo metodo di monitoraggio simultaneo di più canali 802.11 è ottenuto dalla raccolta di pacchetti OTA aggregati. Per ottenere questo risultato, si consiglia di utilizzare più schede WLAN USB compatibili con 802.11ac con un software di analisi di rete compatibile. Alcune comuni schede WLAN USB compatibili con lo standard 802.11ac includono la scheda Savvius WiFI per OmniPeek (802.11ac), Netgear A6210 o simili.
X. Riepilogo
Di seguito è riportato un breve riepilogo delle informazioni da raccogliere per risolvere in modo efficace un potenziale problema di interoperabilità dei client wireless con un CUWN. Se necessario, questa sezione fungerà da sezione di riferimento rapido.
I. Definizione del problema
- Il problema è limitato a uno specifico modello di punto di accesso e/o di tipo radio (2,4 GHz contro 5 GHz)?
- Il problema si verifica solo su una o più versioni specifiche del software WLC (Wireless LAN Controller)?
- Il problema si verifica solo con versioni specifiche di tipi di client e/o software (versione del sistema operativo, versione del driver WLAN, ecc.)?
- Esistono altri dispositivi wireless che non rilevano questo problema? In caso affermativo, quali?
- Il problema è riproducibile quando il client è collegato a un SSID aperto, una larghezza di canale di 20 MHz e 802.11ac disabilitato? (Il problema si verifica solo in modalità 11n rispetto alla modalità 11ac)
- Se il problema non è riproducibile con un SSID aperto, a quale configurazione di protezione minima è associato il problema? (PSK o 802.1X sulla WLAN)
- Quali erano le precedenti versioni software e di configurazione valide?
II. Configurazione WLC e registri
Raccogliere quanto segue dalla CLI del WLC in questione:
- config paging disattivato
- show run-config
In alternativa, è possibile raccogliere solo questi output in base alle esigenze:
- config paging disattivato
- show run-config no-ap
- show wlan apgroups
Backup della configurazione WLC tramite TFTP, FTP,...(GUI: Comandi > Carica file > Configurazione)
Syslog dal WLC
III. Informazioni dispositivo client
- Tipo di client (tablet, smartphone, notebook, ecc.)
- Marca e modello del dispositivo
- Versione del sistema operativo
- Modello scheda WLAN
- Versione driver scheda WLAN
- Supplicant used (Windows Zero Config / Auto Config, Intel PROSet,...)
- Sicurezza configurata per l'utilizzo da parte del client wireless e della WLAN (Open, PSK, EAP-PEAP/MSCHAPv2,...)
IV. Esempio di topologia di rete
Include una rappresentazione e/o dettagli relativi ai dispositivi wireless della rete (stampanti/scanner, WLC, ecc.)
V. Creare un foglio di calcolo per registrare tutti i problemi dei client
Esempio:
| Indirizzo MAC | Username | Descrizione del sintomo segnalato | Ora in cui l'utente finale ha osservato il sintomo | Eseguire il ping del gateway predefinito S/N | Stato del segnale WiFi (connesso/tentativo di connessione) | Record ipconfig /all (o equivalente) |
L'obiettivo di questo esercizio è quello di aiutare a identificare un modello comune e di mostrare un'immagine più accurata del problema o dei problemi in questione.
VI. Comandi Show e Debug sul WLC
Raccogli questi debug WLC tramite la CLI:
- timeout sessioni di configurazione 0
- debug client <indirizzo_MAC>
- debug dhcp message enable
Aggiungere i debug aggiuntivi caso per caso:
- debug aaa detail enable - da utilizzare in caso di problemi di autenticazione con il server AAA
- debug aaa events enable - da utilizzare in caso di problemi di autenticazione con il server AAA
- debug aaa all enable: utilizzare questa opzione per problemi di autenticazione. La versione è dettagliata, quindi utilizzarla solo quando necessario (per casi di override AAA e simili)
- debug mobility handoff - da utilizzare per problemi di roaming tra WLC
Raccogli l'output dei comandi show del WLC dalla CLI:
- config paging disattivato
- show time
- show client detail <mac-address of client> (annotare lo stato del client sul WLC)
- Eseguire il ping del client dal WLC
Al termine del test, usare questo comando per interrompere tutti i debug correnti sul WLC:
- debug disable-all
VII. Mostra ed esegue il debug dei comandi sull'access point
Access point Cisco IOS® leggeri
In questa sezione vengono illustrati in dettaglio i debug richiesti per i modelli serie 1700/2700/3700 o precedenti.
Per evitare il timeout di una sessione AP durante una sessione Telnet/SSH/console, utilizzare i seguenti comandi:
- cli console debug capwap
- config t
- console linea 0 - utilizzare per modificare i parametri di timeout della sessione seriale
- line vty 0 4 - utilizzare per modificare i parametri di timeout della sessione Telnet/SSH
- exec-timeout 0
- session-timeout 0
- termine len 0
Prima di iniziare il test, raccogliere un esempio di questi comandi show sull'access point. Almeno raccogliere due campioni di questo output, sia prima che dopo il completamento dei test con l'uso di questi comandi show dell'access point dalla CLI:
- termine len 0
- show clock
- show tech
- show capwap client mn
- mostra int do1 dfs
- show logging (visualizza registri)
- altro event.log
- show trace dot11_rst formato del tempo di visualizzazione locale
- show trace dot11_rst
- show trace dot11_bcn formato ora di visualizzazione locale
- show trace dot11_bcn
Raccogliere i seguenti debug AP dalla CLI:
- debug dot11 { d0 | d1 } indirizzo monitor <indirizzo_MAC>
- debug dot11 { d0 | d1 } traccia stampa client chiavi mgmt rxev txev rcv xmt txfail
- mon
Al termine del test, usare questo comando per disabilitare i debug:
- u tutto
AP-COS AP
In questa sezione vengono illustrati in dettaglio i debug richiesti per i access point serie 1800/2800/3800.
Per evitare il timeout di una sessione AP durante una sessione Telnet/SSH/console, utilizzare i seguenti comandi:
- exec-timeout 0
Prima di iniziare il test, raccogliere un esempio dei comandi show sull'access point. Almeno raccogliere due campioni di questo output, sia prima che dopo il completamento dei test con l'uso di questi comandi show dell'access point dalla CLI:
- termine len 0
- show clock
- show tech
- show client statistics <indirizzo_MAC_client>
- show cont nss status
- show cont nss stats
- show log
Per i punti di accesso serie 1800, raccogliere i seguenti debug AP dalla CLI:
- debug dot11 client level events addr <indirizzo-MAC_client>
- debug dot11 errori a livello di client addr <indirizzo-MAC_client>
- debug dot11 client level critical addr <indirizzo-MAC_client>
- debug dot11 client level info addr <indirizzo-MAC_client>
- debug dot11 client datapath eapol addr <indirizzo-MAC_client>
- debug dot11 client datapath dhcp addr <indirizzo-MAC_client>
- debug dot11 client datapath arp addr <indirizzo-MAC_client>
- mon
Per i punti di accesso serie 2800/3800, raccogliere i seguenti debug AP dalla CLI:
- config ap indirizzo-traccia-client add <indirizzo-MAC_client>
- abilita tutti i filtri di traccia client dell'access point di configurazione
- config ap client-trace output console-log enable
- avvio traccia client ap di configurazione
- mon
Al termine del test, usare questo comando per disabilitare i debug:
- arresto traccia client ap di configurazione
VIII. Acquisizioni lato client
Raccogliere un pacchetto Netmon 3.4 (solo Windows XP o 7) o Wireshark dalla scheda WLAN del dispositivo client.
IX. Acquisizioni OTA
Acquisizioni 802.11n
- AirPCAP con Wireshark
- MacBook Pro
- OmniPeek Professional, Enterprise,...
- Assistente remoto OmniPeek (ORA)
- Cisco AP in modalità Sniffer
Acquisizioni 802.11ac
- Per le acquisizioni 11ac 3SS, è possibile utilizzare un Macbook Pro 2014 o successivo con 10.10.x o superiore (non utilizzare MacBook Air per le acquisizioni 11ac se possibile, in quanto attualmente è un dispositivo 2SS).
- In modalità sniffer, è possibile usare anche un access point Cisco serie 2702, 3702 o simile.
- Per scenari di roaming e con l'utilizzo di software di analisi di rete professionale come OmniPeek di Savvius. Si consiglia di utilizzare più schede WLAN USB compatibili con lo standard 802.11ac, ad esempio la scheda WiFI Savius per OmniPeek (802.11ac), Netgear A6210 o simili.
XI. Appendice A - Suggerimenti e consigli aggiuntivi
Windows
Raccogliere informazioni aggiuntive relative alla connessione wireless corrente e altri dettagli correlati direttamente da un PC Windows. Dalla riga di comando di Windows (CMD) è possibile usare i seguenti comandi netsh wlan:C:\Users\engineer>netsh wlan show ?
These commands are available:
Commands in this context:
show all - Shows complete wireless device and networks information.
show allowexplicitcreds - Shows the allow shared user credentials settings.
show autoconfig - Shows whether the auto configuration logic is enabled or
disabled.
show blockednetworks - Shows the blocked network display settings.
show createalluserprofile - Shows whether everyone is allowed to create all
user profiles.
show drivers - Shows properties of the wireless LAN drivers on the system.
show filters - Shows the allowed and blocked network list.
show hostednetwork - Show hosted network properties and status.
show interfaces - Shows a list of the wireless LAN interfaces on
the system.
show networks - Shows a list of networks visible on the system.
show onlyUseGPProfilesforAllowedNetworks - Shows the only use GP profiles on GP
configured networks setting.
show profiles - Shows a list of profiles configured on the system.
show settings - Shows the global settings of wireless LAN.
show tracing - Shows whether wireless LAN tracing is enabled or disabled.
C:\Users\engineer>netsh wlan show interfaces
There are 3 interfaces on the system:
Name : Wireless Network Connection 8
Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter #5
GUID : 6beec9b0-9929-4bb4-aef8-0809ce01843e
Physical address : c8:d7:19:34:d5:85
State : disconnected
Name : Wireless Network Connection 4
Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter
GUID : 23aa09d4-c828-4184-965f-4e30f27ba359
Physical address : 48:f8:b3:b7:02:6e
State : disconnected
Name : Wireless Network Connection
Description : Intel(R) Centrino(R) Advanced-N 6200 AGN
GUID : 8fa038f8-74e0-4167-98f9-de0943f0096c
Physical address : 58:94:6b:3e:a1:d0
State : connected
SSID : snowstorm
BSSID : 00:3a:9a:e6:28:af
Network type : Infrastructure
Radio type : 802.11n
Authentication : WPA2-Enterprise
Cipher : CCMP
Connection mode : Profile
Channel : 157
Receive rate (Mbps) : 300
Transmit rate (Mbps) : 300
Signal : 80%
Profile : snowstorm
Hosted network status : Not started
C:\Users\engineer>netsh wlan show networks bssid | more
Interface name : Wireless Network Connection
There are 21 networks currently visible.
SSID 1 : snowstorm
Network type : Infrastructure
Authentication : WPA2-Enterprise
Encryption : CCMP
BSSID 1 : 00:3a:9a:e6:28:af
Signal : 99%
Radio type : 802.11n
Channel : 157
Basic rates (Mbps) : 24 39 156
Other rates (Mbps) : 18 19.5 36 48 54
BSSID 2 : 00:3a:9a:e6:28:a0
Signal : 91%
Radio type : 802.11n
Channel : 6
Basic rates (Mbps) : 1 2
Other rates (Mbps) : 5.5 6 9 11 12 18 24 36 48 54
-- More --
macOS (in precedenza OS X)
Per raccogliere l'output equivalente come comando ipconfig /all su un PC Windows, è possibile usare il comune comando Linux/Unix di ifconfig per elencare le informazioni dettagliate per tutte le interfacce di rete su un MacBook Apple. Se necessario, potete anche specificare di ricevere l'output solo per l'interfaccia wireless nativa per un dato MacBook (en0 o en1, dipende dal modello). Ad esempio:
bash-3.2$ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 14:10:9f:de:df:f3 inet6 fe80::1610:9fff:fede:dff3%en0 prefixlen 64 scopeid 0x4 inet 10.150.128.40 netmask 0xffffe000 broadcast 10.150.159.255 nd6 options=1<PERFORMNUD> media: autoselect status: active
Per ottenere informazioni rapide ma dettagliate relative alla connessione wireless corrente su un MacBook. È inoltre possibile selezionare l'icona WiFi nell'angolo superiore destro del desktop mentre si tiene contemporaneamente premuto il pulsante di opzione sulla tastiera, come mostrato nell'immagine.
Un'altra opzione utile è quella di utilizzare l'utilità della riga di comando nascosta chiamata aeroporto. Si consiglia di utilizzarlo solo con il proprio MacBook o con uno in uso in un ambiente di emulazione. Poiché alcuni amministratori di rete potrebbero non voler concedere l'accesso a questa utility sul MacBook di un utente finale, è necessario prestare la dovuta attenzione. Per continuare, immettere quanto segue in Terminale sul MacBook in questione:
sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport
Ora è possibile utilizzare l'utility CLI dell'aeroporto con facilità. Di seguito è riportato un esempio:
bash-3.2$ airport -I
agrCtlRSSI: -61
agrExtRSSI: 0
agrCtlNoise: -90
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 216
maxRate: 300
lastAssocStatus: 0
802.11 auth: open
link auth: wpa2
BSSID: 0:3a:9a:e6:28:af
SSID: snowstorm
MCS: 13
channel: 157,1
Per facilitare ulteriormente il processo di raccolta di un'affidabile, singola acquisizione di pacchetti OTA a 802.11 canali con l'uso delle funzionalità di un MacBook Pro o simili. È possibile utilizzare le funzionalità incorporate in macOS con il metodo Diagnostica wireless > Sniffer o simili, ma è possibile utilizzare anche un'utilità di terze parti chiamata Airtool (OS X 10.8 e versioni successive). Il vantaggio è un'interfaccia semplice per raccogliere rapidamente un pacchetto OTA acquisizione, che viene salvato direttamente sul desktop con pochi clic attraverso l'interfaccia utente dell'app direttamente dalla barra dei menu superiore sullo schermo.
Ulteriori informazioni e link per il download di Airtool sono disponibili al seguente indirizzo:
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
14-Feb-2023 |
Certificazione |
1.0 |
14-May-2016 |
Versione iniziale |
Feedback