Index: doc/AssociazioneMultipla.tex
===================================================================
--- doc/AssociazioneMultipla.tex	(revision 11)
+++ doc/AssociazioneMultipla.tex	(revision 1)
@@ -4,5 +4,10 @@
 \usepackage[T1]{fontenc}
 \usepackage[utf8]{inputenc}
-\usepackage[pdftex,bookmarks,colorlinks]{hyperref}
+\usepackage[pdftex,bookmarks,colorlinks,linkcolor=red,urlcolor=blue]{hyperref}
+
+% testo colorato
+%\usepackage{color}
+% riferimenti incrociati dinamici
+%\usepackage{varioref}
 
 % SoujaK
@@ -11,9 +16,6 @@
  %bookmarks=false]{hyperref}
 
-\title{Associazione multipla simultanea di~un~\textit{client}~802.11}
-\author{Andrea~Rappini, Alessio~Romagnoli,\\Marco~Solieri, Andrea Simeone}
-
-\makeindex
-
+\title{Associazione multipla simultanea\\ di un \textit{client} 802.11}
+\author{Andrea Rappini, Alessio Romagnoli,\\Marco Solieri, Andrea Simeone}
 
 \begin{document}
@@ -22,24 +24,20 @@
 
 \begin{abstract}
-La diffusione di reti \textit{wireless} è in forte crescita a causa della sua
-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.
+La diffusione di reti 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 wireless.
 \end{abstract}
 
-\clearpage
-\tableofcontents
-
-\clearpage
+% \newpage
 \section{Introduzione}
-\label{sec:introduzione}
+\label{sec:intro}
 
 \subsection{Oggetto}
@@ -47,44 +45,45 @@
 Lo studio di fattibilità si interroga sulle possibilità realizzative di
 connessione di un singolo \textit{client} 802.11 a diverse reti, partecipando a
