| 27 | | * [http://hardware.slashdot.org/comments.pl?sid=89147&cid=7712841 Interessante articolo su SlashDot di un tizio che si e' interessato all'argomento] |
| 28 | | |
| 29 | | ---- |
| 30 | | = Studio di fattibilita': associazione multipla simultanea = |
| 31 | | == Introduzione == |
| 32 | | |
| 33 | | L'avvio e l'approccio di questo studio dipende in maniera forte dagli aspetti |
| 34 | | architetturali del protocollo 802.11. La questione non entra in gioco soltanto |
| 35 | | nel definire una bozza di implementazione, ma, ancor prima, nel comprendere |
| 36 | | quali siano le strade da intraprendere per una realizzazione a livello mentale. |
| 37 | | |
| 38 | | Dalle conoscenze iniziali dell'intero gruppo di lavoro e' risultato evidente |
| 39 | | che la ricerca non poteva perseguire una soluzione che lavorasse al di sopra di |
| 40 | | tutto lo stack IEEE 802.11. In questo tipo di scenario si renderebbe necessaria |
| 41 | | la ri-associazione ad ogni cambio di canale, una operazione che richiede tempi |
| 42 | | lunghi (o biblici, e' da considerare anche l'autenticazione), se comparati ai |
| 43 | | tempi di trasmissione dei dati. |
| 44 | | |
| 45 | | Se come riferimento si prende lo stack ISO/OSI, da quanto detto risulta |
| 46 | | evidente che la ricerca sara' orientata al di sotto del livello "network". |
| 47 | | |
| 48 | | Prima di poter proseguire in maniera sensata, si ritiene pertanto necessario |
| 49 | | approfondire la conoscenza dell'interfaccia offerta dal livello MAC e da quello |
| 50 | | PHY e come esse possano essere utilizzate. In aggiunta a questo e' da chiarire |
| 51 | | quanto forte sia la dipendenza fra il livello PHY e l'hardware del dispositivo |
| 52 | | sottostante. |
| 53 | | |
| 54 | | == Architettura dello standard IEEE 802.11 == |
| 55 | | I due livelli (data link e fisico) su cui lo standard e' definito possiedono |
| 56 | | un insieme di operazioni primitive proprie, ma le loro definizioni sono lungi |
| 57 | | dal poter essere considerate vere e proprie interfacce: si tratta delle "MAC |
| 58 | | layer management entities" (MLME) e delle "PHY layer management entities" |
| 59 | | (PLME). |
| 60 | | E' assai importante notare, specialmente ai fini dello studio in oggetto, che lo |
| 61 | | strato MAC non oscura il sottostante PHY, ma permette alla "station management |
| 62 | | entity" (SME) di interagire direttamente con esso. Le varie entita' hanno la |
| 63 | | possibilita' di comunicare fra loro secondo le specifiche dello standard, |
| 64 | | attraverso i SAP (service access point). Tale concetto intende aggregare |
| 65 | | l'insieme di chiamate che una determinata entita' espone alle altre per |
| 66 | | realizzare forme di comunicazione o invocazione. |
| 67 | | |
| 68 | | {{{ |
| 69 | | __||________________________ |
| 70 | | | | | | |
| 71 | | | MAC | MLME = | |
| 72 | | | | | | |
| 73 | | |--||--|--||--| Station | |
| 74 | | | | | Managemement | |
| 75 | | | PLPC | PLME | Entity | |
| 76 | | | | | | |
| 77 | | |--||--| = | |
| 78 | | | | | | |
| 79 | | | PMD | | | |
| 80 | | |______|______|______________| |
| 81 | | }}} |
| 82 | | |
| 83 | | |
| 84 | | In generale il livello MAC, come ovvio, deve essere il piu' possibile |
| 85 | | indipendente da quello fisico anche se a volte e' necessario che il livello MAC |
| 86 | | gestisca stati opportuni del livello fisico. |
| 87 | | |
| 88 | | Il livello PHY viene suddiviso nella seguente maniera: |
| 89 | | * PLCP (Physical Layer Convergence Procedure): funzioni di convergenza del |
| 90 | | livello fisico (adattamento del medium a PHY service), che realizzano una |
| 91 | | traduzione al fine di rendere l'interfaccia comune; |
| 92 | | * PMD (Physical Medium Dependent): insieme di funzioni fortemente dipendenti |
| 93 | | dallo specifico dispositivo wireless (ad esempio richieste di trasmissione o |
| 94 | | ricezione di dati). |
| 95 | | |
| 96 | | Anche in questo caso le relazioni con l'esterno sono gestite da appositi |
| 97 | | moduli SAP: uno specifico per la porzione PLCP (PMD-SAP) e un altro relativo al |
| 98 | | sottostrato PMD (PMD-SAP). |
| 99 | | |
| 100 | | === Primitive di gestione generica === |
| 101 | | Le informazioni specifiche per la gestione di ogni strato sono incapsulate |
| 102 | | all'interno di cio' che viene definita Management Information Base (MIB) che |
| 103 | | puo' essere visto come un componente di ogni livello. In accordo con questo, |
| 104 | | ogni Management Entity possiede specifiche primitive di GET e SET in |
| 105 | | grado di operare sugli attributi della relativa MIB. Informazioni dettagliate |
| 106 | | sugli attributi dei vari MIB sono presenti nel |
| 107 | | [http://www.xt3.it/reti0506/MIB-D6.2.txt documento ufficiale] |
| 108 | | |
| 109 | | === Interfaccia di MAC: MLME SAP === |
| 110 | | * POWERMGT: richieste al modulo che gestisce il risparmio energetico |
| 111 | | * SCAN: scansione della rete alla ricerca di BSS disponibili |
| 112 | | * JOIN: sincronizzazione con un BSS |
| 113 | | * AUTHENTICATE: autenticazione con un BSS |
| 114 | | * DEAUTHENTICATE: deautenticazione con un BSS |
| 115 | | * ASSOCIATE: associazione fra una STA e un AP |
| 116 | | * REASSOCIATE: associazione fra una STA e un altro AP |
| 117 | | * DEASSOCIATE: disassociazione fra una STA e un AP |
| 118 | | * RESET: azzeramento |
| 119 | | * START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete |
| 120 | | ad-hoc) |
| 121 | | |
| 122 | | === Interfaccia di PHY: PLME SAP === |
| 123 | | In generale si hanno disposizione tutti i getter e i setter necessari per |
| 124 | | manipolare tutti gli attributi del MIB (normati nell'aggiunta `Annex D`). |
| 125 | | Inoltre, si hanno a disposizione le seguenti primitive: |
| 126 | | * PLME-RESET.request: forza il reset del livello PHY, reinizializzandolo allo stato di |
| 127 | | ricezione; |
| 128 | | * PLME-CHARACTERISTICS.request: ritorna le caratteristiche operative della PHY |
| 129 | | entity; |
| 130 | | * PLME-CHARACTERISTICS.confirm: viene sollevata dalla PHY entity successivamente |
| 131 | | ad una PLME-CHARACTERISTICS.request. Fornisce le caratteristiche operative |
| 132 | | della PHY entity; |
| 133 | | * PLME-DSSSTESTMODE.request: utile per entrare in modalita' test in una PHY DSSS |
| 134 | | entity; |
| 135 | | * PLME-DSSSTESTOUTPUT.REQUEST: opzionale, testa i segnali di output di una PHY |
| 136 | | DSSS entity. |
| 137 | | |
| 138 | | |
| 139 | | === Interfaccia di PHY: PLCP e PMD === |
| 140 | | Come gia' accennato in precedenza, le funzioni proprie dello strato PHY sono |
| 141 | | separate nei due livelli distinti PMD e PLCP; quest'ultimo intende fornire il |
| 142 | | meccanismo per trasferire MPDU fra le STA, stando al di sopra del livello PMD. |
| 143 | | Anche in questa sezione, i servizi vengono definiti in maniera puramente |
| 144 | | astratta, in modo da non forzare a particolari implementazioni delle interfacce. |
| 145 | | |
| 146 | | Le primitive tra MAC e PHY si possono dividere in due categorie: |
| 147 | | * primitive per il supporto d'interazioni punto-a-punto a livello MAC |
| 148 | | (primitiva PHY-DATA.{request,confirm,receive,indication}). |
| 149 | | * primitive con significato locale per agevolare l'interazione tra sottolivelli |
| 150 | | (e.g. PHY-TXStart.{request,...}). |
| 151 | | |
| 152 | | === Specifiche della modulazione FHSS === |
| 153 | | Si tratta attualmente della tecnologia piu' diffusa nelle trasmissioni radio. |
| 154 | | Vengono in generale definite un sacco di primitive che vanno dal controllo |
| 155 | | del consumo energetico del medium, alla trasmissione, al CS/CCA. |
| 156 | | Frequency hopping: il salto delle frequenze (channel) e' fatto alfine di |
| 157 | | ottenere un maggior throughput della rete (non si impegna mai una stessa |
| 158 | | frequenza per "troppo" tempo). Questo hopping deve avvenire entro |
| 159 | | un tempo limite di 224us. |
| 160 | | |
| 161 | | == Appunti vari == |
| 162 | | ||20061014-1305||Roma|| |
| 163 | | Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi |
| 164 | | è praticamente una serie di richieste tra il client e l'AP affinchè la |
| 165 | | connessione venga instaurata; nota importante è che il client prima di |
| 166 | | collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP |
| 167 | | manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova |
| 168 | | connessione. Naturalmente vi sono già delle primitive implementate atte a |
| 169 | | svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che |
| 170 | | per le reinstaurazione). |
| 171 | | Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro |
| 172 | | (es che fece anche il seminarista se non ricordo male) e per fare ciò si |
| 173 | | inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte |
| 174 | | comunque c'è l'AP che controlla tutta la sincronizzazione ed egli stesso manda |
| 175 | | pancette ai client conessi a lui; quindi vi è una doppia sincronizzazione: una |
| 176 | | tra AP e client e una tra client e client (cap 11 del documento ieee 802.11). |
| 177 | | |
| 178 | | = MadWifi e l'estensione per VAP = |
| 179 | | ,,20061011-1744: soujak,,[[BR]] |
| 180 | | I driver [http://madwifi.org MadWifi] per schede Atheros su piattaforme Linux |
| 181 | | implementano gia' la funzionalita' di associazione multipla simultanea grazie |
| 182 | | ad [http://madwifi.org/wiki/HAL HAL]. Per ulteriori informazioni si veda il |
| 183 | | relativo [http://madwifi.org/wiki/ngFeatures wiki]. Risulta, come e' chiaro, |
| 184 | | capire quanto l'implementazione della virtualizzazione delle interfacce di rete |
| 185 | | dipenda dal chip Atheros o dall'implementazione del driver e quanto invece la |
| 186 | | funzionalita' possa essere portata anche in scenari differenti. A tal fine si |
| 187 | | consiglia come riferimento gli stessi |
| 188 | | [http://madwifi.org/wiki/UserDocs/GettingMadwifi sorgenti]. |
| 189 | | |
| 190 | | ,,20061013: soujak,,[[BR]] |
| 191 | | Da una rapida occhiata ai driver e alla relativa documentazione (User's Guide e |
| 192 | | README) sono emersi una serie di dettagli rilevanti. |
| 193 | | Anzitutto parte dell'implementazione del driver e' distribuita in forma binaria |
| 194 | | dal produttore della scheda per ottemperare a specifici dettami dell FCC. Una |
| 195 | | scheda wireless e', di fatto, un rice-trasmettitore radio con capacita' |
| 196 | | tecniche (bande in cui poter operare) che possono infrangere quelle che sono le |
| 197 | | limitazioni imposte dalle legislazioni dei vari Paesi per l'utilizzo |
| 198 | | dell'etere. Conseguentemente un firmware (o software?) fornito in forma |
| 199 | | sorgente potrebbe consentire modifiche che potrebbero portare ad infrazioni |
| 200 | | legali, come l'ascolto su canali riservati. La funzionalita' di associazione |
| 201 | | multipla fornita come estensione al driver e' basata su porzioni binarie e |
| 202 | | quindi emergono dubbi sulla sua portabilita', benche' il driver sia basato su |
| 203 | | una implementazione di 802.11 (proveniente da BSD) indipendente dal hardware. |
| 204 | | |
| 205 | | In aggiunta a questo, l'implementazione espone un limite che poco si confa' alla |
| 206 | | genericita' che lo studio intende perseguire. Prima di tutto, l'estensione VAP |
| 207 | | permette soltanto la creazione di piu' AP o l'uso contemporaneo di modalita' |
| 208 | | STA e AP (associato ad un BSS e contemporaneamente Master). Cosi' facendo, si |
| 209 | | aggiungono effettivamente possibilita' interessanti (come eseguire sniffing su |
| 210 | | reti su cui si e' autenticati e addirittura associati), ma se ne precludono |
| 211 | | parecchie altre (si pensi alle reti ''ad-hoc''). |
| 212 | | Inoltre l'implementazione non fa uso di strategie di channel-hopping, pertanto i |
| 213 | | Virtual Access Point sono limitati a coesistere sullo stesso canale e ad |
| 214 | | utilizzare lo stesso livello fisico - un altra limitazione alla quale si spera |
| 215 | | di non dover sottostare. |
| 216 | | |
| 217 | | Altri aspetti del progetto MadWifi e dell'estensione in oggetto possono invece |
| 218 | | rivelarsi interessanti, ad esempio l'interfaccia verso l'alto. Gli sviluppatori |
| 219 | | hanno creato un tool (`wlanconfig`) per facilitare la creazione e la gestione |
| 220 | | di interfacce virtuali che presentano all'utente la molteplicita' di usi della |
| 221 | | medesima scheda fisica. |
| | 29 | * [wiki:MadWifi I driver MadWifi e l'estensione VAP] |
| | 30 | * [http://hardware.slashdot.org/comments.pl?sid=89147&cid=7712841 Interessante articolo su SlashDot] |
