<< Torna agli Approfondimenti Tematici


Rodolfo Trippetti
Wireshark: un esempio semplice di troubleshooting


Istruttore certificato con una lunga esperienza nella formazione ICT. VMware Certified Instructor (VCI), VMware Certified Professional (VCP), Cisco Certified Systems Instructor (CCSI), Cisco Certified Network Professional R&S (CCNP), Microsoft Certified Trainer (MCT), Microsoft Certified Systems Engineer (MCSE)


Introduzione

L'analisi del traffico di rete è sempre un'esperienza didattica e professionale estremamente interessante sia per chi si occupa di networking puro che per chi lavora nell'ambito della sicurezza o gestisce e supporta applicativi distribuiti o client-server. Per di più è un'esperienza che può essere fatta attraverso l'utilizzo di tools open source ormai da tempo disponibili in rete. Di questi Wireshark è probabilmente il più popolare e sicuramente è tra quelli che hanno raggiunto un buon grado di maturazione. La sua storia è stata scritta in parte anche in Italia all'inizio degli anni 2000 da Loris Degioanni, a quel tempo uno studente del Politecnico di Torino. La sua tesi di dottorato produsse la prima versione della libreria WinPcap, un porting su Windows della libreria Libcap di Unix (per i dettagli si può leggere l’articolo http://www.winpcap.org/docs/WinPcap-AICA03.pdf oppure http://www.winpcap.org/docs/iscc01-wpcap.pdf). Si tratta attualmente di un componente fondamentale di Wirshark su sistema operativo Windows in quanto è proprio quello che consente la cattura del traffico di rete. Lo sviluppo di questo software e il suo successivo rilascio in rete come open source hanno fatto la fortuna di Loris Degioanni che ora vive e lavora negli Stati Uniti. La sua storia, un interessante esempio di quella "fuga dei cervelli" di cui si parla ormai quotidianamente, è ampiamente documentata sulla rete.

Dal punto di vista funzionale Wireshark si compone di due elementi principali: il componente di cattura e quello di analisi, i quali possono essere installati separatamente e indipendentemente l'uno dall'altro. Per il componente di cattura gioca un ruolo essenziale proprio la WinPcap già citata in precedenza. Per il componente di analisi, oltre alla GUI e ai suoi strumenti di elaborazione (filtri, coloring, funzioni statistiche, ecc.) risulta fondamentale la sua capacità di riconoscere protocolli, cioè di interpretare e visualizzare correttamente le diverse strutture di pacchetto presenti nel tracciato (packet dissection). L'elenco dei protocolli e dei tipi di pacchetto riconosciuti da Wireshark è veramente lunghissimo, oltre 1500, ben maggiore di quello che un tecnico ha normalmente presente o con cui potrebbe solitamente avere a che fare, e costituisce certamente un punto di forza del prodotto.

Attualmente Wireshark è messo a disposizione come software open source sul sito http://www.wireshark.org dalla Riverbed Technologies che lo usa come base per commercializzare una serie di prodotti di supporto e di estensione delle funzionalità. Viene regolarmente aggiornato attraverso il costante lavoro di sviluppo garantito da una comunità di alcune centinaia di sviluppatori che si riuniscono allegramente una volta l'anno a Standford in occasione della cosiddetta SharkFest (http://sharkfest.wireshark.org/). Negli ultimi anni è stata anche fondata la Wireshark University con lo scopo di creare un curriculum di studi con relativa certificazione professionale, la Wireshark Certified Network Analyst, WCNA (https://wcnaportal.com).

Fast Lane – GKI supporta i tecnici e gli amministratori di rete nella costruzione di un know-how su Wireshark attraverso una formazione proprietaria costruita sugli obiettivi della certificazione professionale (vedi le indicazioni alla fine dell’articolo).

Il tracciamento del traffico di rete può essere utile per tantissimi motivi. Anzitutto ci può dare l'opportunità di fare il troubleshooting di un problema, probabilmente la cosa più interessante e utile in qualunque ambiente operativo. Ma di grande utilità può essere anche analizzare i dettagli di un protocollo noto, capire quali e quanti protocolli passano in un canale di rete, fare statistiche su vari parametri (indirizzi, protocolli, connessioni, flussi TCP, ecc.). Oppure semplicemente approfondire la conoscenza del networking. In questo articolo commenterò un esempio molto semplice di troubleshooting.


Descrizione del problema.

Alcune webcam possono registrare mandando direttamente i file di registrazione in una share di windows, utilizzando il protocollo SMB su porta tcp 445 (CIFS). Utilizzando una di queste webcam ho verificato il seguente problema: appena fornite le impostazioni alla telecamera per puntare alla share di windows predisposta su un server tutto funziona bene per un po', poi ad un certo punto la webcam perde la share e non la riaggancia più. Da quel momento in poi tutti i test falliscono. Nessun motivo apparente sembra causare il malfunzionamento.


Tracciamento del traffico prodotto dalla webcam.

Durante il test la webcam manda un file di testo alla share in cui c'è semplicemente scritta la data e l'ora del test. Non avendo altre informazioni significative da parte del dispositivo ho deciso di catturare con wireshark il traffico prodotto verso il server Windows durante il test che falliva. La parte interessante del tracciato è visibile in figura 1.


Figura 1


Se si va nel menù delle funzioni statistiche di Wireshark e si chiama la funzione Conversation si ottiene un report visualizzato in una finestra specifica nella quale si possono osservare tutti i flussi TCP presenti. La finestra è riportata in figura 2.


Figura 2


Questi flussi risultano tutti molto brevi, ciascuno una dozzina di pacchetti e trasportano tutti il protocollo SMB. Se andiamo ad analizzare uno di questi flussi (ne vediamo uno in figura 1) riconosciamo all'inizio i tre pacchetti di handshake che aprono la sessione TCP 445 (microsoft-ds) tra la webcam e il server. Successivamente individuiamo due pacchetti di negoziazione del protocollo SMB, un semplice ACK del flusso, e quindi altri due pacchetti SMB di cui l'ultimo (la risposta del server alla webcam) riporta il messaggio di errore il cui testo visualizzato nel campo Info è Error: Out of Memory. A questo punto il dialogo si interrompe e dopo un ACK i due host fanno lo shutdown della sessione TCP, il server addirittura mandando un Reset (RST). Andando a vedere i dettagli del pacchetto di errore leggiamo anche il messaggio Error Class: DOS Error (figura 3). Il tracciato ci mostra una serie di questi tentativi di dialogo tra la webcam e il server, tutti interrotti dallo stesso errore del server.


Figura 3



Soluzione del problema.

Come ci potevamo aspettare abbiamo evidenziato un malfunzionamento a livello applicativo, molto probabilmente imputabile al server SMB piuttosto che alla webcam. Sappiamo bene però che i protocolli applicativi sono in genere molto complessi, è difficile conoscerne in dettaglio le implementazioni e quindi la loro corretta interpretazione risulta quasi sempre impossibile, a meno che non si riesca a reperire documentazione specifica in merito. Fortunatamente esiste Internet che in questi casi, essendo un pozzo di errori documentati da cui attingere, riesce a fornirci la risposta.

La prima fonte trovata sembra descrivere un problema analogo (anche se non riferito all'uso di una webcam) e la descrizione della sua risoluzione recita grosso modo così:

"Set the following registry key to ‘1’: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\MemoryManagement\LargeSystemCache

and set the following registry key to ‘3’: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size

After making these changes and restarting, I haven’t seen this issue arise again. Fixed!"

Sebbene effettivamente questo sia risolutivo vale la pena in questi casi indagare ulteriormente per trovare oltre che una soluzione anche una sua logica spiegazione o quantomeno una descrizione più completa e ragionata del problema. Con un po' di pazienza si trova in rete uno stralcio di un vecchio articolo di Microsoft che rende ragione del problema in cui sono incappato. Ne riporto il pezzo più importante nella figura 4. Nel capoverso visualizzato si parla di tuning di un sistema Windows e vengono riportati esattamente le stesse due chiavi di registry scritte sopra. In fondo è presente una tabella con tutte le coppie di parametri inseribili nelle due chiavi. Le scelte possibili ottimizzano le risorse di memoria del sistema operativo in funzione dell'attività a cui è dedicato. Quelli che ci interessano li troviamo nella terza riga in corrispondenza della dicitura File Sharing. Poco prima lo stesso frammento di articolo accenna alla possibilità di trovare questi parametri anche sull'interfaccia grafica (sono i parametri di controllo del servizio Server) dove la voce descrittiva che ci interessa è ancora più chiara: Maximize Usage for File Sharing.


Figura 4


Evidentemente le impostazioni di default di Windows forniscono dei buffer di memoria per il servizio Server (quello che condivide le risorse) che risultano insufficienti per l'attività di registrazione della webcam. La soluzione infatti è semplicemente quella di estenderli. Non a caso Wireshark riporta un possibile "DOS Error" nell'ultimo pacchetto SMB di risposta del server, come abbiamo visto nella figura 3, infatti il DOS (Denial Of Service) è proprio un attacco di saturazione dei buffer di memoria di un qualche servizio.

La modifica dei parametri nelle due chiavi di registry indicate nella documentazione risolve il problema. La webcam non interrompe più bruscamente la sua attività di registrazione e i test vengono eseguiti tutti correttamente. L'esempio descritto, effettivamente molto semplice, ha il pregio di mostrare che Wireshark è in grado di fornirci delle informazioni preziose che seppure non ci chiariscono subito il problema almeno ce lo individuano. Se tali informazioni poi riescono ad essere usate come indizi per una paziente ricerca su Internet, ci possono portare sia alla sua soluzione sia, dettaglio non trascurabile, alla sua comprensione.[/div]

Clicca sul nome della città o su "Online Training" per effettuare l'iscrizione. Schedulazione PAW
Italia
Online Training Fuso orario: Central European Summer Time (CEST) Lingua Corso: Italiano
Milano
Questo è un corso FLEX, erogato sia in aula che in remoto, contemporaneamente.
Schedulazione APAW
Italia
Online Training Fuso orario: Central European Summer Time (CEST) Lingua Corso: Italiano
Milano
Questo è un corso FLEX, erogato sia in aula che in remoto, contemporaneamente.
Schedulazione PAPW
Italia
Online Training Fuso orario: Central European Summer Time (CEST) Lingua Corso: Italiano
Milano
Questo è un corso FLEX, erogato sia in aula che in remoto, contemporaneamente.

Contattaci

Contattaci per qualsiasi ulteriore informazione, saremo lieti di rispondere alle tue domande e di supportarti nella definizione dei tuoi piani formativi! Puoi raggiungerci telefonicamente al numero +39 02 255081 oppure compilando il modulo di contatto.