-più BSS (cioè l'insieme di nodi costituenti una rete \textit{wireless}).
-
-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}.
+piè BSS
+(cioè l'insieme di nodi costituenti una rete 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.
 
 \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 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 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.
+\textit{client},
+permettendogli connessioni simultanee a reti altrimenti isolate ed eventualmente
+consentendo al \textit{client} di agire in qualità di ponte. 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
+multi-connettività in oggetto come punto di partenza per la realizzazione di
+politiche di gestione al fine di massimizzare il \textit{throughput} aggregato.
 
 \subsection{Obiettivi supplementari}
 \label{sec:obiettivi}
 I criteri con i quali si sono prese le svariate decisioni che hanno
-caratterizzato lo studio e che si concretizzano nelle soluzioni proposte sono
-stati influenzati dai seguenti obiettivi supplementari:
+caratterizzato lo studio e che si concretizzano nelle soluzioni proposte hanno
+risentito dei seguenti obiettivi supplementari:
 \begin{description}
- \item [\textit{overhead} minimo]
- abbattere i costi introdotti dalla gestione simultanea delle connessioni
- multiple;
- \item [perdite minime]
- ridurre o eliminare ogni possibile perdita di dati in ricezione causata dalla
- temporanea assenza su un BSS (cfr. sezione \ref{sec:mezzotrasmissivo});
- \item [portabilità]
- essere quanto più indipendente dalle specifiche piattaforme
- \textit{hardware}/\textit{firmware}, pur rimanendo legata all'ambiente
- GNU/Linux;
- \item [facilità implementativa]
- ridurre gli sforzi per l'effettiva messa in opera;
- \item [trasparenza]
- virtualizzare le interfacce di rete associate ad ogni connessione per
- minimizzare l'impatto per l'utente come per il sistema.
+\item[\textit{overhead} minimo]
+abbattere i costi introdotti dalla gestione simultanea delle connessioni
+multiple;
+\item[perdite minime] ridurre o eliminare ogni possibile perdita di dati in
+ricezione causata dalla temporanea assenza su un BSS (cfr.
+sezione~\ref{sec:mezzotrasmissivo});
+\item[portabilità] essere quanto più indipendente dalle specifiche piattaforme
+\textit{hardware}/\textit{firmware}, pur rimanendo legata all'ambiente
+GNU/Linux;
+\item[facilità implementativa] ridurre gli sforzi per l'effettiva messa in
+opera;
+\item[trasparenza] virtualizzare le interfacce di rete associate ad ogni
+connessione per minimizzare l'impatto.
 \end{description}
 
@@ -97,7 +96,7 @@
 sua natura, disponibile e condiviso da ogni utilizzatore, pertanto lo standard
 IEEE 802.11 ne sancisce il partizionamento in diversi spettri di frequenza
-denominati canali. In tal modo si permette la coesistenza di reti
-\textit{wireless} distinte in aree limitrofe o addirittura sovrapposte grazie
-all'uso di canali differenti.
+denominati canali. In tal modo si permette la coesistenza di reti wireless
+distinte in aree limitrofe o addirittura sovrapposte grazie all'uso di canali
+differenti.
 
 \label{salti}
@@ -110,21 +109,18 @@
 \subsubsection{Accesso alla rete}
 \label{sec:accessoallarete}
-\paragraph{Associazione}
-Affinché una stazione mobile possa partecipare ad una rete \textit{wireless}, le
-è fatto obbligo di annunciare la sua presenza attraverso una procedura detta di
-associazione.
-Questo legame unisce una stazione ad uno ed un solo BSS e garantisce che la
-stazione possa effettuare trasmissioni dirette ad ognuno dei nodi appartenente
-all'intera rete e viceversa.
+Affinché una stazione mobile possa partecipare ad una rete wireless, le è fatto
+obbligo di annunciare la sua presenza attraverso una procedura detta di
+\textbf{associazione}. Questo legame unisce una stazione ad uno ed un solo BSS e
+garantisce che la stazione possa effettuare trasmissioni dirette ad ognuno dei
+nodi appartenente all'intera rete e viceversa.\\
 Lo studio intende proprio scardinare l'univocità del rapporto fra stazione
 e BSS che lo standard impone esplicitamente.
 
-\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 \textbf{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
@@ -140,18 +136,4 @@
 una stazione può essere autenticata presso molteplici altre stazioni.
 
-\paragraph{802.11i}
-\label{80211i}
-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).
-Questo genere di comunicazioni viene quindi effettuato a strati di rete
-superiori coinvolgendo marginalmente il livello 802.11 in oggetto.
-È per questa ragione che i dettagli inerenti l'autenticazione ad alto livello
-(pertanto scorrelata da quella di 802.11 da poco descritta) sono sostanzialmente
-irrilevanti per gli scopi del presente studio.
-
 \subsubsection{Risparmio energetico}
 \label{sec:risparmioenergetico}
@@ -159,15 +141,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 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.
+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.
 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} (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}).
