Index: doc/AssociazioneMultipla.tex
===================================================================
--- doc/AssociazioneMultipla.tex	(revision 8)
+++ doc/AssociazioneMultipla.tex	(revision 9)
@@ -4,11 +4,5 @@
 \usepackage[T1]{fontenc}
 \usepackage[utf8]{inputenc}
-\usepackage[pdftex,bookmarks,colorlinks,citecolor=green, linkcolor=red,
-urlcolor=blue]{hyperref}
-
-% testo colorato
-%\usepackage{color}
-% riferimenti incrociati dinamici
-% \usepackage{varioref}
+\usepackage[pdftex,bookmarks,colorlinks]{hyperref}
 
 % SoujaK
@@ -17,6 +11,6 @@
  %bookmarks=false]{hyperref}
 
-\title{Associazione multipla simultanea\\ di un \textit{client} 802.11}
-\author{Andrea Rappini, Alessio Romagnoli,\\Marco Solieri, Andrea Simeone}
+\title{Associazione multipla simultanea di~un~\textit{client}~802.11}
+\author{Andrea~Rappini, Alessio~Romagnoli,\\Marco~Solieri, Andrea Simeone}
 
 \makeindex
@@ -29,14 +23,19 @@
 \begin{abstract}
 La diffusione di reti \textit{wireless} è in forte crescita a causa della sua
-comodità e della diffusa disponibilità di connessioni ad Internet con ampie
-larghezze di banda. Sfruttare contemporaneamente la connessione alla
-molteplicità di reti spesso presente permetterebbe un utilizzo migliore di tali
-risorse, migliorando il \textit{throughput} e incrementandone l'affidabilità.
-
-Lo studio intende quindi analizzare le effettive possibilità di realizzazione di
-un'estensione delle comuni implementazioni dello standard IEEE 802.11 che
-permetta al singolo \textit{client} in ambiente GNU/Linux l'associazione
-simultanea a differenti reti \textit{wireless}.
+comodità e della larga disponibilità di connessioni ad Internet con ampie
+larghezze di banda.
+Sfruttare contemporaneamente la connessione alla molteplicità di reti spesso
+presente permetterebbe un utilizzo migliore di tali risorse, migliorando il
+\textit{throughput} aggregato e incrementandone l'affidabilità.
+
+Si intende dapprima introdurre il lettore allo scenario nel quale è stato
+condotto lo studio, evidenziandone gli aspetti salienti che riguardano lo
+standard IEEE 802.11 e le sue interpretazioni.
+In un secondo momento si presenteranno non solo le proposte risolutive
+individuate, ma anche spunti per ulteriori ottimizzazioni.
 \end{abstract}
+
+\clearpage
+\tableofcontents
 
 \clearpage
