A Francesco che in fondo non ha mai smesso di credere in me

A Francesco
che in fondo non ha mai smesso di credere in me
Introduzione
Attualmente il panorama delle comunicazioni e’ in continua evoluzione.
La presenza di reti wireless e’ in aumento sul territorio e la tecnologia VoIP
vede sempre piu’ applicazioni sia dal punto di vista lavorativo che personale.
La possibilita’ di un utilizzo combinato di queste due tecnologie e’ resa
complicata dalla presenza di due fattori concorrenti. L’elevata perdita di
pacchetti insita nelle reti Wi-Fi1 e l’utilizzo di un protocollo inaffidabile2
come UDP3 da parte del VoIP.
Il nostro scenario ipotetico vede un dispositivo mobile come un PDA
(Personal Digital Assistant, computer palmare) connesso ad un Access Point
wireless fisso, e la possibilita’ di spostamento nello spazio senza perdita di
connettivita’ a patto di copertura del percorso.
Questa comunicazione avviene attraveso lo scambio di informazioni. Il dispositivo mobile invia all’AP i dati di interesse, e a sua volta l’AP comunica
l’avvenuta ricezione (Acknowledgement).
Il problema nasce dal fatto che il device wireless utilizzato per la trasmissione non comunica all’applicazione l’avvenuta ricezione degli acknowledgement.
Il nostro studio si pone come obiettivo la valutazione della possibilita’ di
riportare in userspace le informazioni sulla avvenuta ricezione da parte del
1
Wi-Fi, abbreviazione di Wireless Fidelity. Termine che indica dispositivi che possono
collegarsi a reti locali senza fili (WLAN) basate sulle specifiche IEEE 802.11
2
Un protocollo per la trasmissione di dati si dice inaffidabile se non gestisce il
riordinamento dei pacchetti ne’ la ritrasmissione di quelli persi.
3
User Datagram Protocol (UDP) e’ uno dei principali protocolli utilizzati in Internet.
i
ii
INTRODUZIONE
prime hop (Access Point nel nostro caso) di un frame 802.11 per garantire
un controllo di flusso. Questo avverra’ grazie alla gestione interattiva dello
stream di dati UDP mediante un meccanismo cross-layer che raccolga ed
elabori le informazioni necessarie.
Questa tesi e’ stata sviluppata in coppia con Giulio Grassi, collega laureando in Informatica. Data la complessita’ dell’argomento, le modifiche allo
stack di rete presente nel kernel di linux sono state apportate utilizzando
una sorta di extreme programming4 . Per quanto riguarda i dettagli relativi
all’interazione tra stack di rete e driver, le modifiche sono state seguite dalla
sottoscritta. La parte riguardante l’interazione con le applicazioni e’ stata
seguita dal collega Giulio Grassi.
Di seguito una panoramica del documento.
Primo capitolo : viene fatta una panoramica della realta’ in cui si agisce,
soffermandosi sulla tecnologia wireless, sui vari protocolli di comunicazione che costituiscono la gerarchia ISO OSI e sui tipi di crittografia
piu’ comuni al momento, WEP e WPA.
Secondo capitolo : si trova un’esposizione dei nostri obiettivi e le possibili
strade per la risoluzione dei problemi riscontrati, vi e’ inoltre un’analisi
dei dispositivi utilizzati per fare prove empiriche e test.
Terzo capitolo : e’ presente la trattazione dei problemi riscontrati ben
dettagliati e delle modifiche da attuare.
Quarto capitolo : si ha la spiegazione in dettaglio del meccanismo realizzato.
Quinto capitolo : vengono portati a sostegno del nostro lavoro una serie
di test effetuati per valutare meglio il meccanismo realizzato indicando
inoltre i limiti.
4
L’Extreme Programming e’ una metodologia agile e un approccio all’ingegneria del
software. Tra gli aspetti caratteristici vi sono la programmazione a piu’ mani e la verifica
continua del programma durante lo sviluppo per mezzo di programmi di test.
INTRODUZIONE
Sesto capitolo : si trovano una serie di possibili sviluppi futuri.
iii
Indice
Introduzione
i
1 Scenario
1
1.1
Contesto della ricerca . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Tecnologia Wireless 802.11 . . . . . . . . . . . . . . . . . . . .
4
1.3
Dispositivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.1
Access Point . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.2
Schede di rete wireless . . . . . . . . . . . . . . . . . .
7
1.4
1.5
Layer e protocolli . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1
Stack di rete . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.2
Livello Data Link (livello 2 del modello OSI) . . . . . . 11
1.4.3
Livello Network (livello 3 del modello OSI) . . . . . . . 15
1.4.4
Livello Trasporto (livello 4 del modello OSI) . . . . . . 19
1.4.5
Livello Applicazione (livello 7 del modello OSI) . . . . 21
Crittografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.5.1
WEP - Wired Equivalent Privacy . . . . . . . . . . . . 27
1.5.2
WPA e WPA2 - WiFi Protected Access . . . . . . . . . 29
2 Obiettivi e sperimentazione
2.1
2.2
31
Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.1
Ack dal prime hop e interattivita’ . . . . . . . . . . . . 31
2.1.2
Crittografia . . . . . . . . . . . . . . . . . . . . . . . . 33
Sperimentazione . . . . . . . . . . . . . . . . . . . . . . . . . . 34
v
vi
INDICE
3 Parte tecnica
3.1
Intel PRO/Wireless 3945ABG . . . . . . . . . . . . . . . . . . 39
3.1.1
3.2
Analisi driver iwl3945 . . . . . . . . . . . . . . . . . . . 39
Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.1
UDP over IPv6 . . . . . . . . . . . . . . . . . . . . . . 53
3.2.2
UDP over IPv4 . . . . . . . . . . . . . . . . . . . . . . 54
4 Realizzazione-Implementazione
4.1
55
Funzionamento dell’applicazione . . . . . . . . . . . . . . . . . 55
4.1.1
Spiegazione generale . . . . . . . . . . . . . . . . . . . 55
4.1.2
Approfondimento: lato trasmissione . . . . . . . . . . . 56
4.1.3
Approfondimento: lato ricezione . . . . . . . . . . . . . 61
4.1.4
Utilizzo applicazione . . . . . . . . . . . . . . . . . . . 63
5 Valutazione
5.1
37
67
Metriche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.1
Parametri . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2
Scenario sperimentale . . . . . . . . . . . . . . . . . . . . . . . 68
5.3
Prove e risultati . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.1
5.4
Esecuzione test . . . . . . . . . . . . . . . . . . . . . . 69
Discussione risultati . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.1
Prove . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.4.2
Affidabilita’ . . . . . . . . . . . . . . . . . . . . . . . . 77
5.4.3
Ritardi . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6 Sviluppi Futuri
81
6.1
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2
DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3
Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.4
IEEE 802.11r . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.5
Kernel Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7 Conclusioni
85
Elenco delle figure
1.1
Hot Spot Fon a Bologna (maps.fon.com) . . . . . . . . . . . .
2
1.2
Meccanismo di interazione . . . . . . . . . . . . . . . . . . . .
3
1.3
Nodo nascosto . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4
Frame 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5
Struttura ACK Frame . . . . . . . . . . . . . . . . . . . . . . 15
1.6
Header del pacchetto IP . . . . . . . . . . . . . . . . . . . . . 17
1.7
Header del pacchetto UDP . . . . . . . . . . . . . . . . . . . . 21
2.1
Modifiche cross-layer . . . . . . . . . . . . . . . . . . . . . . . 33
3.1
Panoramica meccanismo cross-layer . . . . . . . . . . . . . . . 38
3.2
Struttura IPv6 Header . . . . . . . . . . . . . . . . . . . . . . 53
5.1
Riassunto Generale . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2
WEP multisessione . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3
WPA multisessione . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4
Andamento ritardi singola prova . . . . . . . . . . . . . . . . . 76
vii
Elenco delle tabelle
1.1
Codice protocolli Transport Level . . . . . . . . . . . . . . . . 18
3.1
Comandi iwl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1
Ritardi medi risposte applicazione . . . . . . . . . . . . . . . . 73
ix
Capitolo 1
Scenario
Oggi, in Italia e nel mondo, girando per le citta’ e’ possibile avere accesso
a reti wireless protette e non. Grazie a questo e mediante alcuni accorgimenti
e’ possibile rimanere sempre connessi alla rete.
Una rete LAN wireless (WLAN - wireless local area network) consiste in
una rete formata da due o piu’ computer o dispositivi connessi senza l’utilizzo
di cavi. Essa utilizza tecnologie di trasmissione mediante onde radio come
quella a espansione di spettro oppure la OFDM1 . La tecnologia permette
comunicazioni in un area limitata, consentendo mobilita’ all’interno di essa
senza perdere l’accesso alla rete.
In un contesto privato, le reti senza fili hanno avuto un massivo utilizzo
grazie alla facilita’ di installazione e alla crescente diffusione di portatili e
palmari. Alcuni tipi di esercizi come coffee-shop o centri commerciali hanno
iniziato ad offrire questo tipo di servizio ai clienti. Nelle citta’ sono nati progetti per piccole reti pubbliche, per esempio quelle di biblioteche e universita’,
oppure grandi reti civiche che coprono le vie del centro2 .
1
Orthogonal Frequency-Division Multiplexing (OFDM), tra le tecnologie per la tele-
comunicazione, e’ un tipo di modulazione di tipo multi-portante che utilizza un numero
elevato di sottoportanti ortogonali tra di loro.
2
A Bologna per esempio troviamo la Rete Civica Iperbole (www.comune.bologna.it)
1
2
1. Scenario
1.1
Contesto della ricerca
Lo studio riguarda la mobilita’ mediante connettivita’ wireless in un ambiente vasto (per esempio una citta’). Per fare questo e’ necessario avere una
copertura globale dell’area, anche attraverso varie reti differenti, e accesso a
tutti gli hot spot presenti lungo il percorso.
Figura 1.1: Hot Spot Fon a Bologna (maps.fon.com)
Precisamente la ricerca risponde all’esigenza di avere un’interazione effettiva con il flusso dei dati in un contesto UDP. Il protocollo UDP e’ di tipo
senza connessione e non permette di avere informazioni riguardanti la sorte
dei pacchetti inviati. L’utilizzo di questo protocollo viene imposto dal tipo
di servizio che si vuole sfruttare; nel nostro caso la scelta del protocollo VoIP
ha reso necessario affrontare il problema.
Grazie ad una maggiore padronanza del sistema, lo studio e’ stato svolto
in ambiente Linux, e data la sua durata vi e’ stato il passaggio dalla versione
del kernel 2.6.23.x alla 2.6.25.x. La disponibilita’ dei sorgenti di kernel e
driver hanno reso la scelta alquanto immediata.
1.1 Contesto della ricerca
Data la facile reperibilita’ e la grande diffusione delle porte USB in quasi
tutti i dispositivi mobili, la preferenza e’ andata alle schede WNIC3 USB.
Il nostro scopo e’ fornire il maggior numero di informazioni possibili
riguardanti la sorte dei pacchetti trasmessi. Per poterlo fare lavoreremo all’interno dello stack di rete implementando un servizio cross-layer utilizzabile
in userspace.
Figura 1.2: Meccanismo di interazione
Per capire quali sono i servizi presenti e le problematiche da affrontare e
risolvere, di seguito si trovano le spiegazioni dei dispositivi e dei protocolli
utilizzabili.
3
Wireless Network Interface Controller
3
4
1. Scenario
1.2
Tecnologia Wireless 802.11
Standard Lo IEEE802.11 [3, 4] o Wi-Fi definisce uno standard per le reti
WLAN sviluppato dal gruppo 11 dell’IEEE 802. Qua’ viene definito il livello
fisico e MAC del modello ISO-OSI4 e specificata sia l’interfaccia tra client e
access point che quella tra piu’ client.
All’interno della famiglia, i protocolli dedicati alla trasmissione delle informazioni sono a, b e g. Gli altri standard, cioe’ c, d, e, f, h, ecc. riguardano
estensioni dei servizi base e miglioramenti di servizi gia’ disponibili. Il primo
protocollo largamente diffuso e’ stato il b; in seguito si sono diffusi il protocollo a e soprattutto il protocollo g. La sicurezza e’ stata inclusa in uno
standard a parte, l’802.11i.
L’802.11b e 802.11g utilizzano lo spettro di frequenze (banda ISM5 ) relativo ai 2,4 GHz. E’ importante tenere in considerazione che trovandosi ad
operare su bande con frequenze gia’ utilizzate da altri apparecchi, i dispositivi
b e g possono essere influenzati da telefoni cordless, ripetitori audio/video per
distribuire programmi televisivi satellitari oppure altri apparecchi all’interno
di un appartamento che utilizzino la banda di frequenze sopacitata.
L’802.11a utilizza la banda ISM dei 5,8 GHz.
Sicurezza Per quanto riguarda la sicurezza, le versioni originali dei protocolli 802.11 erano basati sulla crittografia WEP (Wired Equivalent Privacy). Nel 2001 un gruppo dell’universita’ di Berkeley presento’ uno studio
nel quale descriveva le falle di sicurezza del protocollo 802.11. Il gruppo si
4
Open Systems Interconnection Basic Reference Model (OSI Reference Model) e’ una
descrizione a livelli di astrazione dei protocolli e dell’implementazione delle comunicazioni
in una rete di computer.
5
Banda ISM (Industrial, Scientific and Medical) e’ il nome assegnato dall’Unione Internazionale delle Telecomunicazioni (ITU) ad un insieme di porzioni dello spettro elettromagnetico riservate alle applicazioni radio non commerciali, per uso industriale, scientifico
e medico.
1.2 Tecnologia Wireless 802.11
concentro’ sull’algoritmo di cifratura utilizzato dal WEP (RC46 ), che nell’implementazione scelta per lo standard 802.11 era molto debole e facilmente
forzabile. Per ovviare al problema l’IEEE si mise al lavoro per progettare
un’evoluzione dello standard. Contemporaneamente anche la Wi-Fi Alliance
cerco’ una soluzione al problema. Per questo nel 2003 Wi-Fi Alliance annuncio’ la nascita del WPA e nel giugno del 2004 l’IEEE rilascio’ le specifiche
dell’IEEE 802.11i. Il nuovo standard rendeva le reti wireless molto sicure e
la Wi-Fi Alliance lo adotto’ subito sotto il nome di WPA2. Il WPA2 abbandona l’RC4 come algoritmo di codifica per passare al piu’ sicuro Advanced
Encryption Standard.
Le varie opzioni di sicurezza disponibili comportano livelli di complessita’
crescente per la configurazione e l’adeguamento dei firmware e dei driver di
AP e schede di rete wireless.
In ambito privato sono di solito disponibili minori competenze, per cui
capita di trovare reti wireless non crittate o che al massimo utilizzino la
WEP. Queste reti sono insicure e possono essere forzate con semplicita’,
permettendo l’intercettazione del traffico wireless e l’accesso abusivo alla rete.
Vantaggi Molte reti riescono a fornire la cifratura dei dati e il roaming
potendosi spostare dalla copertura di un access point ad un altro senza una
caduta della connessione internet al di fuori del raggio di azione che delimita
un hot-spot.
Diversamente dal cellulare, l’esistenza di uno standard certificato garantisce l’interoperabilita’ fra apparecchio e rete anche all’estero.
Senza i costi della cablatura (essendo tecnologia wireless) si ha una rapida
e facile installazione (ed espansione successiva) della rete.
La presenza di parecchi produttori ha creato una notevole concorrenza
abbassando di molto i prezzi iniziali di questa tecnologia.
6
RC4 o Rivest Cipher 4 e’ un algoritmo di cifratura progettato da Ron Rivest della
RSA Security nell’anno 1987.
5
6
1. Scenario
Svantaggi Il tempo di latenza delle schede wireless e’ superiore a quelle
basate su cavo con una latenza massima nell’ordine di 1-3 ms (da notare che
le connessioni GPRS/UMTS hanno latenze nell’ordine di 200-400ms).
Uno svantaggio delle connessioni Wi-Fi 802.11a/g si trova nella stabilita’
del servizio che per via dei disturbi sul segnale talvolta puo’ essere discontinuo. Infatti questo puo’ essere disturbato da forni a microonde, telefoni
cordless (ecc.) nelle vicinanze che quando sono in funzione disturbano la
frequenza operativa di 2,4-2,5 GHz.
Da non trascurare il fatto che secondo alcuni recenti studi, scienziati affermati dichiarano che le radiazioni Wi-Fi sono nocive al nostro organismo[5,
6, 7, 8].
1.3
1.3.1
Dispositivi
Access Point
Un Access Point e’ un dispositivo che permette all’utente mobile di collegarsi ad una rete wireless. Questo, collegato fisicamente ad una rete cablata
(oppure via radio ad un altro access point), riceve ed invia un segnale radio
al client, permettendo cosi’ la connessione. Un AP puo’ avere varie modalita’
di funzionamento.
Root Mode E’ la modalita’ classica di funzionamento dell’AP, ovvero
quando esso e’ collegato alla rete cablata e funziona da punto di accesso
per i nodi mobili wireless (Laptop, Cellulari, Palmari, ecc.)
Bridge Mode Consiste nalla creazione di un link wireless tra due (pointto-point) o piu’ (point-to-multipoint) access point. Tipicamente quando un
access point funziona in bridge mode non svolge la funzione di root, anche se alcuni costruttori permettono questa possibilita’ di funzionamento in
contemporanea.
1.3 Dispositivi
Repeater Mode Consente di aumentare il raggio di copertura di una rete
wireless. Questo riduce drasticamente il troughput.
1.3.2
Schede di rete wireless
Un controller di rete wireless (WNIC - Wireless network interface controller) e’ una scheda di rete che permette ad un computer di utilizzare una
infrastruttura di rete non cablata. Questa lavora ai primi due livelli del modello ISO-OSI. Il dispositivo utilizza un’antenna e la comunicazione avviene
attraverso le microonde.
Funzionamento Esistono due essenziali modalita’ di funzionamento, conosciute come infrastruttura e ad-hoc.
Nel modello a infrastruttura e’ necessaria la presenza di un AP. Questo
gestira’ tutto il trasferimento dei dati e si comportera’ da hub centrale. In
questa modalita’ tutti i client devono essere connessi all’AP con lo stesso
SSID (service set identifier). In caso di cifratura devono essere a conoscenza
della chiave oppure di un mezzo per l’autenticazione.
In una rete ad-hoc non e’ necessario un AP poiche’ ogni dispositivo puo’
interfacciarsi direttamente con gli altri nodi della rete. Anche in questo caso
tutti i client devono essere impostati con lo stesso SSID sullo stesso canale.
Le schede di rete utilizzano le specifiche IEEE 802.11. Vecchi dispositivi utilizzano standard antiquati, quelli recenti permettono sia l’utilizzo di
standard attuali che la retrocompatibilita’.
E’ importante notare che il range del dispositivo varia in base all’ambiente circostante (ostacoli presenti nell’area) e alla qualita’ dell’antenna. Le
fonti ambientali che influiscono sul funzionamento sono soprattutto quelle
elettriche (frigoriferi, contatori, ecc.) oppure veri e propri ostacoli strutturali
(muri, gabbie metalliche, ecc.)
La velocita’ massima di trasferimento si puo’ ottenere solo se realmente
vicini alla fonte della trasmissione. I dispositivi negoziano dinamicamente la
velocita’ di trasmissione per minimizzare la perdita di pacchetti (e quindi i
7
8
1. Scenario
tentativi di ritrasmissione).
In un desktop computer una WNIC e’ solitamente connessa mediante il
bus PCI, ma esistono alternative come USB, PC Card e soluzioni integrate
come Mini PCI e PCI Express Mini.
Dispositivi USB
L’Universal Serial Bus e’ uno standard di comunicazione seriale che consente di collegare diverse periferiche ad un computer. Progettato per consentire a piu’ periferiche di essere connesse usando una sola interfaccia standardizzata ed un solo tipo di connettore, permette l’hot plug7 .
I device USB WNIC sono di facile reperibilita’ e semplici da utilizzare.
Spesso le loro caratteristiche non li inseriscono al top della categoria, ma
hanno vantaggi non trascurabili. Primo fra tutti, mediante una prolunga
USB e’ possibile spostare il device per ottenere una ricezione migliore. In
effetti in un ambiente chiuso la ricezione varia anche solo spostandosi di un
metro8 .
Dispositivi PCMCIA
Si definisce PCMCIA9 la porta o il dispositivo nato per l’espansione delle
funzionalita’ dei computer portatili. Lo standard delle PC Card nasce nel
1991 dalla fusione dei due standard JEIDA10 4.1 e PCMCIA 2.0.
Originariamente le PC Card furono pensate come slot di espansione per
la memoria dei portatili, successivamente nello stesso formato vennero creati
7
Si dice hot plug un’interfaccia che permette il collegamento e/o lo scollegamento di
un dispositivo anche a sistema avviato
8
Mobili, porte e pareti modificano la diffusione delle onde elettromagnetiche. In una
casa la ricezione peggiora anche solo spostandosi di qualche metro, questo dovuto anche
alla qualita’ dei dispositivi utilizzati per uso personale
9
Personal Computer Memory Card International Association, associazione che
sviluppo’ il primo dispositivo.
10
Le JEIDA sono memory card giapponesi precedentemente diffuse a quelle PCMCIA
1.3 Dispositivi
svariati dispositivi come schede di rete, modem e hard disk. E’ da notare che
la funzionalita’ originaria e’ andata in disuso.
Esistono tre formati di PC Card e vari accessori per l’estensione di esse.
Tutti i tipi hanno la stessa dimensione e numero di pin (68), la differenza
sta nello spessore, rispettivamente 3.3mm, 5.0mm, e 10.5mm11 . Mediante la
variazione di spessore e’ possibile ottenere device PCMCIA conteneti componenti di grosse dimensioni, e grazie alle estensioni le card possono sporgere
dal connettore, permettendo per esempio ad un antenna wireless di essere
esposta.
Dispositivi Mini PCI e PCI Express Mini
Mini PCI e’ un bus standard che permette di connettere dispositivi periferici al computer. E’ un’evoluzione del PCI bus (Peripheral Component
Interconnect) progettato per computer portatili e altri dispositivi di piccole
dimensioni.
PCI Express Mini Card e’ l’evoluzione dell’ interfaccia PCI Express
usando il bus Mini PCI. Sviluppata da PCI-SIG12 , l’interfaccia supporta
connettivita’ PCI Express, USB 2.0 e Firewire. Ogni device puo’ scegliere
l’interfaccia che ritiene piu’ appropriata al suo scopo.
I device WLAN con queste connessioni sono quelli integrati nei laptop.
11
12
Da notare la possibilita’ di utilizzare card sottili in slot spessi.
Il PCI-SIG o Peripheral Component Interconnect Special Interest Group e’ un gruppo
responsabile delle specifiche degli standard dei bus Peripheral Component Interconnect
(PCI), PCI-X, and PCI Express (PCIe).
9
10
1. Scenario
1.4
Layer e protocolli
1.4.1
Stack di rete
Perche’ una infrastruttura di rete possa funzionare in modo corretto ed
efficacie, e’ necessaria una strutturazione dettagliata del software che la deve
gestire. Per ridurne la complessita’, quasi tutte le reti sono gestite da una
struttura gerarchica di livelli (ognuno creato sulla base del livello sottostante)
che astraggono e risolvono i problemi presenti. Numero, nome e caratteristiche dei livelli varia da rete a rete, comunque sia, ogni livello utilizza i servizi
forniti dal layer sottostante per offrire ulteriori servizi al layer superiore[1, 2].
Questo principio e’ comunemente utilizzato nell’informatica e si basa sulla
possibilita’ di trattare ogni layer come una black box, potendolo utilizzare
semplicemente conoscendone l’interfaccia e il formato dell’informazione in
uscita dopo l’elaborazione.
Tra due postazioni la comunicazione avviene per livelli, cioe’ un dato livello nella macchina A comunichera’ con il livello corrispondente nella macchina
B. Le regole e le convenzioni utilizzate in questa comunicazione vengono definite come il protocollo del layer. La violazione di questi protocolli rende la
comunicazione difficile se non impossibile.
In mezzo ad ogni coppia di livelli adiacenti e’ presente un’interfaccia.
Vengono definite le operazioni e i servizi forniti dal livello sottostante a quello
superiore. Oltre a minimizzare la quantita’ di informazioni necessarie per la
comunicazione, rende possibile la modifica integrale dell’implementazione di
un livello (mantenendo ovviamente intatta l’interfaccia) senza farlo sapere ai
livelli adiacenti.
La specifica di questa infrastruttura deve contenere tutte le informazioni
che permettano la creazione di essa dal punto di vista sia hardware che
software.
Da notare che implementazione e specifiche di due macchine differenti
possono essere diverse, l’unica cosa importante sta nel fatto che il sistema
funzioni correttamente e che vi sia un linguaggio comune che permetta la
1.4 Layer e protocolli
comunicazione. Per esempio tra due architetture con specifiche e implementazioni differenti che sanno interpretare e utilizzare il protocollo IP la
comunicazione avviene senza problemi.
Stack di rete e linux Seguendo i suggerimenti degli stessi developer del
kernel13 e dei driver presi in considerazione si e’ deciso di procedere utilizzando come riferimento lo stack di rete mac80211 recentemente inserito nel
kernel stabile, in quanto il codice si presenta meglio strutturato e organizzato.
Inoltre e’ lo stack di rete del kernel stabile e vi sara’ una migrazione dei vari
driver che ancora si appoggiano al vecchio stack softmac e generic ieee80211.
Nel modello ISO OSI la rete e’ strutturata in 7 livelli di astrazione. I
livelli a cui siamo maggiormente interessati dal punto di vista delle modifiche
da effettuare sono quello MAC, IP e Trasporto, la raccolta delle informazioni
avviene muovendosi tra essi.
1.4.2
Livello Data Link (livello 2 del modello OSI)
Il livello Data Link si pone il problema della connessione diretta di due
apparecchi. Si hanno quindi due sistemi connessi mediante un canale di
comunicazione che si comporta come un cavo, per esempio un cavo coassiale, una linea telefonica, oppure una connessione punto-punto mediante
microonde.
Necessariamente il canale deve comportarsi come un cavo nel quale ogni
sequenza di bit inviati viene ricevuta esattamente in quell’ordine. Il problema
non e’ triviale data la possibilita’ di errori dovuti alla tecnologia. Un altro
aspetto non trascurabile consiste nella presenza di ritardi di propagazione
del segnale e nel fatto che la velocita’ di trasmissione e’ finita. Questi limiti
influenzano notevolmente il funzionamento dei protocolli.
13
Nella documentazione reperibile scritta da loro specificano il punto di vista ufficiale
11
12
1. Scenario
Mac 802.11
Il protocollo MAC (Media Access Control) e’ un sottolivello del Data Link
Layer. Permette l’indirizzamento univoco e l’accesso ad un canale condiviso. Questo sottolivello funge da interfaccia tra il sottolivello LLC (Logical
Link Control, rientra anchesso nel DL Layer) e il livello fisico (primo layer
del modello OSI). Inoltre emula un canale di comunicazione full-duplex in
una rete ad accesso multiplo rendendo possibile comunicazioni in unicast,
multicast e broadcast.
In una comunicazione point-to-point full-duplex il livello MAC non e’
necessario, ma viene quasi sempre incluso in questi protocolli per questioni
di compatibilita’.
Indirizzamento Gli indirizzi gestiti da questo layer vengono chiamati indirizzi fisici o indirizzi MAC. Un identificativo MAC e’ un numero di serie
univoco associato alla scheda di rete, rendendo possibile la consegna dei pacchetti ad un nodo all’interno della sottorete14 . Un esempio di rete fisica e’
una LAN Ethernet, magari con connesso un AP e i relativi client, infatti quest’ultima condivide con la rete cablata la stessa gerarchia di indirizzi
MAC a 48 bit.
Meccanismo di accesso al canale Il meccanismo fornito da questo sottolivello e’ anche conosciuto come multiple access protocol e rende possibile a
piu’ nodi di collegarsi e condividere lo stesso mezzo fisico. Questo protocollo
scova o previene le collisioni dei pacchetti in transito mediante un meccanismo di contesa del canale oppure attraverso l’allocazione di risorse riservate
per la creazione di un canale logico. Questo meccanismo di controllo si fonda
sul multiplexing a livello fisico.
Il protocollo piu’ diffuso nelle reti wired e’ chiamato CSMA/CD (Carrier
14
Per sottorete si intende un rete fisica composta da una o piu’ reti interconnesse me-
diante ripetitori, hub, bridge e switche, ma non IP router. Un IP router puo’ connettere
piu’ sottoreti differenti
1.4 Layer e protocolli
sense multiple access con collision detection). Viene utilizzato all’interno
dello stesso dominio di collisione, per esempio una sottorete gestita da un
hub o un bus Ethernet. Una rete solitamente e’ formata da vari domini di
collisione interconnessi mediante bridges e switches.
Parlando delle reti wireless troviamo il CSMA/CA (Carrier sense multiple
access con collision avoidance). Parlando di CSMA, quando un nodo mobile
desidera trasmettere per prima cosa deve ascoltare il canale per un tempo
prestabilito per verificare che non vi siano attivita’. Se lo si trova in stato
idle allora si ha il permesso di trasmettere, in caso contrario si deve posticipare l’invio dei dati. Nello specifico con il CSMA/CA (LocalTalk) una volta
che il canale e’ libero, la station che vuole trasmettere invia un segnale che
specifica alle altre stazioni di non trasmettere e solo successivamente inizia
l’invio dei dati.
La prevenzione delle collisioni migliora le performance del CSMA. In caso di canale occuppato il tempo di attesa prima del test successivo viene
randomizzato, e questo riduce notevolmente la probabilita’ di collisioni. La
necessita’ della prevenzione delle collisioni nasce dal fatto che in una rete
wireless non si riesce ad ascoltare il canale durante la trasmissione dei propri
dati, questo rende impossibile scovare le collisioni una volta avvenute. Un
ulteriore problema e’ quello del client nascosto.
Il client A e il client B non si vedono tra loro, ma tentano di comunicare
con lo stesso Access Point. A trasmette all’AP e B non sentendo il canale
occuppato decide di fare lo stesso.
Un metodo per incrementare le prestazioni e’ stato trovando aumentando
lo scambio di messaggi prima della trasmissione vera e propria. Il meccanismo e’ chiamato IEEE 802.11 RTS/CTS e funziona nel seguente modo. A
prima della tramissione invia all’AP un pacchetto di tipo RTS (Request to
send), se l’AP puo’ rivere invia come risposta un CTS (Clear to send) e cosi’
iniziera’ la trasmissione di A. In questo modo B non sa che A esiste, ma sa
che l’AP sta ricevendo dati da qualcuno perche’ giunto in possesso del CTS
per qualcun’altro.
13
14
1. Scenario
Figura 1.3: Nodo nascosto
La dimensione dei pacchetti RTS/CTS varia da 0 a 2347 ottetti. Normalmente, se i dati da inviare hanno dimensione minore di 2347 l’invio del frame
RTS non avviene e il pacchetto dati e’ spedito immediatamente. Se questa
dimensione viene superata, allora il meccanismo RTS/CTS viene utilizzato.
Frame 802.11 Lo standard 802.11 definisce tre differenti tipi di frame:
dati (DATA), controllo (CTRL), manutenzione (MGMT). Ognuno di essi e’
formato da svariati campi utilizzati dal sublayer per svolgere le sue funzioni.
Figura 1.4: Frame 802.11
1.4 Layer e protocolli
15
Il primo campo da valutare nello studio e’ il Frame Control, composto
da 11 sottocampi. Contiene informazioni riguardanti il protocollo, il tipo
(uno dei tre precedentemente citati), il sottotipo del frame (nel caso sia di
controllo, per esempio un ACK), se vi e’ frammentazione e altro ancora.
Un altra informazione sensibile riguarda la crittografia e cioe’ specifica se il
payload e’ crittato oppure no.
Per completezza riportiamo la struttura di un ACK frame.
Figura 1.5: Struttura ACK Frame
Come si puo’ notare, non e’ presente nessun campo che permetta di ricondurre l’acknowledgement ricevuto col relativo pacchetto trasmesso. Per
questo tenere traccia dell’effetiva trasmissione dei pacchetti non risulta affatto essere un compito banale.
1.4.3
Livello Network (livello 3 del modello OSI)
Nel trasferimento dei pacchetti dalla sorgente alla destinazione, questo
livello si preoccupa di tutti i dettagli relativi al percorso.
La consegna
deve avvenire indipendentemente dalla struttura della rete e dal numero di
sottoreti presenti.
E’ da notare che questo e’ l’ultimo livello in cui si ha a che fare con
una trasmissione end-to-end. Per questo e’ necessario che il layer conosca la
topologia di reti e sottoreti per potere scegliere il giusto percorso attraverso di
esse, soprattutto nel caso sorgente e destinazione si trovino in reti differenti.
Sempre nel terzo livello viene controllato il flusso delle comunicazioni per
evitare la creazione di code negli snodi nevralgici della rete.
16
1. Scenario
Protocollo IPv4
Il protocollo IPv4 e’ descritto nell’IETF RFC 791[9] pubblicato per la
prima volta nel settembre 1981.
E’ un protocollo data-oriented e viene usato nelle reti di tipo packet
switched. E’ di tipo best-effort, infatti non garantisce la consegna dei pacchetti a destinazione. Non controlla la correttezza dei dati e possono verificarsi ricezione di pacchetti duplicati oppure non in ordine di spedizione.
Spazio degli indirizzi Gli indirizzi IPv4 sono a 32 bit, per questo vi
sono solo 4.294.967.296 indirizzi possibili. Da tenere presente che alcuni
di essi sono di tipo riservato, per esempio circa 18 milioni sono destinati
alle reti private e circa 16 milioni sono indirizzi broadcast. Nonstante il
numero apparentemente elevato, questo spazio di indirizzamento col passare
del tempo si e’ dimostrato insufficiente. Il NAT (Network address translation)
ha permesso di allontanare l’inevitabile. La soluzione evvettiva al problema
la si trova nello sviluppo del protocollo IPv6.
Il formato umanamente leggibile di un indirizzo IPv4 consiste in una
quadrupla di numeri separati da un punto (92.168.10.1).
NAT Un metodo semplice per permettere a tutti i computer di una sottorete di dialogare con tutta la rete pur non possedendo un ip fisso visibile
dall’esterno e’ proposto dal NAT (Network address translation). Il metodo consiste nell’avere un solo gateway con ip fisso accessibile dall’esterno che
presta il suo indirizzo per le comunicazioni di tutte le macchine della sottorete
traducendo e tenendo traccia dei pacchetti in transito per poter recapitare
le risposte ai legittimi destinatari. In questo modo si migliora la sicurezza perche’ le macchine interne alla rete non sono direttamente accessibili
dall’esterno, e si migliora l’utilizzo dello spazio di indirizzamento possibile,
grazie al fatto che un’intera rete privata utilizza un solo IP.
1.4 Layer e protocolli
ARP Il protocollo IP necessita di conoscere la struttura logica della rete.
Infatti se un nodo A invia un pacchetto (contenente l’indirizzo IP di sorgente
e destinazione) al nodo B situato in una rete differente, il device che collega
le due reti deve avere modo per conoscere entrambe le loro strutture. Questo
deve avere una tabella dinamica dei MAC di entrambe le sottoreti e la giusta
associazione MAC-IP. Questa associazione viene fatta mediante il protocollo
ARP (Address Resolution Protocol) e lo scambio di messaggi propagati in
broadcast. La tabella contenente le coppie vede associato ad esse un TTL
(Time to live), in pratica la loro scadenza.
DHCP La possibilita’ che un computer conosca il suo MAC address ma
non il suo indirizzo IP si presenta spesso nelle reti private. La soluzione
a questo, in precedenza e’ stata RARP (Reverse ARP), successivamente si
e’ arrivati a BOOTP (Bootstrap Protocol), per arrivare a DHCP (Dynamic Host Configuration Protocol) dei giorni nostri. Oltre all’IP, DHCP permette l’assegnazione del server NTP (Network Time Protocol), quello DNS
(Domain Name System) e altri particolari.
Formato del pacchetto IP Il protocollo IP prevede la seguente struttura
per i datagram IP
Figura 1.6: Header del pacchetto IP
17
18
1. Scenario
Data Il campo data non fa parte dell’header IP, e non e’ incluso nel
checksum. Il suo contenuto e’ specificato nel campo protocol e puo’ essere
uno qualsiasi dei protocolli del livello trasporto. I piu’ comuni sono:
Tabella 1.1: Codice protocolli Transport Level
Codice Protocollo
1
Internet Control Message Protocol (ICMP)
2
Internet Group Management Protocol (IGMP)
6
Transmission Control Protocol (TCP)
17
User Datagram Protocol (UDP)
89
Open Shortest Path First (OSPF)
132
Stream Control Transmission Protocol (SCTP)
Frammentazione e riassemblaggio Per rendere il protocollo piu’
tollerante alle differenze delle varie sottoreti si e’ inserito il concetto di frammentazione. Grazie a questo ogni device ha la possibilita’ di spezzare i dati
in piu’ pacchetti. Questo e’ necessario nel caso la MTU (maximum transmission unit) della rete sia minore della dimensione del pacchetto. Per esempio
la dimensione massima di un pacchetto IP e’ di 65,535b, ma la dimensione
tipica del MTU di una rete Ethernet e’ di 1500b. Questo comporta che per
inviare tutto il payload del pacchetto IP sono necessati 45 frame ethernet.
Per la frammentazione si e’ scelto il network layer perche’ e’ il primo che
collega gli estremi della comunicazione anziche’ gli hop. Se la frammentazione
fosse eseguita a livelli superiori (TCP, UDP, etc.) si avrebbero implementazioni ridondanti. Nel caso fosse implementata a livelli inferiori (Ethernet,
ATM, etc.) risulterebbe necessario frammentare e riassemblare ad ogni hop,
il che implicherebbe una aumento spropositato dei costi. In pratica la scelta
e’ stata compiuta per motivi di efficienza.
Frammentazione Quando un device riceve un pacchetto IP esamina
la destinazione e sceglie su quale interfaccia instradarlo. Ogni interfaccia ha
1.4 Layer e protocolli
un MTU specifico, quindi si valuta la necessita’ di frammentazione.
La frammentazione tiene conto della dimensione dell’header (minimo 20b
e massimo 60b). Ogni segmento ha la sua intestazione IP con queste variazioni:
• la dimensione totale del pacchetto viene modificata con la dimensione
del segmento
• il flag MF (more fragments) viene posto a 1 per tutti i frammenti eccetto
l’ultimo
• il fragment offset viene sistemato in accordo alla posizione del segmento
nel pacchetto IP completo utilizzando blocchi di 8byte
Riassemblaggio Alla ricezione di un pacchetto IP e’ necessario controllare il bit della frammentazione e l’offset. Se il bit e’ a 1 e l’offset e’
diverso da 0 allora e’ necessario immagazzinare i dati relativi al pacchetto. Alla ricezione del pacchetto con bit a 0 si potra’ ricostruire il pacchetto
originario utilizzando i campi offset. Una volta riassemblati tutti i segmenti
nell’ordine corretto, il pacchetto IP viene passato al livello superiore dello
stack di rete per ulteriori elaborazioni.
1.4.4
Livello Trasporto (livello 4 del modello OSI)
Il livello di trasporto permette il dialogo strutturato tra mittente e destinatario. I protocolli definiti permettono la comunicazione end-to-end15 .
Uno di questi protocolli e’ il TCP (Transmission Control Protocol). E’
connection-oriented e permette al flusso di dati di essere recapitato senza
errori. I frammenti dello stream vengono impacchettati e passati ai layer
inferiori, sara’ poi il ricevente che provvedera’ a riassemblarli e in caso di
errore a chiederne il rinvio. Implementa anche un meccanismo per il flow
15
Per comunicazione end-to-end si intende lo scambio di informazioni tenendo in con-
siderazione solamente sorgente e destinazione, senza prestare attenzione ai passaggi
intermedi.
19
20
1. Scenario
control, e cioe’ non permette ad una sorgente veloce di congestionare un
ricevente lento.
Il protocollo a cui siamo interessati e’ l’UDP (User Datagram Protocol).
Questo e’ di tipo inaffidabile (non e’ detto che i pacchetti arrivino a destinazione) e senza connessione. E’ comunque abbondantemente utilizzato
laddove le applicazioni necessitano di interattivita’ e velocita’. Per esempio
audio e video vengono quasi sempre inviati attraverso UDP, questo perche’
piuttosto che la ricezione di tutti i pacchetti, e’ molto piu’ importante la
regolarita’ e la continuita’ del flusso di dati.
Protocollo UDP
L’User Datagram Protocol e’ uno dei protocolli fondamentali di Internet.
Le applicazioni possono creare e inviarsi dei messaggi brevi (conosciuti anche come datagram) attraverso degli appositi socket. Il protocollo e’ stato
definito nel 1980 da David P. Reed (RFC 768)[10].
UDP non garantisce l’affidabilita’ della connessione o che i pacchetti
vengano ricevuti nell’ordine di invio. Infatti possono anche essere duplicati
o non arrivare affatto senza nessuna segnalazione. L’eliminazione di questo
controllo rende il protocollo veloce ed efficiente per le applicazioni che non
necessitano di queste garanzie. Spesso applicazione audio e video lo utilizzano data la preferenza ad avere pacchetti mancanti invece che ritardi elevati.
Oppure in caso sia necessario una sincronia tra un server e dei client (per
esempio i giochi in rete) oppure si debbano gestire messaggi in broadcast o
multicast.
Un esempio di applicazioni che utilizzano UDP sono Domain Name System (DNS), streaming media applications come IPTV, Voice over IP (VoIP)
e per esempio Trivial File Transfer Protocol (TFTP).
UDP header Il protocollo UDP impone un header dei pacchetti con la
seguente struttura.
1.4 Layer e protocolli
Figura 1.7: Header del pacchetto UDP
Caratteristiche del protocollo UDP e’ un semplice protocollo basato sul
trasferimento di messaggi e privo di connessione (non si crea una connessione
end-to-end dedicata). Semplicemente lo stream di pacchetti viene inviato
alla destinazione senza nessun controllo di sorta e ognuno dei pacchetti e’
completamente indipendente dall’altro.
Inaffidabilita’ Quando un messaggio viene inviato, non e’ possibile sapere
nulla della sua sorte.
Mancanza di ordinamento Il flusso di messaggi inviati puo’ essere ricevuto in ordine differente.
Leggero Data la mancanza di controlli e’ leggero in termine di byte dell’header da aggiungere, efficiente e veloce.
Datagram I pacchetti vengono inviati individualmente e nel caso arrivino a destinazione essi sono sicuramente integri. Hanno dimensione
predefinita e non vengono spezzettati o riassemblati.
1.4.5
Livello Applicazione (livello 7 del modello OSI)
Il livello applicazione contiene svariati protocolli normalmente utilizzati dagli utenti. Un esempio chiarificatore lo si trova nel protocollo HTTP
(HyperText Transfer Protocol), che sta alla base del World Wide Web.
La quantita’ di protocolli esistenti non permette di discuterne o farne
una panoramica, perche’ qualsiasi applicazione utilizzi la rete si basa su un
protocollo di questo livello (dalle mail alla messaggistica istantanea e molto
altro).
21
22
1. Scenario
Protocollo VoIP
Con VoIP[11, 12] (Voice Over Internet Protocol) si intende il protocollo
capace di gestire il passaggio da segnale audio (analogico) a flusso di pacchetti
(digitale) sulla rete e viceversa.
In questo modo e’ possibile effettuare delle telefonate utilizzando la rete
Internet anziche’ quella telefonica pubblica. Per questo e’possibile telefonare
a costi molto bassi in qualsiasi parte del mondo senza differenze geografiche.
La qualita’ della telefonata e’ paragonabile a quella di una normale linea
telefonica; basta solo disporre di una connessione internet a banda larga
(ADSL o HDSL) con almeno 32 kbps di banda garantita.
Funzionamento Per poter funzionare sono richiesti due tipi di protocollo
di comunicazione in parallelo:
• uno per trasportare la voce sottoforma di dati, normalmente viene
adottato il protocollo RTP (Real-Time Transport Protocol)
• l’altro per riconvertire i dati in voce, per sincronizzarla e riordinarla
quindi cronologicamente
Esistono diversi protocolli standard:
• SIP (Session Initiation Protocol) della IETF;
• H.323 della ITU;
• Skinny Client Control Protocol proprietario della Cisco;
• Megaco (conosciuto anche come H.248);
• MGCP;
• MiNET proprietario della Mitel;
• IAX, usato dai server Asterisk open source PBX e dai relativi software
client.
1.4 Layer e protocolli
Vantaggi I benefici dell’utilizzo di una tecnologia innovativa quale il VoIP
sono molteplici.
Abbattimento costi Consente un abbattimento dei costi notevole, sia
per chiamate nazionali che internazionali o intercontinentali dato che il costo
della chiamata praticamente non varia sia che si parli nel proprio paese che
dalla parte opposta del mondo.
Agevolazioni in campo lavorativo Puo’ essere utilizzato sia all’interno di una stessa azienda, sia per telefonate piu’ complesse, come teleconferenze in multi-point. Inoltre si puo’ utilizzare una sola rete integrata per
voce e dati, che garantisce una riduzione dei bisogni totali di infrastruttura
e, in ambito aziendale uno scambio agevolato delle informazioni.
Servizi telematici Se si decide di utilizzare l’ apparecchio telefonico
apposito, a differenza dei normali apparecchi questo potra’ essere sfruttato
sia per normali conversazioni, che per avere accesso ad alcuni servizi internet,
quali l’ elenco telefonico, ottenendo una risposta in forma vocale o testuale.
Possibilita’ di Number Portability Passando alla tecnologia VoIP
non e’ detto che si debba perdere il proprio numero telefonico, perche’, grazie
alla Number Portability il numero resta tale e quale. La procedura che
permette di trasferire numeri telefonici da un operatore all’altro e’ similare a
quella dei vari gestori di telefonia mobile. E’ possibile, inoltre, telefonare da
un pc portatile via internet da qualsiasi luogo dotato di collegamento ADSL.
Maggiore privacy Le chiamate tramite VoIP sono piu’ sicure delle
normali chiamate, anche se non vengono criptate o cifrate. Per riuscire ad
intercettare una comunicazione VoIP si deve aver accesso agli apparati che
costituiscono la rete VoIP e/o la Rete Internet.
23
24
1. Scenario
Numeri di emergenza Dal 2006 la maggior parte dei provider di
servizi VoIP ha abilitato le chiamate ai numeri di emergenza, localizzando in
tempo reale l’utente.
Svantaggi Come tutte le tecnologie in via di sviluppo, e quindi da perfezionare, anche questa del VoIP presenta diversi svantaggi.
Qualita’ vocale Utilizzando la stessa linea per trasmettere sia voce che
dati, la qualita’ della voce durante una telefonata potrebbe calare e, in caso
di black-out elettrico non sarebbe possibile effetturare telefonate.
La mancata qualita’ eccellente delle telefonate e’ dovuta a due diversi
problemi: il ritardo e la perdita di pacchetti dati.
Il ritardo genera eco e sovrapposizione delle conversazioni. Per sopperire a
questi problemi fastidiosi sara’ necessario progettare degli apparecchi appositi
in grado di cancellare l’eco. Per sopperire alla presenza di eco e disturbi quali
fruscii, sono stati gia’ creati software appositi. Per quanto riguarda la gesione
dei silenzi, delle pause o di respiri prolungati, quindi mancanza di parole, sono
stati creati altri software per eliminarli tenendo conto che, generalmente, una
conversazione e’ costituita da circa il 50% di tempi morti ed in questo modo
si mantiene libera la linea da sovraccarichi inutili.
Per quanto riguarda la perdita dei pacchetti, per ottenere una conversazione lineare questi devono rispettare l’ordine cronologico in cui vengono
inviati. Una perdita di pacchetti voce pari o superiore al 10% non consente
di svolgere una chiara comunicazione.
Banda insufficiente Il gestore della rete dovrebbe garantire una larghezza di banda sufficientemente ampia, per ridurre il tempo di latenza e le perdite
di dati. Tuttavia cio’, mentre e’ relativamente facile nelle reti private, e’ molto
piu’ difficile quando si usa internet come mezzo trasmissivo.
1.5 Crittografia
Numerazioni speciali Un ulteriore svantaggio e’ dato dalla impossibilita’ di alcuni operatori di chiamare i numeri di emergenza e alcuni numeri
speciali.
Il nostro contesto nel VoIP Lo scenario applicativo da noi preso in considerazione, vede utilizzato il VoIP in un contesto wireless. Per questo motivo
diviene indispensabile risolvere il problema dell’interattivita’ del controllo del
flusso di dati con questo mezzo trasmissivo.
1.5
Crittografia
Sicurezza nelle reti wireless Parlando di sicurezza in ambito wireless
si intende la prevenzione di accessi non autorizzati o il danneggiamento dei
computer interconnessi.
Vi sono un gran numero di buchi nella sicurezza dei protocolli utilizzati
e dei metodi di crittazione. Da non sottovalutare e’ anche la mancanza di
consapevolezza e attenzione degli utenti di questo servizio. La violazione di
queste reti e’ diventata molto piu’ semplice con l’introduzione delle applicazioni easy-to-use basate sia su Linux che su Windows trovabili nella rete
gratuitamente.
Una realta’ da tenere in considerazione vede l’utilizzo delle periferiche
wireless non configurate utilizzate per introdursi nelle reti cablate. Questo
approccio e’ stato utilizzato per ottenere l’accesso a quelle reti aziendali prive
di wireless. Infatti dal 2005 ad oggi la stragrande maggioranza dei laptop ha
una scheda wireless integrata, attiva anche se non configurata per l’accesso
ad una rete.
Tipologie di accessi non autorizzati Di seguito sono riporati alcuni
modi per accedere a una rete wireless. Tutti gli attacchi volti a demolire la
rete sono omessi.
L’accesso ad una rete puo’ essere accidentale, specialmente se la rete
25
26
1. Scenario
non e’ protetta e si utilizzano dei tool per l’associazione automatica alle reti
presenti.
L’associazione puo’ essere volontaria e dannosa per gli utenti legittimi
della rete. Vi sono svariati modi per arrivare al risultato desiderato. Il
cracker puo fingersi access point, usare le credenziali fornite dal client per
connettersi alla rete ufficiale e inoltrare tutti i dati del client all’AP vero.
Questo e’ un tipico esempio di ’man in the middle’. Oppure puo’ creare una
rete ad hoc con un laptop connesso alla rete cablata e utilizzarlo come accesso
ad essa.
E’ da tenere presente che le reti wireless operando al livello 2 dello stack,
ignorano le protezioni fornite dal livello 3 come VPN (Virtual private network) o reti autenticate. L’unica protezione possibile e’ situata in un accesso
protetto o autenticato al canale, cosa che migliora la protezione, ma rimane
comunque vulnerabile agli attacchi volontari.
Esiste la possibilita’ di limitare i MAC address con privilegi sulla rete.
Un metodo per accedere a queste reti si basa sull’ascolto delle comunicazione presenti e l’appropriazione da parte del cracker di un indirizzo MAC
privilegiato.
Come affrontare il problema Esistono tantissimi modi per evitare
l’intrusione in una rete, ma non esisono reti sicure al 100%. Il metodo piu’
affidabile vede l’uso combinato di piu’ tecnologie contemporaneamente.
Sicuramente vi sono tre regole d’oro:
1. Tutti i dispositivi che possono accedere alla rete devono essere sicuri.
(Firewall, antivirus, corretta configurazione del sistema)
2. Tutti gli utenti devono sapere cosa significa sicurezza in campo wireless
e non.
3. La rete deve essere costantemente monitorata per vedere malfunzionamenti ed eventuali tentativi di accesso.
1.5 Crittografia
Filtraggio dei MAC ID Si stabiliscono quali sono gli indirizzi MAC
che possono accedere alla rete e si filtrano tutti gli altri.
IP Statico Si disabilita l’assegnamento automatico dell’indirizzo IP eseguito dal server DHCP. Questo non impedisce a qualcuno di connettersi alla rete, solo impone una maggior ricerca. Restringendo la dimensione
delle sottoreti e’ anche possibile bloccare determinati indirizzi che altrimenti
sarebbero utilizzabili senza problemi.
Crittografia Per rendere il canale sicuro diviene quindi necessario introdurre la crittografia. In questo modo vi e’ un oscuramento delle informazioni trasmesse nell’etere.
1.5.1
WEP - Wired Equivalent Privacy
Il WEP e’ un algoritmo definito dallo standard 802.11i e deprecato dal
2004 utilizzato dalle reti wireless. Nato per rendere le reti wireless sicure
come quelle cablate, nel 2001 si sono trovate delle vulnerabilita’ gravi. Ad
oggi, con il dovuto software, una rete WEP diviene utilizzabile in 5 6 minuti.
Nonostante questo la WEP e’ ancora fortemente utilizzata, e rimane la
scelta di default utilizzata da AP e router.
Algoritmo di crittazione WEP usa il cifrario a chiave simmetrica RC4
per il livello di confidenza16 , e il checksum CRC-32 per l’integrita’.
Lo standard a 64 bit usa una chiave di 40 bit concatenata con 24 bit di
inizializzazione per formare la chiave RC4 realmente usata durante il traffico.
La scelta dei 40bit fu dettata dalle restrizioni goverantive presenti in USA
nel 1999. Una volta tolte le restrizioni si amplio’ lo standard fino a 128bit
con 104bit di chiave. Questo tipo di chiave viene spesso usata come stringa
16
Per livello di confidenza si intende la probabilita’ che i dati vengano usati non
dall’utente finale
27
28
1. Scenario
esadecimale di 26 caratteri. Esiste anche un formato a 256bit ma non tutti i
produttori lo implementano.
La dimensione della chiave non e’ la vulnerabilita’ maggiore della WEP.
Infatti un problema sono le collisioni e i pacchetti alterati, problemi che non
hanno nulla a che fare con la lunghezza della chiave.
Autenticazione Vi sono principalmente due metodi per l’autenticazione:
Open System e Shared Key.
Nel caso di Open System, il client non deve fornire delle credenziali. Semplicemente la chiave e’ conosciuta da entrambe le parti e quindi i pacchetti
si oscurano utilizzandola. Per questo non vi e’ una vera autenticazione.
Parlando di Shared Key, la chiave WEP si usa anche per l’autenticazione.
L’handshake e’ suddiviso in quattro parti:
1. il mittente invia la richiesta di autenticazione al destinatario
2. questo invia al mittente una ’frase’ in chiaro
3. il mittente la critta con la chiave WEP stabilita e la reinvia al destinatario
4. il destinatario la decritta utilizzando la WEP e controlla che la frase
mandata corrisponda.
In caso di successo l’autenticazione e’ stata effettuata. Dopo l’associazione
autenticata la chiave viene usata per crittare tutti i frame in uscita.
Rimedi Data la debolezza insita nello standard WEP, l’unica soluzione
possibile sta nell’uso di protocolli di tunneling crittati (IPSec, Secure Shell
ecc.) che permettono di avere una trasmissione sicura utilizzando reti insicure.
Comunque l’unica soluzione realmente efficacie sta nel non usare un protocollo di sicurezza deprecato.
1.5 Crittografia
1.5.2
WPA e WPA2 - WiFi Protected Access
Wi-Fi Protected Access (WPA e WPA2) e’ un protocollo nato in risposta
alle debolezze della WEP. WPA implementa quasi interamente lo standard
IEEE 802.11i, ma e’ da tenere presente che standard e implementazione effettiva hanno avuto processi evolutivi paralleli a causa della necessita’ di
ripristinare la sicurezza. WPA2 implementa interamente lo standard. Se
lo standard WPA non impone modifiche all’hardware (se non un possibile aggiornamento del firmware) il WPA2 funziona solamente su dispositivi
moderni.
Esistono 2 tipologie di protocollo WPA, Enterprise e Personal. Quello
Enterprise propone un server per l’autenticazione. Nel caso del Personal si
ha una chiave precedentemente condivisa, infatti tutti gli accessi avvengono
mediante una parola d’ordine uguale per tutti.
Cifratura I dati sono crittati usando il cifrario RC4 con una chiave a 128bit
con un vettore di inizializzazione di 48bit. L’effettiva miglioria dalla WEP e’
stata l’introduzione del TKIP (Temporal Key Integrity Protocol) che cambia dinamicamente le chiavi in uso, permettendo di affrontare i metodi di
ottenimento della chiave usati per la WEP.
Oltre alla cifratura e all’autenticazione, viene usato il MIC (message integrity code) basato sull’algoritmo chiamato Michael, per proteggere l’integrita’ del payload.
Risultato Avendo aumentato la dimensione di chiavi e vettore di inizializzazione, dopo aver ridotto il numero dei pacchetti inviati con le chiavi e
migliorando il sistema di verifica di integrita’ dei pacchetti, il protocollo e’
arrivato ad un livello di sicurezza accettabile.
Si deve comunque tenere presente che l’algoritmo Michael e’ stato utilizzato anche per permettere il riutilizzo dell’hardware datato, e quindi presenta
delle vulnerabilita’. Per ovviare a queste debolezze, nel caso si trovino due
29
30
1. Scenario
pacchetti compromessi, TKIP riavvia la rete forzando la rigenerazione delle
chiavi e quindi bloccando l’attaccante.
Capitolo 2
Obiettivi e sperimentazione
2.1
Obiettivi
La connessione wireless, per sua stessa natura, non permette di effettuare
alcun controllo di flusso sulla trasmissione. Alcuni protocolli come il TCP
implementano questa caratteristica a livello piu’ alto, ma nel nostro caso
dovendo usare il protocollo UDP, su cui si appoggia il VOIP, non e’ in grado
di fornire questo servizio.
Il nostro studio si pone come obiettivo il riportare in userspace alcune informazioni basilari riguardanti la trasmissione dei frame 802.11 per garantire
almeno un controllo di flusso fino al prime hop della comunicazione (Access
Point).
2.1.1
Ack dal prime hop e interattivita’
Nel nostro contesto e’ necessario sapere se la trasmissione di un frame e’
andata a buon fine. Le motivazioni possono essere varie, la possibilita’ di
scegliere di ritrasmettere i frame non inviati correttamente, il monitoraggio
del carico della rete e delle latenze effettivamente presenti (tempo trascorso dal momento in cui il pacchetto viene processato per la trasmissione e
l’avvenuta ricezione del relativo acknowledgement).
Stabilire se effettivamente il pacchetto sia arrivato a destinazione impone
31
32
2. Obiettivi e sperimentazione
la creazione (o l’utilizzo) di un protocollo differente che agisca almeno a livello
trasporto (layer ISO-OSI). Fissando l’utilizzo di UDP over IP l’unica certezza
che si puo’ ottenere sta’ nell’effettiva ricezione del frame da parte del prime
hop (solitamente l’access point). Da non sottovalutare il fatto che spesso il
prime hop e’ connesso alla rete cablata, il che diminuisce notevolmente la
possibilita’ di perdita dei pacchetti.
Il meccanismo cross-layer da noi implementato elabora informazioni prese
dai livelli 2 3 e 4 e li rende disponibili in user space.
Il problema puo’ essere risolto affrontando i seguenti sottoproblemi uno
alla volta e non necessariamente nell’ordine.
• L’utente che invia un datagram UDP, come fa a sapere a quanti e quali
pacchetti IP esso e’ associato?
• Dato l’identificatore del pacchetto IP, come e’ possibile recuperare
l’identificativo del frame MAC in cui e’ incapsulato?
• Dato un frame MAC, come e’ possibile associarvi gli acknowledgement
ricevuti dall’access point?
Riesaminando lo stack di rete precedentemente spiegato si vede come,
partendo dal basso, a livello MAC si reperiscono le informazioni riguardanti
il frame. Infatti e’ a questo livello che si ottiene l’identificatore del frame e
le informazioni relative al suo stato (ACK ricevuto, retry count ecc).
L’associazione dell’ID del pacchetto IP e il relativo frame MAC e’ possibile
a livello network nel momento in cui vi e’ interazione con il livello MAC. In
questo modo dato un identificatore di un pacchetto IP si possono sapere le
sorti del frame associato.
Lo stesso approccio puo’ essere usato a livello trasporto nel momento in
cui si usino le primitive del livello network per l’incapsulamento dei datagram.
Per risolvere il primo problema e’ stato necessario modificare la syscall di
invio di un pacchetto UDP perche’ questa possa restituire l’id del pacchetto
IP associato, cosicche’ l’utente possegga tutti i dati importanti. Per fornire
le informazioni sull’avvenuta trasmissione dei frame si e’ usato il canale di
2.1 Obiettivi
33
errore dei socket. Tutta la gestione dei controlli e della ritrasmissione e’
lasciata all’applicativo in user-space.
Figura 2.1: Modifiche cross-layer
2.1.2
Crittografia
Le reti wireless forniscono una protezione dei dati in transito mediante la
cifratura di essi. Perche’ il servizio da noi fornito sia efficacie e’ necessario
che funzioni indipendentemente dal tipo di cifratura utilizzata dalla rete.
Come obiettivo formulato in questi termini non e’ detto che sia raggiungibile, data la varieta’ di reti che e’ possibile incontrare sul percorso. Per
questo lo studio si focalizza sul mantenere il servizio stabile in presenza di
reti libere, con chiave WEP o TKIP. In questo modo si ha copertura con la
grande maggioranza delle reti presenti in circolazione.
La gestione di questo tipo di informazioni viene eseguita a livello MAC.
34
2. Obiettivi e sperimentazione
2.2
Sperimentazione
Questo studio e’ stato svolto utilizzando e approfondendo le informazioni
fornite dal progetto di Laboratorio di Reti di Calcolatori e dal Tirocinio
svolto presso l’universita’ di Bologna. Per questo e’ necessario motivare le
scelte fatte esponendo qualche dettaglio relativo alle conoscenze pregresse.
Apportare le modifiche necessarie nel kernel a livello stack di rete, permette di ottenere la migliore portabilita’ possibile. E’ da tenere presente che
quando questo studio ha avuto inizio, Settembre 2007, il nuovo stack di rete
era appena entrato nella versione stable del kernel. La documentazione era
molto nebulosa e la reperibilita’ di driver che lo utilizzassero era ancora difficile. Per questo motivo la ricerca e’ iniziata lato driver, nonostante spesso
abbia posto problemi che esulavano il nostro scopo iniziale.
RTL8187 e RT2570usb Nello scenario adottato, il device da prendere in
considerazione deve essere preferibilmente di tipo USB. Per questo in un primo momento sono stati valutati due diversi adattatori usb wireless dotati di
differenti chipset: un rt2570usb e un rtl8187 per i quali sono presenti i driver per il kernel versione 2.6.23.x. Il driver rtl8187 funziona perfettamente,
mentre l’rt2570 ha ancora un problema legato al trasfer rate e soprattutto,
essendo un device piuttosto datato, risente notevolmente delle condizioni ambientali e della polarizzazione dell’antenna. Nonostante il chipset rtl8187 sia
relativamente nuovo e disponibile in commercio, il suo driver rende praticamente impossibile interfacciarsi in modo aperto con l’hardware a causa della
struttura del firmware. Al contrario, nel caso del rt2570 (parte del rt2x00) il
firmware non e’ presente, ma il chipset ralink rt2570 e’ vetusto e non piu’ in
commercio. La versione successiva (rt73) si basa su firmware e il supporto
sotto Linux e’ ben lontano dall’essere usabile.
La scelta e’ caduta sull’rtl8187 . Mediante l’analisi del codice dei driver
si e’ stabilito che la gestione della ricezione e della trasmissione e’ lasciata
interamente al firmware, come molti altri punti caldi. Il firmware filtra le
informazioni riguardanti la trasmissione a tal punto da costringere gli svilup-
2.2 Sperimentazione
patori del driver a falsificarle per permettere ai protocolli dei livelli superiori
di funzionare a dovere. Infatti il driver segna tutti i pacchetti inviati come
correttamente trasmessi (acknowledgement ricevuto) appena prima di passare il pacchetto al device per la spedizione. Sono state fatte alcune prove
per l’ottenimento delle informazioni mediante metodi alternativi, ma sono
stati fallimentari a causa di problemi aggiuntivi, per esempio il layer USB.
Grazie all’aiuto e all’esperienza del Dott. Vittorio Ghini e’ stato trovato
un modus operandi nell’iterazione tra driver e firmware nelle schede integrate
(Mini PCI e PCI Express Mini).
• Il driver tramite un comando comunica al firmware la sua volonta’ di
spedire un pacchetto.
• Il firmware risponde con una avvenuta ricezione del comando.
• A tempo debito il firmware comunica al driver se il comando e’ andato
a buon fine o ne comunica lo stato di errore.
Questa tipologia di interazione permetterebbe di ottenere dei risultati validi.
Controllando nel driver dell’rtl8187 sappiamo che una sezione dedicata ai
comandi non e’ presente. Sono state fatte delle supposizioni riguardo a questa stranezza, la piu’ plausibile riguarda lo spazio lasciato libero all’interno del
pacchetto. Gli sviluppatori del driver1 ci hanno comunicato che nell’URB2
oltre alla dimensione del pacchetto e’ necessario lasciare un ulteriore spazio
libero, ma le motivazioni non sono note nemmeno a loro. La nostra supposizione consiste nell’esistenza di un ulteriore livello tra USB e firmware. Lo
scopo ipotizzato di quest’ulteriore layer e’ il dialogo con il firmware tramite i
comandi necessari. E’ da notare che il chipset da noi preso in considerazione
1
Andrea Merello, studente dell’universita’ di Genova. E’ nel team di sviluppo del driver,
estremamente disponibile, ha fornito importanti delucidazioni in alcuni punti del codice.
2
USB Request Block, pacchetto utilizzato nell’interazione con l’USB layer
35
36
2. Obiettivi e sperimentazione
e’ montato solamente su supporti USB, quindi dovendo tenere presente l’ulteriore incapsulamento aggiunto dal protocollo USB e’ possibile che l’approccio
a comandi sia stato scartato a priori.
Il protocollo USB crea un vero e proprio livello di astrazione ulteriore tra
i device e i relativi driver, per questo si e’ accantonata l’idea dell’utilizzo di
un device USB salvo ulteriori sviluppi.
IPW3945 La ricerca si e’ spostata su una scheda Mini PCI con chipset
Intel ipw3945. I driver esterni al kernel (gli ipw3945) sono basati sul vecchio
stack di rete, per questo una volta divenuti stabili i nuovi iwl3945 (basati sul
nuovo stack) il passaggio e’ stato rapido.
La disponibilita’ di informazioni e l’evoluzione dello stack di rete (Febbraio 2008) ha reso possibile tracciare i dati sensibili all’interno del kernel e
rendere realta’ la migrazione del nostro studio a livelli di astrazione superiori.
ZD1201 Grazie ai progressi e all’indipendenza delle modifiche effettuate
dai driver, l’ultimo device sperimentato e’ un usb basato su chipset Zydas
zd1201. Anche in questo caso esistevano dei driver esterni basati sul vecchio
stack di rete e dei nuovi interni integrati col nuovo stack ieee80211.
L’utilizzo di questa WNIC USB ha permesso di ottenere un giusto compromesso tra informazioni filtrate dal driver e necessita’ iniziale di utilizzare un dispositivo USB. Infatti il driver maschera l’informazione relativa al
retry count rendendo piu’ complicato il bilanciamento di carico o la decisione
di spedire i datagram usando un’interfaccia piuttosto che un altra; fornisce
comunque le informazioni riguardandi l’acknowledgrment ricevuto e quindi
permette l’interattivita’ legata al fusso di dati.
Ulteriori sviluppi (Maggio-Giugno 2008) hanno visto l’uscita del kernel
2.6.25 e 2.6.26 verso i quali migrano il codice e gli sforzi di sviluppo, l’arrivo
di nuovi driver wireless e un generale consolidamento dello stack wireless
nella sua interezza.
Capitolo 3
Parte tecnica
Nelle decisioni prese durante lo studio e la progettazione di questo lavoro si e’ tenuto conto di un fattore determinante: per rendere compatibile
il nostro meccanismo con la moltitudine di schede wireless in commercio,
si e’ evitato di effettuare modifiche al driver, inserendo il nostro codice all’interno dello stack di rete. In questo modo, utilizzando hardware wireless
differenti e quindi avendo driver diversi, il nostro lavoro riesce a funzionare
correttamente, senza dover percio’ effettuare modifiche caso per caso.
N.B.: Nella figura che segue solo nelle funzioni in blu ci sono state modifiche; in verde sono riportati brevi commenti sulle funzioni in questione.
37
38
3. Parte tecnica
Figura 3.1: Panoramica meccanismo cross-layer
3.1 Intel PRO/Wireless 3945ABG
3.1
Intel PRO/Wireless 3945ABG
Pur avendo effettuato modifiche solo allo stack di rete, per poter giustificare le nostre scelte e per comprenderne i motivi occorre prima descrivere
il funzionamento di uno dei driver delle schede wireless in commercio. Per
questo studio sono state prese in considerazione le schede PCI Express, in
particolare l’hardware utilizzato per questo lavoro e’ la Intel PRO/Wireless
3945ABG.
3.1.1
Analisi driver iwl3945
In passato, con il vecchio stack di rete, il driver di questa scheda era
l’ipw3945, esterno al kernel. Oggi pero’ le modifiche dello stack all’interno
del kernel di linux hanno portato ad un passaggio dai driver ipw agli iwlwifi
(integrati nel kernel).
Per rimanere al passo con i developer percio’ la scelta del driver da utilizzare
e’ ricaduta su iwl3945, driver che attualmente si trova all’interno del kernel
di linux da noi utilizzato (versione 2.6.25.6).
Incontro tra firmware e driver Nel file iwl3945-base.c, la funzione
iwl irq tasklet e’ stata identificata come il punto piu’ vicino al firmware ma
ancora all’interno del driver, in cui e’ possibile l’intercettazione dei pacchetti.
In questo punto e’ infatti possibile discriminare se il pacchetto in transito
sia in ricezione o in trasmissione tramite la variabile inta fh, su cui viene
memorizzato il valore di un registro del CSR. Se inta fh vale 0x0 allora
siamo in trasmissione, nel caso sia 0x10000 siamo in ricezione e tutti gli altri
valori rappresentano vari stati dei registri e del masterbus.
Nel corpo di questa funzione compaiono delle code in ricezione e in trasmissione contenenti informazioni sui pacchetti inviati e ricevuti. Per la precisione, lato ricezione e’ presente una sola coda, mentre sono ben 6 quelle
riguardanti la trasmissione. Quest’ultimo particolare impedisce un controllo diretto dei pacchetti inviati per il raggiungimento del nostro obiettivo,
39
40
3. Parte tecnica
perche’ occorre tenere presente che in questo punto le informazioni necessarie per discriminare la coda utilizzata dalle altre in un preciso istante per
un determinato pacchetto sono nascoste.
Ricezione e trasmissione Per evitare ambiguita’, in futuro, si parlera’
di ricezione quando la scheda wireless riceve frame dalla rete, indipendentemente che questi siano dati, ack o frame di management, mentre si parlera’
di trasmissione quando l’applicazione invia dati sulla rete.
Comportamento lato ricezione
N.B. Se non specificato diversamente, i file di cui si parla per individuare
l’implementazione di una funzione sono in drivers/net/wireless/iwlwifi. Il
punto di partenza per avere una corretta e completa panoramica del comportamento lato ricezione del driver e della parte di stack di rete riguardante
l’IEEE802.11 che dialoga con esso consiste nello studio delle funzioni contenute nel file iwl3945-base.c.
Piu’ precisamente occorre partire dalla
seguente funzione:
iwl pci probe Funzione che inizializza molti parametri collegati con il livello fisico, come il livello di rumore del segnale, la potenza del segnale stesso
(ecc.) che per il raggiungimento del nostro obiettivo non sono rilevanti. Al
contrario risultano essere importanti due strutture, iwl priv e ieee80211 hw,
che vengono inizializzate proprio in questo punto e che vengono utilizzate i
svariati punti poiche’ contengono una notevole quantita’ di informazioni sul
livello fisico, sullo stato della comunicazione...
Sono riportati solamente alcuni campi, per la definizione completa vedere
drivers/net/wireless/iwlwifi/iwl-priv.h
1
struct iwl priv {
/∗ i e e e d e v i c e used by g e n e r i c i e e e p r o c e s s i n g code ∗/
3
s t r u c t i e e e 8 0 2 1 1 h w ∗hw ;
struct ieee80211 channel ∗ ieee channels ;
3.1 Intel PRO/Wireless 3945ABG
struct ieee80211 rate ∗ ieee rates ;
5
/∗ temporary frame s t o r a g e l i s t ∗/
struct list head free frames ;
7
int frames count ;
u8 phymode ;
9
int alloc rxb skb ;
v o i d (∗ r x h a n d l e r s [REPLY MAX] ) ( s t r u c t i w l p r i v ∗ p r i v ,
11
s t r u c t i w l r x m e m b u f f e r ∗ rxb ) ;
c o n s t s t r u c t ieee80211 hw mode ∗modes ;
13
/∗ p c i hardware a d d r e s s s u p p o r t ∗/
void
15
iomem ∗ hw base ;
/∗ Rx and Tx DMA p r o c e s s i n g queues ∗/
s t r u c t i w l r x q u e u e rxq ;
17
s t r u c t i w l t x q u e u e txq [IWL MAX NUM QUEUES ] ;
unsigned long s t a t u s ;
19
u32 c o n f i g ;
21
int l a s t r x r s s i ;
/∗ From Rx p a c k e t s t a t i s i t i c s ∗/
int last rx noise ;
/∗ From beacon s t a t i s t i c s ∗/
struct tasklet struct irq tasklet ;
23
};
In include/net/mac80211.h e’ possibile trovare la seguente definizione.
s t r u c t ieee80211 hw {
2
struct ieee80211 conf conf ;
s t r u c t wiphy ∗ wiphy ;
4
s t r u c t w o r k q u e u e s t r u c t ∗ workqueue ;
c o n s t c har ∗ r a t e c o n t r o l a l g o r i t h m ;
6
void ∗ priv ;
u32 f l a g s ;
8
unsigned i n t extra tx headroom ;
int channel change time ;
10
u8 queues ;
41
42
3. Parte tecnica
s8 m a x r s s i ;
s8 m a x s i g n a l ;
12
s8 max noise ;
14
};
Inizialmente viene creata una ieee80211 hw mediante l’invocazione di
ieee80211 alloc hw.
ieee80211 alloc hw Funzione definita in net/mac80211/ieee80211.c,
inizializza alcuni campi necessari per la gestione a livello fisico della comunicazione e alloca spazio per la struttura ieee80211 hw, associandole dei gestori
per svariati eventi, sia in trasmissione che in ricezione. Tra gli altri, i piu’ importanti (per il nostro scopo) sono rx handlers e tx handlers. Questi
campi non sono presenti direttamente nella struttura ieee80211 hw, ma lo
sono in un’altra struttura associate ad essa, molto importante ed usata molto
frequentemente perche’ contenente moltissime informazioni necessarie per il
funzionamento della comunicazione, ieee80211 local.
In net/mac80211/ieee80211 i.h e’ possibile trovare la definizione completa.
struct ieee80211 local {
2
/∗ embed t he d r i v e r v i s i b l e p a r t . ∗ /
s t r u c t i e e e 8 0 2 1 1 h w hw ;
4
c o n s t s t r u c t i e e e 8 0 2 1 1 o p s ∗ ops ;
s t r u c t n e t d e v i c e ∗mdev ;
6
struct tasklet struct tasklet ;
s t r u c t s k b u f f h e a d skb queue ;
8
struct sk buff head skb queue unreliable ;
u n s i g n e d l o n g s t a t e [NUM TX DATA QUEUES ] ;
10
struct ieee80211 tx stored packet
p e n d i n g p a c k e t [NUM TX DATA QUEUES ] ;
12
struct tasklet struct tx pending tasklet ;
i n t s h o r t r e t r y l i m i t ; /∗ d o t 1 1 S h o r t R e t r y L i m i t ∗/
3.1 Intel PRO/Wireless 3945ABG
i n t l o n g r e t r y l i m i t ; /∗ dot11LongRetryLimit ∗/
14
ieee80211 rx handler ∗ rx pre handlers ;
ieee80211 rx handler ∗ rx handlers ;
16
ieee80211 tx handler ∗ tx handlers ;
/∗ dot11CountersTable ∗/
18
u32 dot11TransmittedFragmentCount ;
u32 dot11MulticastTransmittedFrameCount ;
20
u32 dot11FailedCount ;
u32 dot11RetryCount ;
22
u32 d o t1 1Mu ltip l eRetryCo un t ;
u32 dot11FrameDuplicateCount ;
24
u32 dot11ReceivedFragmentCount ;
u32 dot11MulticastReceivedFrameCount ;
26
u32 dot11TransmittedFrameCount ;
u32 dot11WEPUndecryptableCount ;
28
};
Ottenuta un’ieee80211 hw, si ricava l’iwl priv direttamente dal suo campo
priv. Da notare che questo e’ uno dei punti di comunicazione tra il livello
ieee80211 (ieee80211 hw), implementato nel kernel, e il nostro driver specifico
(iwl3945). Utilizzando il campo priv (puntatore a void) dell’ieee80211 hw lo
stack puo’ comunicare con il livello sottostante indipendentemente dal driver
presente; e’ quest’ultimo che salvera’ su priv la struttura specifica del driver
(iwl priv).
iwl rx handle Definita in iwl3945-base.c questa funzione, invocata da
iwl irq tasklet quando si riceve un frame, seleziona il gestore corretto per
l’evento che ha scatenato la sua invocazione. Per poter capire meglio come
si comporta occorre conoscere due elementi molto importanti del driver, la
gestione tramite comandi e le code in trasmissione e ricezione.
43
44
3. Parte tecnica
Utilizzo dei comandi Per la comunicazione tra driver e livello fisico
viene utilizzata un’apposita struttura, l’iwl cmd, che puo’ essere utilizzata
tramite il campo cmd sia in ricezione che in trasmissione.
1
s t r u c t iwl cmd {
s t r u c t iwl cmd meta meta ;
s t r u c t i w l c m d h e a d e r hdr ;
3
union {
u32 f l a g s ;
5
s t r u c t i w l t x c m d tx ;
s t r u c t iwl rxon time cmd rxon time ;
7
struct iwl rxon assoc cmd rxon assoc ;
u8 payload [ 3 6 0 ] ;
9
}
11
attribute
}
attribute
( ( packed ) ) cmd ;
( ( packed ) ) ;
Ad ogni evento il driver associa uno specifico comando, al cui interno sono
contenute le informazione necessarie per la corretta gestione dell’evento. I
campi che ci riguardano sono cmd e hdr.
1
s t r u c t iwl cmd header {
u8 cmd ;
u8 f l a g s ;
3
5
7
/∗
0:7
index in f i f o
∗
8:13
fifo selection
∗ 14:14
b i t i n d i c a t i n g i f t h i s packet r e f e r e n c e s the
∗
’ e x t r a ’ s t o r a g e a t th e end o f t h e memory queue
∗ 15:15
(Rx i n d i c a t i o n )
∗/
9
l e 1 6 sequence ;
11
}
attribute
( ( packed ) ) ;
I possibili comandi dell’iwl sono definiti in iwlwifi/iwl-commands.h, di
seguito la parte relativa alla scheda in esame:
3.1 Intel PRO/Wireless 3945ABG
REPLY ALIVE
45
0x1
REPLY ERROR 0x2
Comandi RXON e QOS
REPLY RXON
0x10
REPLY RXON ASSOC
0x11
REPLY QOS PARAM
0x13
REPLY RXON TIMING
0x14
Supporto Multi-Station
REPLY ADD STA
0x18
REPLY REMOVE STA
0x19
not used
REPLY REMOVE ALL STA 0x1a
not used
RX, TX, LEDs
REPLY 3945 RX
0x1b
REPLY TX
0x1c
REPLY RATE SCALE
0x47
REPLY LEDS CMD
0x48
REPLY TX LINK QUALITY CMD
0x4e
3945 only
3945 only
4965 only
Comandi relativi 802.11h
RADAR NOTIFICATION
0x70
not used
REPLY QUIET CMD
0x71
not used
REPLY CHANNEL SWITCH
0x72
CHANNEL SWITCH NOTIFICATION
0x73
REPLY SPECTRUM MEASUREMENT CMD
0x74
SPECTRUM MEASURE NOTIFICATION
0x75
Power Management
POWER TABLE CMD
0x77
PM SLEEP NOTIFICATION
0x7A
PM DEBUG STATISTIC NOTIFIC
0x7B
46
3. Parte tecnica
Notifiche e comandi relativi alla scansione della rete
REPLY SCAN CMD
0x80
REPLY SCAN ABORT CMD
0x81
SCAN START NOTIFICATION
0x82
SCAN RESULTS NOTIFICATION
0x83
SCAN COMPLETE NOTIFICATION
0x84
Comandi IBSS/AP
BEACON NOTIFICATION
0x90
REPLY TX BEACON
0x91
WHO IS AWAKE NOTIFICATION
0x94
not used
Comandi vari
QUIET NOTIFICATION
0x96
REPLY TX PWR TABLE CMD
0x97
MEASURE ABORT NOTIFICATION
0x99
not used
not used
Configurazione BT
REPLY BT CONFIG
0x9b
Notifiche e comandi RF-KILL
REPLY CARD STATE CMD
0xa0
CARD STATE NOTIFICATION
0xa1
Notifiche Beacon persi
MISSED BEACONS NOTIFICATION
0xa2
REPLY MAX
0xff
Tabella 3.1: Comandi iwl
3.1 Intel PRO/Wireless 3945ABG
Code in trasmissione e ricezione Attraverso la struttura iwl priv
si possono ottenere i frame inviati e ricevuti, grazie alla presenza dei campi
iwl rx queue e iwl tx queue. In queste code vengono memorizzati i riferimenti
ai frame di cui il driver deve ancora analizzare le informazioni: l’iwl rx queue
viene utilizzata per ottenere i frame ricevuti. iwl tx queue invece ha una
struttura un po’ diversa, perche’ attraverso queste code viene fatta un’associazione tra i frame da inviare e i comandi corrispondenti. Quando occorre
trasmettere un frame, questo viene memorizzato su una delle varie code
iwl tx queue, al cui interno verra’ memorizzato il comando con cui, come
sara’ spiegato successivamente, si riuscira’ a riottenere le informazioni sul
frame nel momento in cui si ricevera’ l’ack.
1
struct iwl tx queue {
struct iwl queue q ;
s t r u c t i w l t f d f r a m e ∗bd ;
3
s t r u c t iwl cmd ∗cmd ;
s t r u c t i w l t x i n f o ∗ txb ;
5
}
La funzione iwl rx handle scorre le varie code di ricezione presenti nell’iwl priv, da cui estrae un skb (socket buffer), struttura che viene utilizzata
per il trasferimento dei dati da inviare e dei dati accessori tra i vari livelli
gerarchici. Occorre tener presente che, mentre in passato un skb conteneva
direttamente in modo esplicito gli header dei vari protocolli di comunicazione,
ad oggi, con le piu’ recenti versioni del kernel di linux, cio’ non e’ piu’ vero.
Infatti nei nuovi kernel all’interno di un skb e’ presente un puntatore all’header corrispondente allo stadio in cui e’ attualmente il pacchetto e che viene
spostato man mano che si va da un protocollo di comunicazioni all’altro. Dal
campo data di questo skb si ottiene un iwl rx packet, una struttura contenente un campo con l’header del comando e una union in cui vengono salvate
le informazioni vere e proprie ottenute dal livello fisico. A questo punto, in
base al tipo di comando associato all’iwl rx packet viene invocato il gestore
adatto. Nel nostro caso, siamo interessati a sapere quando riceviamo un ack
47
48
3. Parte tecnica
di un nostro frame: nel momento in cui ci si imbatte nel comando REPLY TX
significa che e’ stato ricevuto un ack; in questo caso il gestore che viene invocato e’ iwl rx reply tx. Inoltre, sempre in questo caso, viene invocata la
funzione iwl tx cmd complete (che verra’ discussa a breve).
iwl rx reply tx Definita in iwl3945-base.c gestisce la ricezione degli ack.
Da un skb, lo stesso socket buffer associato al comando REPLY TX (vedi
funzione iwl rx handle), estrae secondo le modalita’ gia’ descritte in precedenza un iwl rx packet e di seguito l’header del comando corrispondente.
Da quest’ultimo vengono estratti due indici, txq id e index. Il primo indica la coda in trasmissione su cui e’ salvato il frame che e’ stato appena
acked; il secondo e’ un indice interno alla coda che verra’ utilizzato nella funzione iwl tx queue reclaim. Dalla coda in trasmissione (iwl tx queue)
contenuta nell’iwl priv e indicata dal txq id, si ottiene la seguente struttura
(sono riportati solamente i campi di nostro interesse):
struct ieee80211 tx status {
struct ieee80211 tx control control ;
2
u8 f l a g s ;
bool e x c e s s i v e r e t r i e s ;
4
u8 r e t r y c o u n t ;
int ack signal ;
6
}
Su questa struttura vengono salvate informazioni molto importanti sul
frame inviato, ottenute dall’iwl tx resp contenuto nell’iwl rx packet di prima.
Proprio questo e’ il punto piu’ a basso livello in cui si e’ in grado di sapere
se un frame inviato e’ acked oppure no. Infatti dall’iwl rx packet di prima e’
possibile ricavare il retry count del frame inviato e soprattutto il campo che
indica se l’ack e’ stato ricevuto: questo campo (status) e’ costituito da 32
bit e l’informazione a noi necessaria e’ contenuta nel bit meno significativo
(se messo ad 1 significa che il frame e’ acked). Quest’ultimo dato in particolare viene memorizzato nel campo flags della struttura iee80211 tx status.
3.1 Intel PRO/Wireless 3945ABG
Gli altri campi dell’ieee80211 tx status vengono impostati in questo punto,
sempre con le informazioni ottenibili tramite l’iwl rx packet.
1
t x s t a t u s −>r e t r y c o u n t = t x r e s p −>f a i l u r e f r a m e ;
t x s t a t u s −>queue number = s t a t u s ;
3
t x s t a t u s −>q u e u e l e n g t h = t x r e s p −>b t k i l l c o u n t ;
t x s t a t u s −>q u e u e l e n g t h |= t x r e s p −>f a i l u r e r t s ;
5
t x s t a t u s −>f l a g s = i w l i s t x s u c c e s s ( s t a t u s ) ?
IEEE80211 TX STATUS ACK : 0 ;
Prima di terminare, la funzione invoca iwl tx queue reclaim(che verra’ analizzata in seguito)
iwl tx cmd complete Definita in iwl3945-base.c viene utilizzata per liberare i buffer che non vengono piu’ utilizzati. Come gia’ spiegato in precedenza estrae dall’iwl rx packet presente nel campo data dello skb gli indici
per individuare le informazioni sul comando relativo al frame appena acked.
Come in iwl rx reply tx, viene invocata la funzione iwl tx queue reclaim.
iwl tx queue reclaim Definita in iwl3945-base.c viene utilizzata per liberare le code in trasmissione che contengono i frame per i quali l’ack e’
gia stato ricevuto e quelli per i quali, invece, data la scadenza dei timeout, non lo riceveremo mai. Le code contenenti le informazioni su questi
frame, prima di venir deallocate, vengono passate come parametro alla funzione iwl txstatus to ieee. Quando tutte le code non utilizzate sono state
liberate, viene verificata la disponibilita’ dello spazio minimo necessario per
sbloccare la trasmissione di frame in attesa.
iwl txstatus to ieee Definita in iwl3945-base.c esegue solamente una distinzione tra eventi scatenati da interrupt e non. Nel primo caso viene invocata
ieee80211 tx status irqsafe, nel secondo ieee80211 tx status.
ieee80211 tx status irqsafe Definita in net/mac80211/ieee80211.c, estrae dallo skb l’oggetto per cui si e’ messo in moto tutto questo meccan-
49
50
3. Parte tecnica
ismo (e’ arrivato l’ack oppure e’ scaduto il timeout), ne imposta il tipo a
IEEE80211 TX STATUS MSG e schedula ieee80211 tasklet handler.
ieee80211 tasklet handler Definita in net/mac80211/ieee80211.c, ha due
comportamenti diversi in base al motivo per cui e’ stata richiamata. Nel caso
in cui si e’ ricevuto un frame dati, allora il campo pkt type dello skb sara’
stato impostato in precedenza con il valore IEEE80211 RX MSG e la funzione
invochera’ ieee80211 rx. Ci si trova invece nel secondo caso quando si riceve
un ack oppure quando e’ scaduto il timeout in trasmissione e si considera
non acked il frame inviato. In queste due situazioni il campo pkt type dello skb viene impostato a IEEE80211 TX STATUS MSG (vedi funzione
ieee80211 tx status irqsafe) e viene invocata la funzione ieee80211 tx status.
ieee80211 tx status
Quando la scheda wireless riceve un ack di un frame
inviato in precedenza oppure quando scade il timeout per la ricezione di un
ack relativo ad un frame gia’ inviato, viene invocata la funzione in questione,
definita in net/mac80211/ieee80211.c. All’interno del corpo di questa funzione avviene il controllo del numero di volte che il frame e’ stato inviato
(retry count) e soprattutto la verifica del fatto che il frame sia acked oppure
no, controllando semplicemente il valore memorizzato nel campo flag della
struttura ieee80211 tx status. Se il valore memorizzato e’ IEEE80211 TX STATUS ACK
allora significa che si e’ ricevuto l’ack, altrimenti si considera perso il frame inviato. Si rammenta che, come gia’ detto sopra, questo campo viene impostato
nel corpo della funzione iwl rx reply tx.
ieee80211 rx Definita in net/mac80211/rx.c viene invocata quando si
riceve un frame dati. Visto che non viene coinvolta quando si riceve un ack,
non e’ necessario conoscere in dettaglio il suo comportamento. Si sappia
solamente che gestisce la ricezione dei frame data e managment, invocando
gli opportuni gestori.
3.1 Intel PRO/Wireless 3945ABG
Comportamento lato trasmissione
Lato trasmissione sono riportate solamente le funzioni piu’ rilevanti dal
punto di vista del nostro lavoro, presenti all’interno del driver e nella parte di
stack di rete che implementa l’IEEE802.11. Per quello che riguarda la parte
controllata dal driver, le due funzioni principali sono le seguenti, il cui corpo
si puo’ trovare nel file iwl3945-base.c
iwl mac tx Lato trasmissione, il punto di passaggio tra lo stack e il driver
avviene tramite l’invocazione da parte del primo della funzione iwl mac tx.
Questa, fatti alcuni controlli trascurabili (per quello che ci riguarda) invoca
iwl tx skb.
iwl tx skb In questa funzione viene associato al frame da inviare il comando REPLY TX che poi, come gia’ detto, servira’ lato ricezione per sapere
se e’ stato ricevuto l’ack. iwl tx skb si occupa anche di impostare correttamente il valore del campo sequence dell’header del comando, inserendoci
gli indici della coda in trasmissione utilizzata per il frame e la sua posizione
all’interno della coda (questi valori saranno poi utilizzati lato ricezione per
l’associazione tra il comando e il frame inviato, come spiegato nella funzione
iwl rx reply tx ). Altra cosa rilevante fatta dalla funzione e’ la sistemazione
dello skb contenente il frame e del suo header, come i campi len, flag...
Per quello che riguarda la parte di kernel che implementa il protocollo
IEEE802.11, le funzioni che destano interesse per il raggiungimento del nostro
obiettivo sono le seguenti:
ieee80211 tx Definita in net/mac80211/tx.c, viene invocata ogni qualvolta ci sia un frame da inviare. In particolare, per poter inviare il frame la
funzione richiama i gestori presenti in local->tx handler. In questo campo,
all’interno di ieee80211 alloc hw, vengono memorizzate le seguenti funzioni:
51
52
3. Parte tecnica
ieee80211 tx handler ieee80211 tx handlers [ ] = {
ieee80211 tx h check assoc ,
2
ieee80211 tx h sequence ,
ieee80211 tx h ps buf ,
4
ieee80211 tx h select key ,
ieee80211 tx h michael mic add ,
6
ieee80211 tx h fragment ,
ieee80211 tx h encrypt ,
8
ieee80211 tx h rate ctrl ,
ieee80211 tx h misc ,
10
ieee80211 tx h load stats ,
NULL
12
};
ieee80211 tx h sequence Questa funzione, presente tra i gestori in trasmissione, viene definita in net/mac80211/tx.c e viene invocata ogni volta che
occorre inviare un frame per poterne incrementare il sequence number.
3.2
Internet Protocol
Una volta ottenuta l’associazione tra acknowledgement e i frame IEEE802.11
trasmessi, occorre riuscire ad associare il frame in questione con il pacchetto
ip che trasporta (o con il frammento di pacchetto ip nel caso ci sia frammentazione). Essendo il futuro legato all’IPv6 e’ necessario dedicarsi a questo
protocollo, anche se, per i motivi che verranno descritti in questa sezione, il
nostro lavoro sfrutta il suo predecessore, l’IPv4.
A livello IP i problemi da risolvere sono due: il primo, come gia’ detto, e’ associare il datagram ip al frame IEEE802.11, il secondo invece consiste nell’ottenere, a partire da un pacchetto udp, le informazioni desiderate
sul datagram ip che lo racchiude, in modo tale da poter collegare il frame
IEEE802.11 con il pacchetto udp. Per risolvere la seconda problematica, e’
3.2 Internet Protocol
stato utilizzato il seguente escamotage: nel punto in cui si estraggono le informazioni sul datagram ip, vengono estratte anche quelle collegate al pacchetto
udp. All’applicazioni vengono poi passati i dati desiderati sul flusso udp con
la granularita’ dei datagram ip (ad ogni datagram ip vengono trasmesse le
informazioni). Risolvendo, come verra’ spiegato successivamente, l’associazione tra i frame 80211 e i datagram ip, possiamo in questo modo collegare
i pacchetti udp con i singoli frame, come desiderato.
3.2.1
UDP over IPv6
Utilizzando questo protocollo l’associazione tra frame IEEE802.11 e datagram IP trova un grande ostacolo. Nel passaggio tra IPv4 e IPv6 vi sono state
molte modifiche, sia per quello che riguarda i campi dati che l’header. Proprio in quest’ultimo vi e’ stato il cambiamento che ci ha fatto abbandonare
l’IPv6: nel suo header e’ stato tolto il campo ID presente invece nell’IPv4.
Figura 3.2: Struttura IPv6 Header
Percio’, non sapendo come poter identificare un pacchetto IPv6, la nostra
53
54
3. Parte tecnica
applicazione, almeno per il momento, utilizza l’IPv4. La risoluzione dell’associazione tra pacchetti UDP, IPv6 e frame IEEE802.11 viene lasciata a future
modifiche dell’applicazione.
3.2.2
UDP over IPv4
Nel kernel buona parte delle funzioni relative all’IPv4 si trovano in /net/ipv4.
Una spiegazione dettagliata delle funzioni utili per questo lavoro verra’ riportata successivamente, quando verranno presenta le nostre modifiche
effettuate a queste funzioni.
L’idea base per associare un pacchetto ip con il o i frame IEEE802.11 che
lo trasportano e’ di sfruttare gli id presenti nei due header, che forniscono
un’appiglio naturale per identificare i due oggetti e per collegarli tra di loro.
Capitolo 4
Realizzazione-Implementazione
4.1
Funzionamento dell’applicazione
4.1.1
Spiegazione generale
Lato trasmissione, ogni volta che viene inviato un datagram ip, all’utente
che l’ha inviato viene comunicato il suo identificativo. All’interno dell’applicazione, quando si e’ passati al livello IEEE802.11 e l’header di questo
protocollo e’ stato inserito nel pacchetto, ma prima che questo venga crittato (nel caso ci sia crittazione) vengono estratte da quest’ultimo le seguenti
informazioni:
• id datagram ip
• porta sorgente
• campo more fragment dell’header IEEE802.11 (indica se al frame in
questione ne seguono altri che portano al loro interno frammenti dello
stesso pacchetto ip)
• id frame IEEE802.11 (servira’ come identificativo dei dati estratti)
Una volta ottenute, queste informazioni vengono memorizzate in un’apposita struttura. Quando in ricezione viene eseguito il corpo della funzione
55
56
4. Realizzazione-Implementazione
ieee80211 tx status, come gia’ detto in precedenza, puo’ voler dire che e’
stato ricevuto l’ack di un frame inviato oppure che, a causa della scadenza
dei timeout, il frame inviato deve essere considerato non ricevuto dall’access
point. All’interno di questa funzione vengono estratte le informazioni sull’ack inviato dall’access point, il retry count, il filtered count e l’id del frame
IEEE802.11 inviato. Proprio tramite a questo identificativo si collegano le
informazioni ottenute in ricezione con i dati estratti in trasmissione di cui si
e’ parlato in precedenza. In questo modo si riesce a stabilire se un determinato datagram ip (e quindi pacchetto udp) ha ricevuto l’ack dall’access point
oppure no, piu’ altre informazioni di corredo come il retry count.
4.1.2
Approfondimento: lato trasmissione
Livello udp-ip
Lato trasmissione, il pacchetto udp viene identificato mediante il datagram ip che lo trasporta, utilizzando il suo id. Questo, che viene memorizzato in 16 bit dell’header ip, viene configurato dalla funzione ip select ident,
definita in include/net/ip.h. Questa si comporta in tre modi diversi: se la
frammentazione dei datagram non e’ prevista, nel caso in cui sia impostato il campo daddr (indirizzo destinazione) del socket utilizzato per la comunicazione, l’id viene incrementato direttamente, altrimenti viene messo
a 0. Nel caso in cui invece ci sia la frammentazione attiva, viene invocata
ip select ident. Questa funzione, definita in net/ipv4/route.c, a sua volta si
occupera’ di impostare adeguatamente l’identificativo del datagram ip. Abbiamo osservato pero’ che l’id viene di norma messo a 0 da ip select ident.
Quindi, per poter fare l’associazione datagram ip con i dati raccolti dalla
nostra applicazione e’ stata modificata la funzione in questione nel seguente
modo: nel punto in cui originariamente l’id veniva impostato a 0, e’ stata
inserita l’invocazione della funzione
ip select ident. In questo modo l’id del
datagram ip viene sempre impostato ad un valore univoco, rendendo possibile l’associazione tra frame IEEE802.11 e pacchetto ip tramite i relativi
4.1 Funzionamento dell’applicazione
57
identificativi.
A livello udp e’ stata modificata la funzione udp push pending frames
definita in /net/ipv4/udp.c, che viene richiamata da udp sendpage quando
si vuole trasmettere un flusso di dati (con udp).
Questa crea una variabile
be16 ipdgramid, nella quale verra’ successiva-
mente mantenuta l’informazione sull’id del datagram ip. Oltre a questo la
funzione invoca udp push pending frames get ipdgramid passandole l’indirizzo di ipdgramid. In questo punto e’ stato spostato il corpo originario di
udp push pending frames, con l’aggiunta di questa riga di codice:
err = ip_push_pending_frames_get_ipdgramid( sk, p_ipdgramid );
dove err sara’ il valore di ritorno della funzione.
Questa funzione, definita in net/ipv4/ip output.c, combina i vari frammenti ip presenti nel socket, li accorpa in un unico datagram ip, sistemando anche i vari campi del skb e dell’header ip e li inoltra verso i livelli successivi per la loro trasmissione (lo stesso comportamento che aveva
ip push pending frame,
la
quale
ora
invoca
solamente
ip push pending frame get ipdgramid). Inoltre all’interno della funzione avviene il salvataggio dell’id del datagram ip nella nostra variabile ipdgramid,
dopo l’invocazione di ip select ident.
Un’altra funzione modificata (sempre in udp.c) e’ udp sendmsg, la quale ora
si comporta come udp push pending frames.
IEEE802.11
Nella parte di kernel che implementa questo protocollo ci sono state le
modifiche piu’ sostanziali. Prima pero’ di parlarne e’ meglio introdurre le
strutture utilizzate per la raccolta e la gestione dei dati.
rtlkill info Per memorizzare le informazioni estratte dai frame trasmessi in
attesa di aver una risposta affermativa o negativa riguardo l’ack, e’ stata utilizzata una lista di rtlkill info, una struttura introdotta da noi in ieee80211.c
e definita come segue:
58
1
4. Realizzazione-Implementazione
struct r t l k i l l i n f o {
l e 1 6 i d ; /∗ s e q u e n c e i d frame 8 0 2 . 1 1 ∗/
s t r u c t packet datagram info ;
3
s t r u c t timespec tx time ;
s t r u c t timespec rx time ;
5
s t r u c t r t l k i l l i n f o ∗ next ;
7
};
• Il campo id viene utilizzato per distinguere tra loro i vari rtlkill info e
consiste nel sequence number dei frame IEEE802.11.
• Il campo datagram info e’ di tipo packet, struttura inserita da noi e
definita in ieee80211.c. La descrizione e’ riportata a seguito di questo
elenco.
• Il campo tx time viene utilizzato per memorizzare il tempo di sistema
nel momento in cui il frame viene inviato (viene memorizzato questo
valore quando vengono estratte le altre informazioni dagli header ip e
udp).
• Il campo rx time viene utilizzato per memorizzare il tempo di sistema
nel momento in cui e’ possibile sapere se il frame e’ acked oppure no
(coincide con l’esecuzione del corpo della funzione ieee80211 tx status).
• Il campo next e’ il puntatore al prossimo rtlkill info (e’ uguale a NULL
nel caso quest’ultimo non ci sia).
N.B. I campi tx time e rx time sono utilizzati solamente per uno scopo
statistico sulle tempistiche.
1
s t r u c t packet {
u8 acked ; /∗ acked , not acked , no ack r e q u e s t e d
3
o r ack f i l t e r e d ∗/
u8 r e t r y c o u n t ; /∗ r e t r y c o u n t e r ∗/
5
u n s i g n e d l o n g f i l t e r e d c o u n t ; /∗number o f t i m e s
4.1 Funzionamento dell’applicazione
59
t h e frame has
been f i l t e r e d ∗/
7
u8 fragment ; /∗ 0 i f th e l a s t fragment ,
1 o t h e r w i s e ∗/
9
b e 1 6 i p i d ; /∗ i p p a c k e t i d ∗/
b e 1 6 u d p p o r t ; /∗ s o u r c e udp p o r t ∗/
11
};
La lista di rtlkill info e’ organizzata in questo modo: ogni elemento nella
lista mantiene, come gia’ detto, un puntatore al successivo. Il primo elemento della lista viene raggiunto tramite il campo next della sentinella, un
rtlkill info definito come segue:
static struct r t l k i l l i n f o sentinel =
2
{0 ,
{0 ,0 ,0 ,0 ,0 ,0} ,
4
{0 ,0} ,
{0 ,0} ,
6
NULL}
In questo modo la sentinella rimane in memoria costantemente; di questo
rtlkill info viene utilizzato solamente il campo next per individuare il primo
rtlkill info contenente informazioni sui frame inviati.
Assieme alla definizione di queste strutture sono state inserite funzioni
accessorie che agiscono sulle code di rtlkill info:
struct r t l k i l l i n f o ∗ r t l k i l l i n f o s e a r c h (
2
l e 1 6 id ) ;
void r t l k i l l i n f o a d d ( s t r u c t r t l k i l l i n f o ∗ p a c k e t i n f o ) ;
void r t l k i l l i n f o r e m o v e ( s t r u c t r t l k i l l i n f o ∗ p a c k e t i n f o ) ;
Terminata l’introduzione sulle strutture inserite, ora e’ possibile descrivere le modifiche effettuate per far funzionare correttamente l’applicazione.
ieee80211 tx h sequence In questa funzione, descritta in precedenza, e’
stata inserita l’invocazione di una nostra funzione, rtlkill extract pkt info
60
1
4. Realizzazione-Implementazione
/∗ ∗∗∗ RTLKILL ∗∗∗ ∗/
i f ( r e q u i r e d i p l o c a l e r r o r n o t i f y ( tx−>skb−>sk ) ) {
i n t r e t = r t l k i l l e x t r a c t p k t i n f o ( hdr ) ;
3
}
5
/∗ ∗∗∗ RTLKILL ∗∗∗ − end ∗/
rtlkill extract pkt info
Questa funzione ha lo scopo di analizzare il pac-
chetto che sta per essere inviato (la funzione richiede come parametro l’header
IEEE802.11).
Da questo header si ottiene il sequence number del frame IEEE802.11,
che, come gia detto in precedenza, verra’ utilizzato per associare in ricezione
le informazioni sulla trasmissione del frame al datagram ip. Nel caso in
cui il frame IEEE802.11 contenga al suo interno un pacchetto ip allora
vengono estratte dal datagram le informazioni collegate ai protocolli udp
e ip mediante l’invocazione di get udp info, di cui si parla qui di seguito.
Queste informazioni, assieme al tempo di sistema ottenuto tramite CURRENT TIME vengono salvate in un rtlkill info, che verra’ aggiunto alla lista
di rtlkill info. N.B.: Viene creato un rtlkill info solamente nel caso in cui il
frame IEEE802.11 contenga al suo interno un datagram ip, che a sua volta
trasporta un pacchetto udp. In tutti gli altri casi la funzione termina senza
modificare l’ambiente.
get udp info Questa funzione analizza gli header ip e udp, estraendone le
seguenti informazioni:
• Indirizzo sorgente (header ip)
• Indirizzo destinazione (header ip)
• Porta sorgente (header udp)
• Porta destinazione (header udp)
• Identificativo datagram ip (header ip)
4.1 Funzionamento dell’applicazione
61
• Dimensione dati trasportati (header ip)
• Byte indicante la presenza di altri frammenti ip dopo quello in questione
• Offset del campo data dal primo datagram ip della sequenza
Queste informazioni vengono salvate all’interno dei parametri della funzione (sono dei puntatori), in modo tale da poter essere salvati nel rtlkill info.
4.1.3
Approfondimento: lato ricezione
ieee80211 tx status Come gia’ detto in precedenza, le informazioni necessarie per sapere se un frame ha ricevuto l’ack dall’access point si possono
trovare nel corpo della funzione ieee80211 tx status, al cui interno percio’
abbiamo inserito l’invocazione della nostra funzione rtlkill info response. La
chiamata avviene solamente se il controllo “if (required ip local error notify(sk)”
da esito positivo: questo succede quando sul socket utilizzato per la comunicazione e’ stata invocata una “recvmsg” sulla coda di errori (MSG ERRQUEUE);
per maggiori dettagli vedere la sezione “Utilizzo applicazione”, comunque per
ora basti sapere che per poter utilizzare la nostra applicazione questa recvmsg
e’ necessaria.
rtlkill info response Questa funzione estrae dall’header IEEE802.11 e dal
parametro ieee80211 tx status le informazioni sul retry count, sul fatto che
il frame inviato sia acked oppure no con le stesse modalita’ della funzione
ieee80211 tx status, descritte in precedenza nella sezione “Comportamento
lato ricezione”. Inoltre viene estratto dall’header IEEE802.11 il sequence
number del frame, utilizzato per ritrovare nella coda degli rtlkill info le informazioni memorizzate in precedenza lato trasmissione sul frame. Ottenuto
il rtlkill info corretto, si uniscono tutti i dati ottenuti, che, oltre a venir
memorizzati nel rtlkill info, vengono passati al mittente del frame tramite
l’invocazione di ip local error notify, che verra’ spiegata fra poco. Nel caso
in cui si stia facendo debug (RTLKILL DEBUG definito) viene memorizzato
62
4. Realizzazione-Implementazione
sul rtlkill info il tempo di sistema tramite CURRENT TIME e viene invocata rtlkill info take response, che non fa altro che stampare sul log di sistema
tutti i dati ottenuti. Una volta che le informazioni a cui siamo interessati
sono passate al mittente del frame, il rtlkill info diviene inutile, percio’, prima di terminare, la funzione dealloca lo spazio utilizzato per memorizzare il
rtlkill info tramite rtlkill info remove, che si occupa anche di toglierlo dalla
coda degli rtlkill info.
1
v o i d i p l o c a l e r r o r n o t i f y ( s t r u c t s o c k ∗ sk , i n t s e n t ,
3
b e 3 2 daddr ,
b e 1 6 dport ,
b e 3 2 saddr ,
be16 sport ,
b e 1 6 ipdgramid ,
u16 f r a g m e n t d a t a l e n , u16 f r a g m e n t o f f s e t ,
5
u8 more fragment ){
...
7
s e r r = SKB EXT ERR( skb ) ;
...
9
s e r r −>e e . e e e r r n o = 0 ;
/∗ s u c c e s s ∗/
s e r r −>e e . e e o r i g i n = SO EE ORIGIN LOCAL NOTIFY ;
11
s e r r −>e e . e e t y p e = s e n t ; /∗ 1 s e n t , 0 not s e n t ∗/
s e r r −>e e . e e c o d e = more fragment ; /∗ more fragment ∗/
13
s e r r −>e e . e e p a d = 0 ;
s e r r −>e e . e e i n f o = ipdgramid ;
/∗ i d datagram ∗/
15
s e r r −>e e . e e d a t a = f r a g m e n t o f f s e t +
( ( ( u32 ) f r a g m e n t d a t a l e n ) < <16);
17
s e r r −>a d d r o f f s e t = ( u8 ∗)& iph−>daddr −
s k b n e t w o r k h e a d e r ( skb ) ;
19
s e r r −>p o r t = dport ;
21
...
Tramite l’invocazione di questa funzione tutti i dati utili vengono salvati
nella memoria dei socket utilizzata per la comunicazioni di errori (questo
4.1 Funzionamento dell’applicazione
canale di comunicazione viene richiesto tramite required ip local error notify):
• sk e’ il socket utilizzato
• success e’ un intero che puo’ assumere i seguenti valori: 0 se non si e’
ricevuto l’ack del frame inviato, 1 se l’ack e’ stato ricevuto, 2 se non ci
sono state execessive retry
• indirizzo di destinazione del frame
• porta di destinazione
• indirizzo sorgente
• porta sorgente
• id del datagram ip
• lunghezza datagram
• offset datagram (nel caso un pacchetto sia stato suddiviso in piu’ datagram)
• flag utile se il pacchetto da trasmettere e’ stato suddiviso in piu’ datagram; indica se il frame e’ l’ultimo oppure se ne seguiranno altri.
Come verra’ spiegato nella sezione “Utilizzo applicazione” l’utente che
richiede il servizio della nostra applicazione dovra’ leggere sul canale d’errore
dei socket le informazioni richieste.
4.1.4
Utilizzo applicazione
L’utente che voglia utilizzare la nostra applicazione per avere informazioni
sulla ricezione da parte dell’access point dei pacchetti udp inviati deve comunicare allo stack di rete la necessita’ di monitorare i pacchetti spediti.
63
64
1
4. Realizzazione-Implementazione
i n t OptVal = 1 ;
r i s = s e t s o c k o p t ( s o c k e t f d , IPPROTO IP , IP RECVERR,
( char ∗)&OptVal , s i z e o f ( OptVal ) ) ;
3
Syscall
Per rendere funzionante l’appplicazione e’ stata introdotta una libreria
(che deve essere compilata per poter essere utilizzata) con all’interno una
nuova socket system call, sendmsg get ipdgramid.
1
#d e f i n e SYS SENDMSG GET IPDGRAMID
18;
...
3
s o c k e t c a l l ( s e n d m s g g e t i p d g r a m i d ,SENDMSG GET IPDGRAMID)
All’invocazione di questa syscall viene eseguita sys socketcall (socket.c)
la quale invoca la seguente funzione da noi scritta:
1
a s m l i n k a g e l o n g s y s s e n d m s g g e t i p d g r a m i d ( i n t fd ,
s t r u c t msghdr
3
unsigned f l a g s ,
u s e r ∗msg ,
be16 ∗ p ipdgramid ) ;
Questa, la cui definizione e’ presente in include/linux/syscall.h e il cui corpo si trova in net/socket.c, invoca sock sendmsg get ipdgramid, passandole
l’indirizzo del parametro p ipdgramid, sul quale l’utente protra’ poi leggere
l’identificativo del datagram ip. sock sendmsg get ipdgramid richiama a sua
volta sock sendmsg get ipdgramid, con le modalita’ gia’ descritte per quello che riguarda p ipdgramid. In quest’ultima, anch’essa definita all’interno
di socket.c, e’ presente la segente riga di codice:
1
r e t=sock−>ops−>s e n d m s g g e t i p d g r a m i d ( i o c b , sock , msg ,
s i z e , p ipdgramid ) ;
La variabile sock altro non e’ che il socket utilizzato per la trasmissione, mentre tramite il campo ops (di tipo proto op) si raggiunge la funzione memorizzata nel campo sendmsg get ipdgramid. Questo campo e’ stato aggiun-
4.1 Funzionamento dell’applicazione
65
to da noi in proto ops, oltre che in inet sockraw ops e inet dgram ops. In
tutti i casi la funzione che viene richiamata e’ inet sendmsg get ipdgramid,
definita in /net/ipv4/af inet, che richiama udp sendmsg get ipdgramid attraverso il campo sk prot della struttura sock presente nel socket utilizzato
per la trasmissione. Nel nostro caso, facendo traffico udp, in sk prot ci sara’
memorizzato un udp prot, struttura nel quale e’ stato aggiunto un campo
sendmsg get ipdgramid in cui viene appunto scritto il nome della funzione
udp sendmsg get ipdgramid. Quest’ultima, dopo la nostra modifica, oltre a
preparare
la
trasmissione
del
pacchetto
udp,
invoca
udp push pending frames get ipdgramid (continuando il passaggio per indirizzo di p ipdramid), la quale, coma gia’ detto nella sezione “Livello udp-ip”
invoca ip push pending frames get ipdgramid (per maggiori dettagli vedere
la sezione apposita, si rammenta solamente che attraverso questo percorso
viene memorizzato su p ipdramid l’id del pacchetto ip trasmesso).
La
syscall
in
questione
puo’
essere
richiamata
invocando
sendmsg get ipdgramid, la quale permette di sapere l’ID del pacchetto IP
spedito (quarto parametro) e se il tentativo di spedizione e’ avvenuto con
successo.
i n t r i s = s e n d m s g g e t i p d g r a m i d ( s o c k e t f d , &msgHeader ,
MSG NOSIGNAL , &i d ) ;
2
Un’altra operazione fondamentale che deve essere fatta dall’utente per
poter utilizzare l’applicazione e’ la seguente:
recvmsg ( s o c k e t f d , msg , MSG ERRQUEUE) ;
Il primo parametro e’ l’identificativo del socket che si sta utilizzando per
la comunicazione, il secondo e’ un puntatore ad un msghdr, all’interno del
quale verranno salvati i dati richiesti, mentre il terzo parametro serve per
poter fare la receive sul canale d’errore del socket.
Nel caso in cui la funzione restituisca un valore maggiore o uguale a 0 e non
siano segnalati errori, la nostra applicazioni fornisce informazioni all’utente,
che le puo’ estrarre in questo modo dalla variabile msg: mediante le funzioni
66
4. Realizzazione-Implementazione
CMSG FIRSTHDR e CMSG NXTHDR si ottengono i vari header dei dati di corredo,
detti ancillary data. In questi header ci sono informazioni sui dati, sui vari
protocolli di comunicazioni adottati ... Le vere e proprie informazioni che
ci interessano invece devono essere estratte tramite CMSG DATA, trattando il
valore di ritorno come un puntatore a sock extended err, struttura i cui campi
conterranno le nostre informazioni.
1
s t r u c t s o c k e x t e n d e d e r r ∗ ee ;
e e = ( s t r u c t s o c k e x t e n d e d e r r ∗)CMSG DATA( c ) ;
3
...
i p i d=ntohs ( ee−>e e i n f o ) ;
5
m o r e f r a g=ee−>e e c o d e ;
f r a g l e n = ( ( ( u32 ) ( ee−>e e d a t a )) > >16);
7
o f f s e t = ( ( ( ( u32 ) ( ee−>e e d a t a ))<<16)>>16);
Capitolo 5
Valutazione
Lo studio di questo meccanismo cross-layer e’ stato integrato con delle
prove pratiche in cui si e’ verificato il corretto funzionamento della nostra
applicazione in varie situazioni. Per ragioni pratiche legate alla disponibilita’,
si e’ deciso di utilizzare come hardware wireless una antenna usb zd1211rw,
chipset 1211. Avendo apportato modifiche solamente nello stack di rete,
l’applicazione e’ in grado di funzionare anche con driver diversi dall’iwl3945.
5.1
Metriche
Nelle varie prove effettuate sono stati analizzati due fattori:
• affidabilita’: e’ stato verificato che le informazioni sugli ack dei frame
inviati fossero corrette ed e’ stata inoltre osservata la completezza delle
informazioni, per conoscere in quali scenari la nostra applicazione fornisce il massimo dei dati e in quali invece viene ridotta la quantita’ di
informazioni.
• tempistiche: e’ stato analizzato il ritardo presente tra il momento in
cui un frame viene inviato e l’istante in cui si viene a conoscenza del
fatto che il pacchetto sia acked oppure no.
67
68
5. Valutazione
5.1.1
Parametri
Per avere dati completi sono state effettuate piu’ prove, variando alcuni
parametri:
• tipologia rete: i test sono stati realizzati con:
– rete non cifrata
– cifratatura WEP
– cifratura WPA express: chiave WPA-PSK, TKIP.
• traffico di background:
– assenza di traffico di background: rete in cui c’e’ solo un utente
che invia tramite access point ad un altro utente.
– con traffico di background: 10 utenti che tramite lo stesso access
point occupano la rete, facendo ping e inviandosi tra di loro dei
dati. All’incirca la quantita’ di traffico durante ogni prova e’ di
1Mbyte.
• dimensione dati inviati:
– pacchetti da 1024 byte (nessuna frammentazione)
– pacchetti da 2048 byte (con frammentazione: per trasmettere ogni
pacchetto sono necessari due frame IEEE802.11)
5.2
Scenario sperimentale
I test sono stati realizzati all’interno del dipartimento di informatica di
Bologna, in corridoio Ercolani, ambiente con aria “satura” per la presenza
di varie reti che occupano molti dei canali disponibili. Per diminuire le interferenze con gli altri utenti, le prove in assenza di cifratura e con cifratura
WEP sono state effettuate utilizzando un unico access point di nostra proprieta’, a cui si sono collegati l’utente che sfrutta la nostra applicazione, l’utente
5.3 Prove e risultati
che riceve i messaggi del primo e, in caso di test con traffico di background, le
altre dieci postazioni che inviano pacchetti nella “nostra” rete. In questo modo gli accessi alla rete utilizzate per le prove sono monitorati e sappiamo con
certezza se c’e’ presenza di traffico e in che quantita’. L’access point a nostra
disposizione supporta l’IEEE80211 di tipo b e g. Per i test con cifratura
WPA, invece, non potendo disporre di una rete privata, abbiamo utilizzato ALMAWIFISTUDIO, rete fornita dall’universita’ di Bologna a tutti gli
studenti universitari. Le differenze con le precedenti prove sono le seguenti:
• gli accessi non sono controllati, non possiamo sapere quanti utenti sono
collegati alla rete che stiamo utilizzando
• sono presenti piu’ access point di ALMAWIFISTUDIO nel luogo in cui
si sono fatte le prove
5.3
5.3.1
Prove e risultati
Esecuzione test
Rete non cifrata e con WEP
Sono state eseguite varie prove, tutte con le seguenti modalita’:
la postazione che riceveva il flusso di dati udp era posta nelle vicinanze dell’access point, mentre l’utente che creava questo flusso e che quindi utilizzava
la nostra applicazione era mobile; dalla posizione di partenza vicina all’access
point, si allontanava lentamente da quest’ultimo in modo da aumentare la
probabilita’ di perdita di pacchetti. Il test si fermava quando l’utente, allontanatosi troppo, perdeva il collegamento alla rete. Nelle prove con traffico di
background, gli utenti in aggiunta erano fissi e vicini all’access point.
Rete cifrata con WPA
A differenza dei test precedenti, qui non e’ stato possibile, per le ragioni
gia’ descritte, controllare l’accesso alla rete utilizzata, percio’ sono state es-
69
70
5. Valutazione
eguite solamente prove con traffico di background, non stimabile pero’, per
l’impossibilita’ di avere informazioni sugli utenti presenti nelle nostre vicinanze e collegati ad ALMAWIFISTUDIO, e sul loro traffico. In questi test
c’era l’utente addetto alla ricezione del flusso udp, con postazione fissa, e l’utente che utilizzava l’applicazione che, partendo da una posizione vicina ad
uno degli access point di ALMAWIFISTUDIO, si allontanava. A differenza
delle prove precedenti, queste venivano fermate dopo un certo intervallo di
tempo, senza aspettare che l’utente perdesse il segnale della rete, a causa
di altri access point presenti nelle vicinanze del dipartimento di informatica,
che propagano il segnale di ALMAWIFISTUDIO.
Traffico di foreground (traffico dell’applicazione)
In tutti i test, per ogni utente che utilizza l’applicazione, sono stati inviati 50 pacchetti udp, con una frequenza all’incirca di 0,4 pacchetti trasmessi al secondo. Cio’ comporta una trasmissione di 410 byte al secondo nelle
prove senza frammentazione e di 820 byte al secondo in quelle con frammentazione (si parla di dimensione dei dati, senza considerare gli header dei vari
protocolli).
Estratto output test
output applicazione
Sending UDP "11" to (192.168.2.241:11111) ipid 39395
sent UDP, IP id 39395 frag_len 65535 offset 65535 more_frag 1
sent UDP, IP id 39395 frag_len 65535 offset 65535 more_frag 0
Sending UDP "12" to (192.168.2.241:11111) ipid 39396
sent UDP, IP id 39396 frag_len 65535 offset 65535 more_frag 1
NOT sent UDP, IP id 39396 frag_len 65535 offset 65535 more_frag 0
Sending UDP "13" to (192.168.2.241:11111) ipid 39397
NOT sent UDP, IP id 39397 frag_len 65535 offset 65535 more_frag 1
NOT sent UDP, IP id 39397 frag_len 65535 offset 65535 more_frag 0
5.3 Prove e risultati
Sep 4 15:08:03 kernel:***RTLKILL*** frame id : 1920
Sep 4 15:08:03 kernel:***RTLKILL*** datagram id : 39395
Sep 4 15:08:03 kernel:***RTLKILL*** source port : 58383
Sep 4 15:08:03 kernel:***RTLKILL*** fragment : 1
Sep 4 15:08:03 kernel:***RTLKILL*** acked : 1
Sep 4 15:08:03 kernel:***RTLKILL*** retry_count : 0
Sep 4 15:08:03 kernel:***RTLKILL*** filtered_count : 0d
.........................
Sep 4 15:08:03 kernel:***RTLKILL*** frame id : 1936
Sep 4 15:08:03 kernel:***RTLKILL*** datagram id : 39395
Sep 4 15:08:03 kernel:***RTLKILL*** source port : 0
Sep 4 15:08:03 kernel:***RTLKILL*** fragment : 0
Sep 4 15:08:03 kernel:***RTLKILL*** acked : 1
Sep 4 15:08:03 kernel:***RTLKILL*** retry_count : 0
Sep 4 15:08:03 kernel:***RTLKILL*** filtered_count : 0d
.........................
Sep 4 15:08:06 kernel:***RTLKILL*** frame id : 1952
Sep 4 15:08:06 kernel:***RTLKILL*** datagram id : 39396
Sep 4 15:08:06 kernel:***RTLKILL*** source port : 58383
Sep 4 15:08:06 kernel:***RTLKILL*** fragment : 1
Sep 4 15:08:06 kernel:***RTLKILL*** acked : 1
Sep 4 15:08:06 kernel:***RTLKILL*** retry_count : 0
Sep 4 15:08:06 kernel:***RTLKILL*** filtered_count : 0d
.........................
Sep 4 15:08:06 kernel:***RTLKILL*** frame id : 1968
Sep 4 15:08:06 kernel:***RTLKILL*** datagram id : 39396
Sep 4 15:08:06 kernel:***RTLKILL*** source port : 0
Sep 4 15:08:06 kernel:***RTLKILL*** fragment : 0
Sep 4 15:08:06 kernel:***RTLKILL*** acked : 0
Sep 4 15:08:06 kernel:***RTLKILL*** retry_count : 0
Sep 4 15:08:06 kernel:***RTLKILL*** filtered_count : 4152370048d
71
72
5. Valutazione
.........................
Sep 4 15:08:09 kernel:***RTLKILL*** frame id : 1984
Sep 4 15:08:09 kernel:***RTLKILL*** datagram id : 39397
Sep 4 15:08:09 kernel:***RTLKILL*** source port : 58383
Sep 4 15:08:09 kernel:***RTLKILL*** fragment : 1
Sep 4 15:08:09 kernel:***RTLKILL*** acked : 0
Sep 4 15:08:09 kernel:***RTLKILL*** retry_count : 0
Sep 4 15:08:09 kernel:***RTLKILL*** filtered_count : 0d
.........................
Sep 4 15:08:10 kernel:***RTLKILL*** frame id : 2000
Sep 4 15:08:10 kernel:***RTLKILL*** datagram id : 39397
Sep 4 15:08:10 kernel:***RTLKILL*** source port : 0
Sep 4 15:08:10 kernel:***RTLKILL*** fragment : 0
Sep 4 15:08:10 kernel:***RTLKILL*** acked : 0
Sep 4 15:08:10 kernel:***RTLKILL*** retry_count : 0
Sep 4 15:08:10 kernel:***RTLKILL*** filtered_count : 4152370048d
Risultati
Nella tabella che segue sono riportati per ogni test effettuato gli intervalli
di tempi medi che intercorrono tra l’istante in cui viene inviato un frame e il
momento in cui l’applicazione fornisce informazioni sulla sua sorte. I valori
indicati sono espressi in nsecondi.
1
1
1
1
2
4
1
4
no traffico bg
no traffico bg
traffico bg (10 client)
traffico bg (10 client)
traffico bg (10 client)
traffico bg (10 client)
traf. bg ALMAWIFISTUDIO
traf. bg ALMAWIFISTUDIO
applicazioni
1024 Byte
1024 Byte
1024 Byte
1024 Byte
2048 Byte
1024 Byte
2048 Byte
1024 Byte
traf pers
xx
xx
xx
xx
18.287.006
18.287.006
10.547.086
14.397.089
open
xx
xx
15.927.642
19.560.530
397.321.446
14.803.633
18.906.654
18.802.267
WEP
Tabella 5.1: Ritardi medi risposte applicazione
56.894.098
22.343.824
xx
xx
xx
xx
xx
xx
WPA
5.3 Prove e risultati
73
74
5. Valutazione
Grafici
Nei grafici sottostanti sono riportati i valori presenti nella tabella precedente (asse y), mostrando inoltre anche la differenza fra i ritardi per i frame
acked (colore giallo) e frame non acked (colore arancione). In colore blu sono
riportati i valori medi senza distinzione tra acked e non (valori presenti nella
tabella). N.B.: La lettera F indica i test in cui sono stati inviati pacchetti
udp di 2048 Byte e in cui percio’ e’ presente frammentazione.
Figura 5.1: Riassunto Generale
I grafici che seguono si riferiscono a quelle prove in cui piu’ utenti sulla
stessa macchina utilizzano l’applicazione. La prima serie di valori di ogni
grafico si riferisce al test nel complesso, senza alcuna distinzione tra i mittenti
dei frame, mentre quelli che seguono sono ottenuti mantenendo separati i
risultati dei vari utenti.
5.3 Prove e risultati
Figura 5.2: WEP multisessione
Figura 5.3: WPA multisessione
75
76
5. Valutazione
Il grafico che segue, a differenza dei precedenti, non riporta i valori medi
dei ritardi ottenuti nei test, ma mostra l’andamento del tempo necessario
per ottenere una risposta sulla sorte del frame di una singola prova, quella
eseguita su una rete senza cifratura, con frammentazione e traffico di background. Nell’asse y sono riportati i ritardi in nsecondi, mentre sull’asse x vi
sono i frame in ordine cronologico. I frame con una sola colonna (blu) sono
quelli che hanno ricevuto un ack, mentre quelli con due colonne (blu-rosso)
non l’hanno ricevuto.
Figura 5.4: Andamento ritardi singola prova
5.4
5.4.1
Discussione risultati
Prove
I vari test hanno fornito risultati simili, con l’unica eccezione dei valori
della prova con cifratura WEP, traffico di background e frammentazione, che
sono molto superiori; questo perche’ alcuni pacchetti inviati hanno riscontrato un ritardo molto elevato, nell’ordine dei secondi, che ha innalzato notevolmente i valori medi del test.
Una caratteristica dei test effettuati in assenza di cifratura e con la WEP
e’ il fatto che quando l’utente che utilizzava l’applicazione si e’ allontanato
5.4 Discussione risultati
dall’access point fino a perderne il segnale, non e’ piu’ riuscito a riconnettersi
automaticamente alla rete (questo non e’ dovuto al nostro lavoro). Tutto
cio’ invece non si e’ verificato durante le prove con WPA, in cui si e’ utilizzato wpa supplicant, il quale impedisce la chiusura della connessione quando
si perde il segnale dell’access point e permette la riconnessione automatica
alla rete. Questo elemento, comunque, non influenza minimamente la nostra
applicazione, che funziona correttamente anche quando si perde il segnale e
lo si riacquisisce successivamente.
5.4.2
Affidabilita’
Come gia’ detto in precedenza, l’applicazione e’ stabile, indipendentemente dal driver utilizzato, ma le informazioni fornite dipendono invece direttamente dal firmware, dai dati che questo fa arrivare dal hardware al driver
e quindi alla parte di stack di rete che implementa il protocollo IEEE802.11.
Infatti non tutte le schede wireless forniscono informazioni valide sul fatto
che i frame siano oppure no acked, sul retry count ..., fornendo invece a
volte informazioni false per mantenere la compatibilita’ con i livelli superiori: i frame vengono dichiarati sempre acked oppure il retry count viene
sempre considerato 0. In questi casi la nostra applicazione non puo’ accorgersi del problema e quindi continua ad essere in esecuzione fornendo pero’
le informazione datele dal driver e quindi dal firmware, che sono percio’ errate. Durante il nostro lavoro sono stati fatti degli studi e delle prove con
varie schede wireless, ottenendo una diversa affidabilita’ delle informazioni
dell’applicazione in base al dispositivo hardware utilizzato:
• rtl8187 : i frame sono sempre dichiarati acked e il retry count e’ considerato 0. Percio’ la nostra applicazioni e’ impotente ed e’ inutile
utilizzarla perche’ fornisce dati errati.
• iwl3945 : i dati forniti sono sempre completi, quindi la nostra applicazioni funziona correttamente.
77
78
5. Valutazione
• zd1211rw : le informazioni sullo stato acked dei frame sono corrette,
mentre il valore del retry count e’ sempre 0, e percio’ non e’ affidabile.
La nostra applicazione quindi mantiene un funzionamento parziale,
fornendo solo una parte di informazioni corrette.
5.4.3
Ritardi
Premessa
Prima di addentrarci nella discussione sui ritardi, occorre dire che questi
valori sono attendibili solo dal punto di vista statistico, perche’ ottenuti
tramite l’utilizzo di system call, che quindi, per quello che riguarda le tempistiche, comportano problemi dovuti a scheduling e alla precisione dell’orologio
di sistema... Infatti, per esempio, a volte abbiamo ottenuto dei ritardi pari
a 0 nsecondi, cosa improbabile nella realta’. Comunque, anche se i risultati
delle prove non possono essere considerati con una precisione del nsecondo,
sono indicativi, con i valori medi, dell’entita’ dei ritardi.
Dall’analisi dei tempi ottenuti dai test si puo’ osservare che, come previsto, vi e’ una differenza notevole fra i ritardi dei frame non acked e di quelli
acked. Questo perche’ si puo’ sapere se un pacchetto e’ acked nell’istante in
cui arriva l’ack dall’access point, mentre per considerarlo non acked occorre
aspettare che i timeout terminino, cosa che ovviamente crea un maggiore
ritardo. Il fatto invece non previsto e’ la vicinanza dei ritardi medi dei pacchetti indipendentemente dalla cifratura della rete. Infatti ci aspettavamo
un ritardo maggiore nei test con WEP e WPA, dovuto alla necesssta’ di
decrittare i frame, a differenza delle prove su rete aperta, ma, dai risultati
ottenuti, quello che si puo’ dire e’ che, almeno con la frequenza di dati inviati
dei test, la tipologia di cifratura della rete non influisce notevolmente sui ritardi. Un altro fattore osservabile dai risultati (grafico relativo alla singola
prova) e abbastanza prevedibile, consiste nel fatto che allontanandosi dall’access point i ritardi aumentano e c’e’ una maggiore probabilita’ di avere
5.4 Discussione risultati
frame non acked. Cio’ e dovuto a fattori fisici, perche’ in una comunicazione
tra due postazioni, all’aumentare della distanza, la potenza del segnale ricevuto da uno dei due elementi diminuisce, rendendo difficile all’antenna la
corretta ricezione del pacchetto, anche perche’ un segnale di bassa potenza
e’ facilmente mascherabile dal rumore circostante.
79
80
5. Valutazione
Capitolo 6
Sviluppi Futuri
6.1
IPv6
L’ICANN1 rese disponibile il protocollo IPv6 sui root server DNS dal 20
luglio 2004, ma solo dal 4 febbraio 2008 inizio’ l’inserimento dei primi indirizzi
IPv6 nel sistema di risoluzione dei nomi. Si prevede che il protocollo IPv4
verra’ utilizzato fino al 2025 circa, per dare il tempo necessario ad adeguarsi
e correggere gli eventuali errori.
Oltre a rispondere all’esigenza dell’aumento dello spazio di indirizzamento, l’IPv6 incorpora alcuni protocolli che prima erano separati, come l’ARP,
ed e’ in grado di impostare automaticamente alcuni parametri di configurazione della rete, come per esempio il default gateway. Inoltre supporta
nativamente il QOS e introduce l’indirizzamento anycast, che permette ad
un computer in rete di raggiungere automaticamente il piu’ vicino server
disponibile di un dato tipo (un DNS, per esempio) anche senza conoscerne a
priori l’indirizzo.
Per quanto riguarda il miglioramento del servizio, le principali migliorie
sono:
1
L’ICANN (Internet Corporation for Assigned Names and Numbers) e’ un ente inter-
nazionale non profit, istituito il 18 settembre 1998 per proseguire in numerosi incarichi di
gestione relativi alla rete Internet che in precedenza erano demandati ad altri organismi.
81
82
6. Sviluppi Futuri
• header di lunghezza fissa (40 byte)
• pacchetti non frammentabili dai router
• eliminazione del campo checksum
Queste tre novita’ alleggeriscono il lavoro dei router, migliorando l’instradamento e il throughput. IPv6 e’ la seconda versione dell’Internet Protocol ad essere ampiamente sviluppata, e costituira’ la base per la futura
espansione di Internet.
Proprio per questo motivo un argomento molto interessante riguarda il
porting da IPv4 a IPV6 del meccanismo cross-layer trattato.
6.2
DCCP
Il Datagram Congestion Control Protocol (DCCP) e’ un protocollo di comunicazione a livello di trasporto orientato al messaggio. E’ stato sviluppato
dall’IETF e standardizzato nell’ RFC 4340.
Applicazioni che possono far uso del DCCP includono quelle con limiti
di tempo per la consegna di dati tali che la consegna in ordine combinata
con il controllo della congestione possa far arrivare alcune informazioni al
ricevente dopo che non sia piu’ utili. Tali applicazioni includono lo streaming
e telefonia via Internet.
Il controllo di congestione e’ il modo in cui i protocolli di rete scoprono la
capacita’ della rete in un particolare cammino. La motivazioni primaria dello
sviluppo del DCCP e’ fornire un modo per tali applicazioni di guadagnare
accesso ai meccanismi standard di controllo della congestione senza doverla
implementare a livello applicazione.
Molto probabilmente appoggiarsi a questo protocollo piuttosto che all’UDP migliorerebbe ulteriormente la qualita’ del servizio da noi proposto.
6.3 Monitor
6.3
Monitor
Ottenute le informazioni dallo stack e dal driver sui datagram UDP inviati, occorre ora trasmettere questi dati alle applicazioni. In questo contesto
sono queste ultime a dover provvedere all’elaborazione delle informazioni
ottenute.
Tutte le operazioni lasciate alle applicazioni possono essere eseguite da
un modulo che dialoghi direttamente con lo stack e gestisca al meglio la
concorrenza di piu’ applicazione che usufruiscono dello stesso servizio.
6.4
IEEE 802.11r
Dopo un anno di interessamento al problema, e a poco piu’ di un mese
dalla discussione di questo documento, l’IEEE ha creato un nuovo standard
che avrebbe facilitato ulteriormente il nostro compito.
Il 15 Luglio 2008 l’IEEE ha pubblicato lo standard 802.11r-2008[13] anche
conosciuto come Fast BSS Transition. Queste modifiche permettono un cambio di AP dinamico e quindi rendono reale la continuita’ della connessione
transitando nella rete in maniera rapida e sicura.
Alcuni dettagli per permettere un servizio del genere sono gia stati introdotti in altre implementazioni del protocollo, tuttavia il ritardo di consegna di circa 100 ms e’ sempre stato troppo lungo per supportare applicazioni
come voce e video ed e’ particolarmente problematico per la sicurezza delle
connessioni che utilizzando WPA/WPA2 puo’ richiedere da 2 a 8 secondi per
la negoziazione.
La principale applicazione prevista per il 802.11r e’ lo standard VOIP.
BSS Transaction:
Scansione Attiva o passiva per altri AP nella zona utilizzando 802.11k
Autenticazione L’autenticazione con un (uno o piu’) AP prestabilito
83
84
6. Sviluppi Futuri
Associazione Riassociazione con l’AP e negoziazione della connessione
A questo punto, Access Point e device mobile dispongono di una connessione:
PTK Four way handshake della sessione basato su chiavi di autenticazione
802.1x
QOS Gestione della qualita’ del servizio
Essendo nuovo, questo standard non ha ancora implementazioni effettive.
Probabilmente con i dovuti accorgimenti il nostro meccanismo cross-layer
puo’ essere adattato allo standard. Dopo quasi un anno di studi, il fatto
che la IEEE abbia deciso di affrontare il problema, sicuramente ci riempie di
soddisfazione.
6.5
Kernel Linux
Riguardo alle modifiche compiute sullo stack di rete (grazie alla loro
indipendenza dalle funzionalita’ preesistenti) potrebbe essere utile una integrazione nella versione ufficiale del kernel di Linux, soprattutto tenendo
presente il nuovo standard IEEE 802.11r.
Capitolo 7
Conclusioni
Il panorama attuale vede le comunicazioni in continua evoluzione. Le reti
wireless sono in aumento sul territorio e la tecnologia VoIP ha sempre piu’
applicazioni sia dal punto di vista lavorativo che personale.
L’utilizzo combinato di queste due tecnologie e’ complicato dal problema dell’elevata perdita di pacchetti insita nelle reti Wi-Fi e l’utilizzo di un
protocollo inaffidabile come UDP da parte del VoIP.
Il nostro scenario ipotetico vede un dispositivo mobile connesso ad un AP,
e la possibilita’ di spostamento nello spazio senza perdita di connettivita’ a
patto di copertura del percorso.
Questa comunicazione avviene attraveso lo scambio di pacchetti. Il dispositivo mobile invia all’AP i dati di interesse, e a sua volta l’AP comunica
l’avvenuta ricezione (Acknowledgement).
Grazie alle modifiche apportate allo stack di rete, il problema della comunicazione all’applicazione l’avvenuta ricezione degli acknowledgement da
parte del device all’applicazione e la gestione dell’interattivita’ e’ stato risolto.
La parte iniziale riguardante lo studio delle informazioni effettivamente
disponibili a basso livello, ha mostrato che tutto il lavoro svolto diviene affidabile solo in presenza di driver capaci di fornire informazioni precise e
corrette, a volte passano ai livelli superiori informazioni false per mantenere
la compatibilita’ con vari protocolli. In questi casi il nostro meccanismo non
85
86
7. Conclusioni
puo’ accorgersi del problema e quindi continua ad essere in esecuzione fornendo pero’ le informazione datele dal driver e quindi dal firmware, che sono
percio’ errate.
Come gia’ detto precedentemente, il codice da noi integrato nello stack e’
stabile, indipendentemente dal driver utilizzato. Non appesantisce o rallenta
significativamente il kernel, ma soprattutto non ne compromette le funzionalita’ dato che non modifica processi1 esistenti, ma ne crea uno nuovo parallelo
ad essi.
Lo studio ha permesso di evidenziare che tendenziamente le schede wireless PCI Express o MINIPCI esportano maggiori informazioni e tendono ad
essere piu’ precise dei device USB. Questo pensiamo sia dovuto alla mancanza
dello stack USB che crea un ulteriore livello di astrazione.
Il lavoro qui svolto getta le basi per la creazione di un modulo che gestisca
i dati da noi forniti, per permettere un alleggerimento dei controlli da parte
delle applicazioni.
Fornisce inoltre alcuni semplici e indicativi risultati circa il comportamento e il possibile utilizzo dell’interattivita’ cosi’ costituita. Il problema
risolto ad oggi e’ ritenuto particolarmente significativo nell’ambito delle reti
wireless.
Con grande soddisfazione personale, nel periodo in cui questa tesi e’ stata
sviluppata anche l’IEEE stava lavorando ad un progetto molto simile. La
pubblicazione dello standard IEEE 802.11r (15 Luglio 2008) ci permette di
affermare la significativita’ del nostro lavoro e la possibilita’ di adattare le
nostre modifiche allo standard per renderle esecuitve fuori dalla nostra rete
di testing.
Grazie all’evoluzione degli standard e delle tecnologie attuali, la possibilita’ di integrare le nostre modifiche al kernel di Linux sembrerebbe non del
tutto impossibile e sicuramente un esperienza inestimabile.
1
Per processo si intende processo di elaborazione di uno o piu’ dati per ottenerne
informazioni.
Sicuramente grazie alla mia famiglia,
che ha reso possibile tutto questo.
Un ringraziamento speciale al Dott. Vittorio Ghini,
che seguendoci un anno intero ci ha permesso di realizzare una
tesi volta a risolvere un problema reale.
Grazie a Giulio Grassi,
collega e amico che ha reso indimenticabile questa tesi e gli
anni passati insieme.
Ultimi ma non per importanza, grazie a tutti gli amici e
colleghi,
che mi hanno accompagnata fino a qua, coscienti che di anni
da passare insieme ce ne saranno altri due.
Grazie a tutti.
Bibliografia
[1] Andrew S. Tanenbaum, Computer Networks (4th Edition),
Prentice Hall, 2003
[2] L. Peterson, B. Davie, Computer Networks: A Systems
Approach (3rd Edition), Morgan Kaufmann, 2003
[3] Institute of Electrical and Electronics Engineers, IEEE
802.11TM WIRELESS LOCAL AREA NETWORKS, Website, 2008,
http://www.ieee802.org/11/
[4] Institute of Electrical and Electronics Engineers, IEEE
802.11TM Standard, Website, 2008,
http://standards.ieee.org/getieee802/802.11.html
[5] BBC, Wi-Fi: A warning signal, Website, 2007,
http://news.bbc.co.uk/2/hi/programmes/panorama/6674675.stm
[6] Fabio M. Zambelli, Report semina terrore sul Wi-Fi,
Website, 2008,
http://www.setteb.it/content/view/3934
1
2
BIBLIOGRAFIA
[7] Filippo Vendrame, I tedeschi temono il Wi-Fi, Website,
2007,
http://www.oneadsl.it/28/09/2007/i-tedeschi-temono-ilwi-fi/
[8] Francesca Guido, Pericolo wi-fi, Website, 2007,
http://www.datamanager.it/articoli.php?visibile1̄&idricercato2̄1059
[9] Information Sciences Institute University of Southern
California, RFC791 - Internet Protocol, 1981,
http://www.faqs.org/rfcs/rfc791.html
[10] J. Postel, RFC768 - User Datagram Protocol, 1980,
http://www.faqs.org/rfcs/rfc768.html
[11] Autori vari: IETF, ISI, Voice Over IP, Website,
http://www.protocols.com/pbook/VoIPFamily.htm
[12] Roberto Arcomano, VoIP Howto, Website, 2002,
http://www.faqs.org/docs/Linux-HOWTO/VoIPHOWTO.html
[13] IEEE P802.11 Task Group R, Project IEEE 802.11r,
Website, 2008,
http://grouper.ieee.org/groups/802/11/Reports/tgr update.htm