+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}).
 \footnotetext{In realtà sarebbe doveroso fare una distinzione fra le reti
 infrastrutturate e quelle indipendenti (o \textit{ad hoc}), nelle quali la
@@ -177,17 +159,17 @@
 \subsubsection{Vincoli temporali}
 \label{sec:vincolitemporali}
-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.
+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.
 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 (si
-veda, più avanti, la sezione \ref{sec:ottimizzazioni}.
+presenti per raffinamenti volti a migliorare l'efficienza delle soluzioni.
 
 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.
+ripartizione equa di questa risorsa. 
+
 Tali regolamentazioni di natura temporale si fondano sulla reciproca
 sincronizzazione delle stazioni che condividono il mezzo fisico, raggiunta
@@ -196,36 +178,35 @@
 Il valore su cui accordarsi viene distribuito all'interno di un \textit{frame}
 di gestione, il \textit{\textbf{beacon}}, inviato ad intervalli regolari e
-prefissati.
-Se già ora si intuisce che l'eventuale perdita di questi messaggi periodici
-durante i salti va minimizzata, ancor di più se ne comprende l'importanza a
-fronte della presenza di ulteriori informazioni di grande interesse per i fini
-preposti.
-\footnotetext{Ancora una volta sarebbe necessaria una distinzione fra le reti
+prefissati. Se già ora si intuisce che l'eventuale perdita di questi messaggi
+periodici durante i salti va minimizzata, ancor di più se ne comprende
+l'importanza a fronte della presenza di ulteriori informazioni di grande
+interesse per i fini preposti.
+
+Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma
+anche degli annunci di 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 comunicazioni in maniera
+spesso più efficiente rispetto a quando il coordinamento è distribuito.
+
+\footnotetext{Ancora una volta è necessaria una distinzione fra le reti
 infrastrutturate e le reti \textit{ad hoc}: il valore comune su cui accordarsi è
 dettato rispettivamente dall'\textit{access point} e dall'intero BSS in maniera
 distribuita.}
 
-Trattasi non solo dei \textbf{TIM} (cfr. \ref{sec:risparmioenergetico}), ma
-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
-comunicazioni in maniera spesso più efficiente rispetto a quando il
-coordinamento è distribuito.
-
-In aggiunta a quanto detto, il \textit{client} non potrà trascurare le
-\textbf{scadenze} temporali oltre le quali i rapporti di autenticazione e
-associazione con i BSS vengono a cadere.
+In aggiunta a quanto detto, il client non potrà trascurare le \textbf{scadenze}
+temporali oltre le quali i rapporti di autenticazione e associazione con i BSS
+vengono a cadere.
 
 \subsection{\textit{Wireless Extensions}}
 \label{sec:wext}
 La portabilità in ambienti GNU/Linux è stata ricercata usando come punto di
-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}.
+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}.
 
 Accanto alle API di programmazione sono stati sviluppati anche gli
@@ -241,380 +222,56 @@
 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 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
+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
 discosta dalla rigidità dello standard.
 
-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 quantomai lontane dalle
+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}.
+
+\subsubsection{Limitazioni}
+\label{sec:limitazioni}
+Le più diffuse implementazioni di 802.11 sono però 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 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}.
+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}.}
 
 A complicare ulteriormente la situazione intervengono le limitazioni imposte
 dalle autorità delle comunicazioni di molti Paesi (si pensi all'FCC
-statunitense\footnotemark), che richiedono la distribuzione dei trasmettitori
-radio con \textit{firmware} in forma necessariamente binaria per scongiurare
+statunitense), 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 (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
-associazioni multiple simultanee, sarà, in tutta la sua complessità, compito
-dell'implementatore della soluzione proposta in \ref{sec:soprailfirmware}.
-
-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.
+%  distanza dallo standard
+% | preautenticazione non implementata da alcuno, probabile assenza di
+%   strutture per supportare autenticazione multipla
+% . powersaving opzionale
 
 \subsection{Caso reale}
 \label{sec:casoreale}
 
-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} Atheros}
-\label{sec:atheros}
-
-I \textit{chipset} Atheros equipaggiano i dispositivi 802.11 di alcuni
-fra i maggiori produttori di \textit{hardware} per la connettività, come
-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.
-
-Proprio per questa ragione la sua distribuzione è vincolata alla presenza di un
-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 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 Atheros ha avuto riscontro
-nel progetto MADWiFi, i \textit{driver} liberi per piattaforme Linux sviluppati
-inizialmente da Sam Leffler.
-Infatti i miglioramenti introdotti dal nuovo HAL sono stati sfruttati
-per l'introduzione di una serie di funzionalità di grande rilevanza.
-Il carattere rivoluzionario rende il progetto, come spesso capita, piuttosto
-instabile ma assai vitale.
-
-\paragraph{VAP}
-L'aspetto indubbiamente più interessante è l'introduzione della modalità
-VAP (\textit{Virtual Access Point}), grazie alla quale è possibile
-virtualizzare il dispositivo creando molteplici interfacce di rete operanti
-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à \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.
-Le interfacce virtuali create possono essere utilizzate comodamente in piena
-trasparenza, essendo aderenti alle \textit{Wireless Extensions}.
-\paragraph{WDS}
-I vari VAP creati possono poi essere eventualmente interconnessi tramite il WDS,
-un'altra delle caratteristiche salienti del driver, che realizza un sistema di
-distribuzione basato su connessioni 802.11 fra i BSS d'interesse, siano
-essi locali (e virtualizzati) o esterni.
-Questa caratteristica risponde agilmente all'esigenza di creazione di
-interconnessioni di differenti reti senza fili.
-\paragraph{Gestione}
-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}
 \label{sec:soluzioni}