@@ -50,21 +49,19 @@
 più BSS (cioè l'insieme di nodi costituenti una rete \textit{wireless}).
 
-Nel presente documento si intende dapprima introdurre il lettore allo scenario
-nel quale è stato condotto lo studio, evidenziandone gli aspetti salienti che
-riguardano lo standard IEEE 802.11 e le sue interpretazioni. In un secondo
-momento si presenteranno non solo proposte risolutive, ma anche spunti
-accessori.
+Si analizzano le effettive possibilità di realizzazione di un'estensione delle
+comuni implementazioni dello standard IEEE 802.11 che permetta al singolo
+\textit{client} in ambiente GNU/Linux l'associazione simultanea a differenti
+reti \textit{wireless}.
 
 \subsection{Scopi}
 \label{sec:scopi}
 L'intento più evidente è quello di aumentare la connettività del
-\textit{client},
-permettendogli connessioni simultanee a reti altrimenti isolate ed eventualmente
-consentendo al \textit{client} di agire in qualità di ponte.
+\textit{client}, permettendogli connessioni simultanee a reti altrimenti isolate
+ed eventualmente consentendogli di agire in qualità di ponte fra di esse.
 Qualora i punti di accesso resi contemporaneamente utilizzabili riferiscano (più
 o meno direttamente) alla medesima rete, allora la molteplicità si traduce in
 ridondanza e, conseguentemente, in affidabilità.
-I più coraggiosi potranno sfruttare le multi-connettività in oggetto come punto
-di partenza per la realizzazione di politiche di gestione al fine di
+I più coraggiosi potranno infine sfruttare le multi-connettività in oggetto come
+punto di partenza per la realizzazione di politiche di gestione al fine di
 massimizzare il \textit{throughput} aggregato.
 
@@ -86,9 +83,8 @@
  GNU/Linux;
  \item [facilità implementativa]
- ridurre gli sforzi per l'effettiva messa in
- opera;
+ ridurre gli sforzi per l'effettiva messa in opera;
  \item [trasparenza]
- virtualizzare le interfacce di rete associate ad ogni
- connessione per minimizzare l'impatto.
+ virtualizzare le interfacce di rete associate ad ogni connessione per
+ minimizzare l'impatto per l'utente come per il sistema.
 \end{description}
 
@@ -126,9 +122,9 @@
 \paragraph{Autenticazione}
 A causa della natura condivisa del mezzo trasmissivo, l'accesso alla rete
-sarebbe aperto a qualunque stazione richieda di associarsi. IEEE ha quindi
-elaborato una strategia di regolazione dell'accesso  richiedendo la mutua
-identificazione di entrambi gli estremi di ogni comunicazione. Tale procedura,
-definita autenticazione, risulta pertanto essere un prerequisito della stessa
-associazione.
+sarebbe aperto a qualunque stazione richieda di associarsi.
+IEEE ha quindi elaborato una strategia di regolazione dell'accesso  richiedendo
+la mutua identificazione di entrambi gli estremi di ogni comunicazione.
+Tale procedura, definita autenticazione, risulta pertanto essere un prerequisito
+della stessa associazione.\\
 Il processo può diventare oneroso in termini di tempo a causa dei \textit{frame}
 da scambiare e dell'elaborazione necessaria (si pensi ai calcoli crittografici
@@ -146,9 +142,10 @@
 \paragraph{802.11i}
 \label{80211i}
-L'estensione \texttt{i} dello standard intende migliorare il livello di
-sicurezza e confidenzialità introducendo nuovi protocolli e metodologie.
+L'estensione 802.11i \cite{80211i} dello standard intende migliorare
+il livello di sicurezza e confidenzialità introducendo nuovi protocolli e
+meccanismi.
 Tutti i suoi metodi di autenticazione basati su autenticatori esterni
 (\textit{server} RADIUS) provengono dallo standard 802.1x, che riguarda proprio
-il controllo d'accesso a reti dell'insieme 802 (Ethernet, Token-Ring \ldots).
+il controllo d'accesso a reti dell'insieme 802 (Ethernet, Token-ring \ldots).
 Questo genere di comunicazioni viene quindi effettuato a strati di rete
 superiori coinvolgendo marginalmente il livello 802.11 in oggetto.
@@ -162,15 +159,15 @@
 efficiente rispetto ai consumi energetici, dal momento che i dispositivi
 portatili alimentati a batteria sono tutt'altro che rari.
-Le stazioni che supportano tale funzionalità hanno la facoltà di
-``addormentarsi'' durante i periodi di inattività. In questi momenti, gli
-eventuali dati ad esse destinati vengono conservati dal BSS\footnotemark per un
-invio successivo, essendo esso stato precedentemente avvisato dello stato delle
-stazioni in questione.
+Le stazioni che supportano tale funzionalità hanno infatti la facoltà di
+``addormentarsi'' durante i periodi di inattività.
+In questi momenti, gli eventuali dati ad esse destinati vengono conservati dal
+BSS\footnotemark per un invio successivo, essendo esso stato precedentemente
+avvisato dello stato delle stazioni in questione.
 I BSS, quindi, annunciano periodicamente la presenza delle trasmissioni in
 attesa, indicandone i destinatari con un messaggio chiamato TIM che è presente
-all'interno di alcuni dei \textit{beacon}. Conseguentemente le stazioni in
-risparmio energetico sono tenute a risvegliarsi in corrispondenza di questi
-intervalli regolari, per poi richiedere l'invio tramite un apposito tipo di
-\textit{frame} (il \texttt{PS-Poll}).
+all'interno di alcuni dei \textit{beacon} (cfr. \ref{sec:vincolitemporali}.
+Conseguentemente le stazioni in risparmio energetico sono tenute a risvegliarsi
+in corrispondenza di questi intervalli regolari, per poi richiedere l'invio
+tramite un apposito tipo di \textit{frame} (il \texttt{PS-Poll}).
 \footnotetext{In realtà sarebbe doveroso fare una distinzione fra le reti
 infrastrutturate e quelle indipendenti (o \textit{ad hoc}), nelle quali la
@@ -180,17 +177,17 @@
 \subsubsection{Vincoli temporali}
 \label{sec:vincolitemporali}
-Come già anticipato precedentemente (nella sezione \ref{salti}), il
-\textit{client} avrà l'illusione di essere contemporaneamente associato ai BSS
-di interesse tramite continui salti fra di essi; per questo motivo risulta
-importante chiarire quali siano i vincoli temporali che lo standard gli impone.
+Come già anticipato (sezione \ref{salti}), il \textit{client} avrà l'illusione
+di essere contemporaneamente associato ai BSS di interesse tramite continui
+salti fra di essi; per questo motivo risulta importante chiarire quali siano i
+vincoli temporali che lo standard gli impone.
 La padronanza di queste informazioni è di grande rilevanza, sia perché dovranno
 essere rispettate dal \textit{client} anche in seguito alle modifiche che
 verranno proposte nel presente studio, sia perché potranno essere tenute
-presenti per raffinamenti volti a migliorare l'efficienza delle soluzioni.
+presenti per raffinamenti volti a migliorare l'efficienza delle soluzioni (si
+veda, più avanti, la sezione \ref{sec:ottimizzazioni}.
 
 L'accesso al mezzo trasmissivo, a causa della sua stessa natura condivisa, è
 regolato da convenzioni stabilite dallo standard che consentono una
 ripartizione equa di questa risorsa.
-
 Tali regolamentazioni di natura temporale si fondano sulla reciproca
 sincronizzazione delle stazioni che condividono il mezzo fisico, raggiunta
@@ -210,8 +207,8 @@
 
 Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma
-anche degli annunci di inizio dei periodi liberi da contesa presenti nelle reti
+anche degli annunci d'inizio dei periodi liberi da contesa presenti nelle reti
 infrastrutturate, lassi di tempo durante i quali l'accesso al mezzo è
 coordinato da un gestore centrale.
-Esso risiede tipicamente nell'\textit{access-point} e provvede a coordinare le
+Esso risiede tipicamente nell'\textit{access point} e provvede a coordinare le
 comunicazioni in maniera spesso più efficiente rispetto a quando il
 coordinamento è distribuito.
@@ -224,11 +221,11 @@
 \label{sec:wext}
 La portabilità in ambienti GNU/Linux è stata ricercata usando come punto di
-riferimento le Linux Wireless Extensions (per brevità \texttt{wext}). Il
-progetto intende mettere ordine in uno scenario spesso dominato
-dall'eterogeneità, proponendo delle interfacce unificate per i driver di
-sistema delle varie soluzioni \textit{hardware} disponibili. Nel momento in cui
-si scrive sono ancora pochi i driver che si sono completamente uniformati a
-questo insieme di interfacce, ma questa scelta è stata dettata dalla speranza
-che esse diventino presto lo standard \textit{de facto}.
+riferimento le Linux Wireless Extensions (per brevità \textsc{wext}).
+Il progetto intende mettere ordine in uno scenario spesso dominato
+dall'eterogeneità, proponendo delle interfacce unificate per i driver di sistema
+delle varie soluzioni \textit{hardware} disponibili.
+Nel momento in cui si scrive non tutti i \textit{driver} che si sono
+completamente uniformati a questo insieme di interfacce, ma la speranza che esse
+diventino presto lo standard \textit{de facto}.
 
 Accanto alle API di programmazione sono stati sviluppati anche gli
@@ -244,71 +241,71 @@
 facendo riferimento al modello ISO/OSI, al livello fisico e a quello MAC
 (\textit{Medium Access Control}), implementati dai produttori tramite
-l'accoppiata \textit{hardware}/\textit{firmware}. MAC viene solitamente
-realizzato così a basso livello per rispondere alle esigenze di velocità
-e precisione temporale di cui si accennava in \ref{sec:vincolitemporali}.
-È importante sottolineare, quindi, che qualunque idea risolutiva dello
-studio in questione non potrà prescindere dalle modalità di interazione
-(interfacce e impostazioni) consentite dalla specifica implementazione di MAC.
-Questo discorso diventa tanto più importante quanto la soluzione perseguita si
+l'accoppiata \textit{hardware}/\textit{firmware}.
+MAC viene solitamente realizzato così a basso livello per rispondere alle
+esigenze di velocità e accuratezza temporale di cui si accennava in
+\ref{sec:vincolitemporali}.
+È importante sottolineare, quindi, che qualunque idea risolutiva dello studio in
+questione non potrà prescindere dalle modalità di interazione (interfacce e
+regolazioni) consentite dalla specifica implementazione di MAC.
+Questa dipendenza diventa tanto più rilevante quanto la soluzione perseguita si
 discosta dalla rigidità dello standard.
 
-La revisione 802.11i, che estende lo standard migliorando la sicurezza da esso
-offerta, definisce nuove funzionalità per il livello MAC che possono invece
-essere tranquillamente implementate all'esterno del \textit{firmware}.
+La revisione 802.11i (introdotta in \ref{80211i}, che estende lo standard
+migliorando la sicurezza da esso offerta, definisce nuove funzionalità per il
+livello MAC che possono invece essere tranquillamente implementate all'esterno
+del \textit{firmware}.
 
 \subsubsection{Libertà d'azione}
 \label{sec:libertàdazione}
-Le più diffuse implementazioni di 802.11 sono però quantomai lontane dalle
+Le più diffuse implementazioni di 802.11 sono quantomai lontane dalle
 libertà di azione sperabili poiché il \textit{firmware} risulta essere
 scarsamente programmabile, consentendo poco più delle interazioni necessarie al
-normale funzionamento. Esempi di soluzioni \textit{chipset} che siano
-controcorrente, e pertanto interessanti, vengono riportati da
-\refname{guidadefinitiva}: Atheros\footnotemark e Broadcom.
-\footnotetext{L'unico (dei due) provato dagli autori, con driver
-\texttt{MADWiFi}.}
+normale funzionamento.
+Esempi di soluzioni \textit{chipset} che siano contrarie a questa tendenza, e
+pertanto interessanti, vengono riportati da \cite{defguide}: Atheros e Broadcom;
+il primo dei due, provato direttamente dagli autori, sarà oggetto della sezione
+\ref{sec:casoreale}.
 
 A complicare ulteriormente la situazione intervengono le limitazioni imposte
 dalle autorità delle comunicazioni di molti Paesi (si pensi all'FCC
-statunitense),
-%http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf
-che richiedono la distribuzione dei trasmettitori radio
-con \textit{firmware} in forma necessariamente binaria per scongiurare
+statunitense\footnotemark), che richiedono la distribuzione dei trasmettitori
+radio con \textit{firmware} in forma necessariamente binaria per scongiurare
 violazioni dei limiti di utilizzo delle frequenze.
-
+\footnotetext{Per maggiori informazioni si veda:\\
+\url{http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf
+}}
 
 \subsubsection{Interpretazione dello standard}
 \label{sec:interpretazionedellostandard}
 
-Nemmeno le più fedeli realizzazioni di 802.11 supportano la
-preautenticazione (\refname{guidadefinitiva}), quindi i servizi di
-autenticazione e associazione risultano indissolubilmente legati, vanificando
-ogni possibilità di realizzare autenticazione multipla.
+Nemmeno le più fedeli realizzazioni di 802.11 (come segnala \cite{defguide})
+supportano la preautenticazione , quindi i servizi di autenticazione e
+associazione risultano indissolubilmente legati, vanificando ogni possibilità di
+realizzare nativamente autenticazioni multiple.
 Di conseguenza, il superamento di questo limite, vincolante per realizzare
-associazione multipla simultanea, sarà, in tutta la sua complessità, compito
+associazioni multiple simultanee, sarà, in tutta la sua complessità, compito
 dell'implementatore della soluzione proposta in \ref{sec:soprailfirmware}.
 
-Un'altra eventuale limitazione dovuta all'interpretazione dello standard
-può derivare dalla libertà concessa riguardo la stessa implementazione del
-supporto alla gestione energetica.
+Un'altra eventuale (e poco probabile) limitazione dovuta all'interpretazione
+dello standard può derivare dalla libertà concessa riguardo la stessa
+implementazione del supporto alla gestione energetica.
 
 \subsection{Caso reale}
 \label{sec:casoreale}
 
-Le schede \texttt{Atheros} costituiscono una realtà attraente per i fini dello
-studio, in particolare per ciò che concerne le libertà d'azione concesse di cui
-al \ref{sec:libertàdazione}.
-Il driver \texttt{MADWiFi} è in grado sfruttare in maniera interessante le
+Le schede Atheros costituiscono una realtà attraente per i fini dello studio, in
+particolare per ciò che concerne le libertà d'azione concesse di cui al
+\ref{sec:libertàdazione}.
+Il driver MADWiFi è in grado sfruttare in maniera interessante le
 potenzialità fornite da questo \textit{chipset}, offrendo funzionalità non
 troppo distanti dagli scopi del presente.
 
-\subsubsection{Il \textit{chipset} \texttt{Atheros}}
+\subsubsection{Il \textit{chipset} Atheros}
 \label{sec:atheros}
 
-I \textit{chipset} \texttt{Atheros} equipaggiano i dispositivi 802.11 di alcuni
+I \textit{chipset} Atheros equipaggiano i dispositivi 802.11 di alcuni
 fra i maggiori produttori di \textit{hardware} per la connettività, come
-\texttt{Linksys}, \texttt{NETGEAR}, \texttt{D-Link}, \texttt{Orinoco},
-\texttt{Proxim} o \texttt{3Com}.
-
-Il suo \textit{firmware} consente un grado di interazione di estensione
+Linksys, NETGEAR, D-Link, Orinoco, Proxim o 3Com.
+Il suo \textit{firmware} consente un grado di interazione dall'estensione
 incomparabile, esponendo un'interfaccia in grado di offrire controllo anche su
 dettagli generalmente offuscati.
@@ -317,28 +314,29 @@
 sovrastrato (reso disponibile in sola forma binaria) atto a limitare
 l'interfaccia al fine di impedire utilizzi non conformi alle vigenti
-regolamentazioni sugli apparecchi radio. Tale componente, denominato
-\texttt{HAL} (\textit{Hardware Abstraction Layer}), interviene limitando le
-radiofrequenze operative del dispositivo, continuando comunque a concedere le
-libertà auspicate.
-
-\subsubsection{Il \textit{driver} \texttt{MADWiFi}}
+regolamentazioni sugli apparecchi radio.
+Tale componente, denominato HAL (\textit{Hardware Abstraction Layer}),
+interviene limitando le radiofrequenze operative del dispositivo, continuando
+comunque a concedere le libertà auspicate.
+
+\subsubsection{Il \textit{driver} MADWiFi}
 \label{sec:madwifi}
-A partire dallo scorso anno la spinta innovatrice di \texttt{Atheros} ha avuto
-riscontro anche nel progetto \texttt{MADWiFi}, i driver liberi per piattaforme
-Linux sviluppati inizialmente da Sam Leffler. Le novità introdotte dal nuovo
-\texttt{HAL} sono state sfruttate aggiungendo una serie di funzionalità di
-grande rilevanza. Il carattere rivoluzionario rende il progetto, come spesso
-capita, piuttosto instabile ma assai vitale.
+A partire dallo scorso anno la spinta innovatrice di Atheros ha avuto riscontro
+anche nel progetto MADWiFi, i driver liberi per piattaforme Linux sviluppati
+inizialmente da Sam Leffler.
+Infatti le novità introdotte dal nuovo HAL sono state sfruttate aggiungendo una
+serie di funzionalità di grande rilevanza.
+Il carattere rivoluzionario rende il progetto, come spesso capita, piuttosto
+instabile ma assai vitale.
 
 L'aspetto indubbiamente più interessante è l'introduzione della modalità
 \textbf{VAP} (\textit{Virtual Access Point}), grazie alla quale è possibile
 virtualizzare il dispositivo creando molteplici interfacce di rete operanti
-concorrentemente in maniera indipendente.
+concorrentemente.
 Questa funzionalità è implementata facendo uso del medesimo livello fisico,
 vincolando così l'operatività dei VAP sullo stesso canale trasmissivo.
 Ciononostante, la rosa delle possibilità rimane ben assortita, permettendo la
 creazione di molteplici \textit{access point} e/o una (e al più una) stazione in
-modalità \texttt{managed} o \texttt{ad-hoc}.
-La nota modalità \texttt{monitor} viene inoltre resa inseribile in una qualsiasi
+modalità \textit{managed} o \textit{ad-hoc}.
+La nota modalità \textit{monitor} viene inoltre resa inseribile in una qualsiasi
 delle configurazioni appena descritte, con la semplice aggiunta di un VAP di
 questo tipo.
@@ -348,15 +346,14 @@
 essi locali (e virtualizzati) o esterni.
 
-Le interfacce virtuali create saranno esposte ed utilizzate comodamente in piena
-trasparenza, essendo presentate come ordinarie interfacce di rete aderenti alle
-\textit{Wireless Extensions}.
-
-L'alto grado di controllo permesso dal \textit{firmware} \texttt{Atheros} si
-propaga fino all'utente attraverso il \textit{driver} grazie ai suoi numerosi
-parametri specifici, che si ricordano essere gestibili tramite il comando
-\texttt{iwpriv} degli \textit{Wireless Tools}. Un ulteriore strumento a riga di
-comando, \texttt{wlanconfig}, completa le necessità di amministrazione proprie
-di questo \textit{driver}, permettendo creazione, distruzione e cambio di
-modalità dei VAP.
+Le interfacce virtuali create possono essere utilizzate comodamente in piena
+trasparenza, essendo aderenti alle \textit{Wireless Extensions}.
+
+L'alto grado di controllo permesso dal \textit{firmware} Atheros si propaga fino
+all'utente attraverso il \textit{driver} grazie ai suoi numerosi parametri
+specifici, che si ricordano essere gestibili tramite il comando \texttt{iwpriv}
+degli \textit{Wireless Tools}.
+Un ulteriore strumento a riga di comando, \texttt{wlanconfig}, completa le
+necessità di amministrazione proprie di questo \textit{driver}, permettendo
+creazione, distruzione e cambio di modalità dei VAP.
 
 \section{Soluzioni}
@@ -601,16 +598,23 @@
  \ldots).
 
- \end{description}
+\end{description}
+
+\clearpage
 
 \section{Ringraziamenti}
 \label{sec:ringraziamenti}
-
-\clearpage
-\tableofcontents
-% \printindex
-
-% \bibliography{Bibliografia}
-% \bibliographystyle{alpha}
-% \nocite{*}
+Vittorio Ghini, docente del corso di ``Laboratorio di programmazione di rete'',
+per averci proposto l'occasione di condurre questo studio e per l'entusiasmo
+che ha saputo trasmetterci.\\
+Luciano Bononi, docente del corso di ``Sistemi di reti \textit{wireless}'', per
+gli indirizzamenti offerti.\\
+Sam Leffler, autore di MADWiFi, per le conferme a proposito della soluzione
+sopra il \textit{firmware} con schede Atheros.\\
+Jouni Malinen, autore di \texttt{wpa\_supplicant}, per i chiarimenti riguardo
+alcuni aspetti dell'autenticazione di 802.11i.
+
+\bibliography{Bibliografia}
+\bibliographystyle{alpha}
+\nocite{*}
 
 \end{document}