-Lo studio di fattibilità in oggetto non può che aver prodotto degli schemi di
-soluzione che coniugano le idee emerse durante la fase di analisi del problema.
-Queste proposte si differenziano per il livello implementativo di riferimento,
-poiché esso comporta un importante \textit{trade-off} fra portabilità ed
-efficienza.
-Quanto più basso, infatti, è il livello al quale si opera, tanto più alta è la
-possibilità di sfruttare appieno le potenzialità del dispositivo, a scapito
-della compatibilità offerta e della facilità implementativa.
-Punto fermo di ogni soluzione proponibile è l'effettuazione di salti periodici
-fra i BSS ai quali il \textit{client} desideri essere ``contemporaneamente''
-associato.
-Le differenze di prestazioni fra le due soluzioni che si proporranno di
-seguito sono dovute proprio ai diversi tempi che i salti periodici
-richiedono, che costituiscono quasi interamente l'\textit{overhead} introdotto.
-
-Si procederà quindi ad illustrare due soluzioni, dimostrando quanto appena
-affermato e calcolando il rapporto fra vantaggi e svantaggi che esse comportano.
-
-\subsection{Sopra il \textit{firmware}}
-\label{sec:soprailfirmware}
-
-\subsubsection{Descrizione}
-Questa soluzione nasce dal desiderio di realizzare associazioni multiple
-effettive per mezzo delle quali, cioé, in ogni istante ciascun BSS consideri il
-\textit{client} regolarmente associato.
-Ciò che si propone consiste sostanzialmente di modifiche al \textit{driver} per
-implementare i salti fra i BSS in maniera tale da evitare la perdita di
-associazione presso ognuno di essi.
-
-\paragraph{Come}
-Per far ciò si deve interagire direttamente (ed eventualmente in maniera
-poco corretta) con l'entità di gestione di 802.11, che si è già chiarito
-risiedere all'interno del \textit{firmware} della scheda \textit{wireless}.
-Soltanto il \textit{driver} sovrastante ha infatti la possibilità di alterare
-determinati stati interni al \textit{firmware} per modificare il comportamento
-di MAC.
-I parametri a cui ci si riferisce sono quelli che regolano i rapporti di
-associazione e autenticazione della stazione: caratteristiche del
-BSS, caratteristiche della crittografia e dell'autenticazione in uso, eventuali
-chiavi temporanee \ldots
-
-\paragraph{Gabola}
-\label{gabola}
-Uno degli aspetti più convincenti di questa soluzione è la possibilità di
-utilizzare la modalità di risparmio energetico (introdotta nella sezione
-\ref{sec:risparmioenergetico}), grazie all'effettività dell'associazione.
-I ripetuti salti costringono il \textit{client} ad assenze dal canale che
-possono infatti essere spacciate senza troppa difficoltà per riposi
-preannunciati, costringendo con l'inganno i BSS a conservare i dati a lui
-diretti. Per completare questa strategia, la stazione simula al suo ritorno un
-risveglio per ricevere l'intera mole di informazioni in attesa di consegna.
-
-\paragraph{Architettura}
-Il \textit{design} della soluzione intende rispondere alle esigenze di
-trasparenza per il sistema operativo e, di conseguenza, per l'utente.
-Le interfacce virtuali, della cui presenza il \textit{driver} è tenuto a
-notificare il SO, aderiscono alle \textit{Wireless Extensions} e si
-differenziano attraverso diversi indirizzi MAC (verosimilmente fittizi).
-Questa forma di \textit{spoofing} è necessaria sia per lo smistamento dei flussi
-in entrata alla stazione e provenienti dai BSS, sia per il convogliamento di
-quelli in uscita dalla stazione e diretti ai vari BSS.
-% 
-%       Grafico della faccenda
-%       OS   [] [] []
-%              \ | /
-%       DRI     \|/
-%       FW      [ ]
-%     ANTENNA    Y
-%              .'  `.
-% BSS1       .'      B1
-% BSS2     B2
-% 
-Così facendo si rende peraltro possibile l'utilizzo di associazioni multiple
-all'interno del medesimo ESS per ridondare la partecipazione.
-La residenza del componente di gestione dei flussi multipli di comunicazione
-all'interno del \textit{driver} lascia chiaramente spazio all'aggiunta di
-politiche per pianificazioni ottimali delle trasmissioni (se ne parlerà più
-approfonditamente in \ref{sec:ottimizzazioni}.
-
-\subsubsection{Vantaggi}
-\begin{description}
- \item [Perdita di dati nulla]:\\
-  \begin{math} \Leftarrow \end{math}
-  i dati in arrivo vengono conservati dai BSS grazie allo sfruttamento della
-  modalità di risparmio energetico (cfr. \ref{sec:risparmioenergetico} e
-  \ref{gabola}).
- \item [Prestazioni massime]:\\
-  \begin{math} \Leftarrow \end{math}
-  l'effettiva associazione multipla minimizza il costo dei salti evitando
-  riautenticazioni e riassociazioni (cfr. \ref{sec:accessoallarete}).
- \item [Trasparenza totale]:\\
-  \begin{math} \Leftarrow \end{math}
-  le interfacce aderenti alle \texttt{wext} nascondono completamente la realtà
-  dei fatti (cfr. \ref{sec:wext}).
- \item [Punto di partenza già disponibile]:\\
-  \begin{math} \Leftarrow \end{math}
-  \texttt{MADWiFi} implementa un sottoinsieme delle funzionalità in oggetto
-  (cfr. \ref{sec:madwifi}).
-\end{description}
-
-\subsubsection{Svantaggi}
-\begin{description}
- \item [Sforzo implementativo considerevole]:\\
-  \begin{math} \Leftarrow \end{math}
-  le nuove funzionalità hanno un prezzo alto, dovendo mantentere le informazioni
-  relative agli stati di autenticazione associazione ed eventualmente
-  sincronizzare la presenza su un BSS ad infrastruttura con i suoi periodi
-  liberi da  contesa (cfr. \ref{sec:vincolitemporali} o
-  \ref{sec:ottimizzazioni});\\
-  \begin{math} \Leftarrow \end{math}
-  per evitare la perdita dei \texttt{beacon}, indispensabili per il rispetto
-  dei vincoli temporali, si è costretti ad una parziale reimplementazione di
-  MAC (cfr. \ref{sec:vincolitemporali});\\
-  \begin{math} \Leftarrow \end{math}
-  il basso livello a cui si è costretti ad agire implica un'intrinseca
-  complessità;\\
-  \begin{math} \Leftarrow \end{math}
-  la forma binaria nella quale i \textit{firmware} sono sovente distribuiti
-  può costringere a noiose operazioni di ingegneria inversa.
- \item [Limitazioni prestazionali]:\\
-  \begin{math} \Leftarrow \end{math}
-  i vincoli temporali dovuti ad esigenze ordinarie (mantenimento
-  dell'associazione) e aggiuntive (ritiro dei dati conservati dai BSS)
-  costringono a salti indesiderati (cfr. \ref{sec:vincolitemporali}).
- \item [Specificità]:\\
-  \begin{math} \Leftarrow \end{math}
-  la dipendenza dalla piattaforma \textit{hardware} sottostante azzera la
-  portabilità;\\
-  \begin{math} \Leftarrow \end{math}
-  lo sviluppo è possibile solo sui rari \textit{firmware} sufficientemente
-  controllabili (cfr. \ref{sec:libertàdazione} e \ref{sec:atheros});\\
-  \begin{math} \Leftarrow \end{math}
-  il supporto alla funzionalità di risparmio energetico dal  lato
-  \textit{client} come da quello BSS è indispensabile per  l'efficienza, (cfr.
-  \ref{sec:risparmioenergetico} e \ref{gabola}).
-\end{description}
-
-\subsection{Sopra il \textit{driver}}
-\label{sec:sopraildriver}
-
-\subsubsection{Descrizione}
-\label{sec:descrizione2}
-Lo spirito con il quale questa soluzione viene concepita è quello di lavorare ad
-alto livello in piena aderenza allo standard, favorendo la portabilità e
-minimizzando, peraltro, gli sforzi implementativi.
-La scelta di interazione con un generico \textit{driver} di sistema per ambienti
-GNU/Linux risponde a queste esigenze obbligando alla rinuncia dell'effettività
-dell'associazione multipla e al pagamento degli esigui costi di riassociazione.
-
-
-\paragraph{Come}
-Come accennato in \ref{sec:interpretazionedellostandard} ogni implementazione
-lega indissolubilmente i concetti di autenticazione e riassociazione,
-vanificando la speranza di mantenere autenticazioni multiple ed obbligando a
-rincarare (spesso non di poco) i costi dei salti fra i BSS.
-Un salto dal BSS1 al BSS2 consta quindi di questa sequenza di operazioni:
-<dissociazione da BSS1, deautenticazione da BSS1, autenticazione con BSS2,
-associazione con BSS2>.
-Si tenga a mente che la persistenza delle autenticazioni a livelli
-superiori (si veda \ref{80211i}) non dovrebbe essere compromessa a causa di
-questa pratica.
-
-\paragraph{Interfacce}
-La portabilità perseguita trova espressione nell'uso delle \textit{Wireless
-Extensions}, in qualità di interfacce unificate dei driver per la piattaforma
-di riferimento.
-Ancor di più, si propone di rendere conformi a queste API le stesse interfacce
-virtuali, create per rappresentare ognuna delle partecipazioni ai BSS nella
-maniera quanto più comoda e trasparente.
-
-\subsubsection{Vantaggi}
-\label{vantaggi2}
-\begin{description}
- \item[Facilità implementativa]:\\
-  \begin{math} \Leftarrow \end{math}
-  il livello implementativo è alto e si interagisce in maniera onesta con il
-  \textit{driver}.
- \item[Trasparenza]:\\
-  \begin{math} \Leftarrow \end{math}
-  la presentazione di interfacce aderenti alle \textsc{wext} oscura la presenza
-  dell'implementazione ai livelli superiori (permettendo compatibilità, ad
-  esempio, con \texttt{wpa\_supplicant}) e ne semplifica la gestione.
- \item[Portabilità]:\\
-  \begin{math} \Leftarrow \end{math}
-  per dialogare con il \textit{driver} sottostante si fa uso delle interfacce
-  \textsc{wext}, disponibili su ogni piattaforma GNU/Linux.
-\end{description}
-
-\subsubsection{Svantaggi}
-\label{svantaggi2}
-
-\begin{description}
- \item [Perdita di dati in arrivo]:\\
-  \begin{math} \Leftarrow \end{math}
-  la perdita di autenticazione e associazione fra un salto e l'altro comporta
-  reali assenze dai BSS che non possono essere evitate; il problema potrebbe
-  essere invero gestito da strati di rete superiori ed affidabili (e.g. TCP).
- \item [Prestazioni mediocri]:\\
-  \begin{math} \Leftarrow \end{math}
-  i salti e le conseguenti operazioni di riautenticazione, riassociazione e
-  risincronizzazione richiedono tempi nell'ordine dei centesimi di secondi. Per
-  avere un'idea dell'entità di questo \textit{overhead} si pensi che lo
-  stesso lasso di tempo potrebbe essere impiegato per la trasmissione di un
-  centinaio di KB.
-
-\end{description}
-\section{Ottimizzazioni}
+
+\section{Ottimizzazioni ulteriori per le scelte di swinging}
 \label{sec:ottimizzazioni}
-Si propone infine una breve trattazione dei fattori che possono essere
-tenuti in considerazione per pianificare oculatamente le trasmissioni al fine
-di ridurre i costi di gestione relativi alle soluzioni descritte in
-\ref{sec:soluzioni}.
-È però compito del lettore valutare, a seconda della soluzione scelta, la
-rilevanza specifica che ognuno di essi riveste.
-
-\begin{description}
- \item [Scadenze temporali]
- Come già esplicitato in \ref{sec:vincolitemporali} sussistono scadenze
- temporali la cui osservanza risulta essere necessaria (\textit{timeout} di
- autenticazione e associazione) o semplicemente conveniente (periodi di
- sincronizzazione dei BSS o di inizio del CFP).
- \item [Impatto dei salti]
- Il costo dei salti può essere calcolato per regolare la frequenza minima con la
- quale essi sono effettuati.
- \item [Caratteristiche delle comunicazioni]
- Date le alte latenze che possono essere prodotte dai salti di BSS, una
- politica di pianificazione delle comunicazioni basata su priorità\footnotemark
- può migliorare la qualità della schedulazione.
- \footnotetext{La qualità di servizio (QoS) suggerita è peraltro oggetto dei
- miglioramenti presenti in \cite{80211e}.}
- \item [Qualità dei BSS]
- Qualora le destinazioni di interesse siano raggiungibili tramite più di uno
- dei BSS di appartenenza, la scelta potrebbe essere banalmente influenzata
- dalla qualità che essi offrono (qualità del segnale, carico di lavoro
- \ldots~).
-
-\end{description}
-
-\clearpage
+
+\section{Bibliografia}
+\label{sec:bibliografia}
 
 \section{Ringraziamenti}
 \label{sec:ringraziamenti}
-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}
