3 | | Questo Wiki intende costituire il punto di riferimento per il gruppo di studenti che sta lavorando al progetto del corso "Laboratorio di reti calcolatori". |
4 | | La ricerca intende analizzare la possibilita' di sfruttare in maniera, possibilmente conveniente, simultanea due reti wireless distinte avendo a disposizione un solo client. |
5 | | Si propone insomma di indagare su tale pratica al fine di avere un'idea quanto piu' esaustiva dei problemi legati ad essa e ad una sua possibile implementazione. |
6 | | |
7 | | Se desiderate contattare l'intero [wiki:Componenti gruppo] per proporre critiche, suggerimenti o riflessioni, potete creare un [http://trac.xt3.it/reti0506/newticket nuovo ticket] oppure spedire un messaggio di posta elettronica all'indirizzo `reti0506[SU]xt3[DOT]it`. |
8 | | |
9 | | Potete trovare le informazioni sugli incontri che ci saranno, o che ci sono stati, nell'apposito [wiki:Calendario Calendario]. |
| 3 | Questo Wiki intende costituire il punto di riferimento per il gruppo di studenti |
| 4 | che sta lavorando al progetto del corso "Laboratorio di reti calcolatori". |
| 5 | La ricerca intende analizzare la possibilita' di sfruttare in maniera, |
| 6 | possibilmente conveniente, simultanea due reti wireless distinte avendo a |
| 7 | disposizione un solo client. |
| 8 | Si propone insomma di indagare su tale pratica al fine di avere un'idea quanto |
| 9 | piu' esaustiva dei problemi legati ad essa e ad una sua possibile |
| 10 | implementazione. |
| 11 | |
| 12 | Se desiderate contattare l'intero [wiki:Componenti gruppo] per proporre |
| 13 | critiche, suggerimenti o riflessioni, potete creare un |
| 14 | [http://trac.xt3.it/reti0506/newticket nuovo ticket] oppure spedire un |
| 15 | messaggio di posta elettronica all'indirizzo `reti0506[SU]xt3[DOT]it`. |
| 16 | |
| 17 | Potete trovare le informazioni sugli incontri che ci saranno, o che ci sono |
| 18 | stati, nell'apposito [wiki:Calendario Calendario]. |
49 | | un insieme di operazioni primitive proprie, ma lungi dal poter essere |
50 | | considerate vere e proprie interfacce: si tratta delle "MAC layer management |
51 | | entities" (MLME) e delle "PHY layer management entities" (PLME). |
52 | | E' assai importante notare che lo strato MAC non oscura il sottostante PHY, ma |
53 | | permette alla "station management entity" (SME) di interagire direttamente con |
54 | | esso. Le varie entita' hanno la possibilita' di comunicare fra loro secondo le |
55 | | specifiche dello standard, attraverso i SAP (service access point). Tale |
56 | | concetto intende aggregare l'insieme di chiamate che una determinata entita' |
57 | | espone alle altre per realizzare forme di comunicazione o invocazione. |
58 | | |
59 | | ||gnappo|| |
| 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 | |
64 | | Le funzioni legate al livello PHY sono distinte nella seguente maniera: |
65 | | * funzioni di convergenza del livello fisico (adattamento del medium a PHY |
66 | | service) - PLCP := Physical Layer Convergence Procedure |
67 | | * PMD (Physical Medium Dependent): insieme di funzioni caratterizzate |
68 | | dallo specifico wireless-medium (trasmissione, ricezione ecc..). |
69 | | |
70 | | Anche in questo caso entra in gioco un SAP specifico per la porzione PMD (PMD |
71 | | SAP) che definisce le interfacce che verranno utilizzate dalle funzioni di |
72 | | convergenza (PMD-SAP). |
| 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). |
75 | | Get e set sugli attributi dello specifico strato |
76 | | |
77 | | === Interfaccia offerta da MLME SAP === |
| 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 === |
90 | | === Interfaccia del livello PHY === |
91 | | Descrizione astratta dei servizi che devono essere forniti al livello MAC: non |
92 | | vi e' alcun riferimento a particolari implementazioni delle interfacce. |
| 122 | === Interfaccia di PHY: PLME SAP === |
| 123 | Oltre alle gia' menzionate primitive di GET e SET, e' presente anche un |
| 124 | piccolo numero di funzioni aggiuntive: |
| 125 | * RESET: reset del dispositivo; |
| 126 | * CHARACTERISTICS: generata da LME durante l'inizializzazione; |
| 127 | * DSSSTESTMODE: mette in modalita' di test il livello DSSS PHY (gli |
| 128 | specifici parametri sono opzionali); |
| 129 | * DSSSTESTOUTPUT: chiede a PHY di generare dei segnali di prova (opzionale); |
| 130 | |
| 131 | === Interfaccia di PHY: PLCP e PMD === |
| 132 | Come gia' accennato in precedenza, le funzioni proprie dello strato PHY sono |
| 133 | separate nei due livelli distinti PMD e PLCP; quest'ultimo intende fornire il |
| 134 | meccanismo per trasferire MPDU fra le STA, stando al di sopra del livello PMD. |
| 135 | Anche in questa sezione, i servizi vengono definiti in maniera puramente |
| 136 | astratta, in modo da non forzare a particolari implementazioni delle interfacce. |
111 | | Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi è praticamente una serie di richieste tra il client e l'AP affinchè la connessione venga instaurata; nota importante è che il client prima di collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova connessione. Naturalmente vi sono già delle primitive implementate atte a svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che per le reinstaurazione). |
112 | | Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro (es che fece anche il seminarista se non ricordo male) e per fare ciò si inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte comunque c'è l'AP che controlla tutta la sincronizzazione ed egli stesso manda pancette ai client conessi a lui; quindi vi è una doppia sincronizzazione: una tra AP e client e una tra client e client (cap 11 del documento ieee 802.11). |
| 155 | Ho letto qualcosa su come si instaura una connessione tra una client e un AP: vi |
| 156 | è praticamente una serie di richieste tra il client e l'AP affinchè la |
| 157 | connessione venga instaurata; nota importante è che il client prima di |
| 158 | collegarsi all'AP deve autenticarsi sull'AP stesso. Una volta fatto cio' AP |
| 159 | manda un pacchetto che indica l'avvenuta autenticazione e l'inizio di una nuova |
| 160 | connessione. Naturalmente vi sono già delle primitive implementate atte a |
| 161 | svolgere questo tipo di compito (sia per quanto riguarda l'instaurazione che |
| 162 | per le reinstaurazione). |
| 163 | Inoltre i vari client devono essere tutti sincronizzati per paralare tra loro |
| 164 | (es che fece anche il seminarista se non ricordo male) e per fare ciò si |
| 165 | inviano delle simpatiche "pancette" con dentro il proprio timestamp; a monte |
| 166 | comunque c'è l'AP che controlla tutta la sincronizzazione ed egli stesso manda |
| 167 | pancette ai client conessi a lui; quindi vi è una doppia sincronizzazione: una |
| 168 | tra AP e client e una tra client e client (cap 11 del documento ieee 802.11). |
116 | | I driver [http://madwifi.org MadWifi] per schede Atheros su piattaforme Linux implementano gia' la funzionalita' di associazione multipla simultanea grazie ad [http://madwifi.org/wiki/HAL HAL]. Per ulteriori informazioni si veda il relativo [http://madwifi.org/wiki/ngFeatures wiki]. Risulta, come e' chiaro, capire quanto l'implementazione della virtualizzazione delle interfacce di rete dipenda dal chip Atheros o dall'implementazione del driver e quanto invece la funzionalita' possa essere portata anche in scenari differenti. A tal fine si consiglia come riferimento gli stessi [http://madwifi.org/wiki/UserDocs/GettingMadwifi sorgenti]. |
| 172 | I driver [http://madwifi.org MadWifi] per schede Atheros su piattaforme Linux |
| 173 | implementano gia' la funzionalita' di associazione multipla simultanea grazie |
| 174 | ad [http://madwifi.org/wiki/HAL HAL]. Per ulteriori informazioni si veda il |
| 175 | relativo [http://madwifi.org/wiki/ngFeatures wiki]. Risulta, come e' chiaro, |
| 176 | capire quanto l'implementazione della virtualizzazione delle interfacce di rete |
| 177 | dipenda dal chip Atheros o dall'implementazione del driver e quanto invece la |
| 178 | funzionalita' possa essere portata anche in scenari differenti. A tal fine si |
| 179 | consiglia come riferimento gli stessi |
| 180 | [http://madwifi.org/wiki/UserDocs/GettingMadwifi sorgenti]. |
119 | | Da una rapida occhiata ai driver e alla relativa documentazione (User's Guide e README) sono emersi una serie di dettagli rilevanti. |
120 | | Anzitutto parte dell'implementazione del driver e' distribuita in forma binaria dal produttore della scheda per ottemperare a specifici dettami dell FCC. Una scheda wireless e', di fatto, un rice-trasmettitore radio con capacita' tecniche (bande in cui poter operare) che possono infrangere quelle che sono le limitazioni imposte dalle legislazioni dei vari Paesi per l'utilizzo dell'etere. Conseguentemente un firmware (o software?) fornito in forma sorgente potrebbe consentire modifiche che potrebbero portare ad infrazioni legali, come l'ascolto su canali riservati. La funzionalita' di associazione multipla fornita come estensione al driver e' basata su porzioni binarie e quindi emergono dubbi sulla sua portabilita', benche' il driver sia basato su una implementazione di 802.11 (proveniente da BSD) indipendente dal hardware. |
121 | | |
122 | | In aggiunta a questo, l'implementazione espone un limite che poco si confa' alla genericita' che lo studio intende perseguire. Prima di tutto, l'estensione VAP permette soltanto la creazione di piu' AP o l'uso contemporaneo di modalita' STA e AP (associato ad un BSS e contemporaneamente Master). Cosi' facendo, si aggiungono effettivamente possibilita' interessanti (come eseguire sniffing su reti su cui si e' autenticati e addirittura associati), ma se ne precludono parecchie altre (si pensi alle reti ''ad-hoc''). |
123 | | Inoltre l'implementazione non fa uso di strategie di channel-hopping, pertanto i Virtual Access Point sono limitati a coesistere sullo stesso canale e ad utilizzare lo stesso livello fisico - un altra limitazione alla quale si spera di non dover sottostare. |
124 | | |
125 | | Altri aspetti del progetto MadWifi e dell'estensione in oggetto possono invece rivelarsi interessanti, ad esempio l'interfaccia verso l'alto. Gli sviluppatori hanno creato un tool (`wlanconfig`) per facilitare la creazione e la gestione di interfacce virtuali che presentano all'utente la molteplicita' di usi della medesima scheda fisica. |
| 183 | Da una rapida occhiata ai driver e alla relativa documentazione (User's Guide e |
| 184 | README) sono emersi una serie di dettagli rilevanti. |
| 185 | Anzitutto parte dell'implementazione del driver e' distribuita in forma binaria |
| 186 | dal produttore della scheda per ottemperare a specifici dettami dell FCC. Una |
| 187 | scheda wireless e', di fatto, un rice-trasmettitore radio con capacita' |
| 188 | tecniche (bande in cui poter operare) che possono infrangere quelle che sono le |
| 189 | limitazioni imposte dalle legislazioni dei vari Paesi per l'utilizzo |
| 190 | dell'etere. Conseguentemente un firmware (o software?) fornito in forma |
| 191 | sorgente potrebbe consentire modifiche che potrebbero portare ad infrazioni |
| 192 | legali, come l'ascolto su canali riservati. La funzionalita' di associazione |
| 193 | multipla fornita come estensione al driver e' basata su porzioni binarie e |
| 194 | quindi emergono dubbi sulla sua portabilita', benche' il driver sia basato su |
| 195 | una implementazione di 802.11 (proveniente da BSD) indipendente dal hardware. |
| 196 | |
| 197 | In aggiunta a questo, l'implementazione espone un limite che poco si confa' alla |
| 198 | genericita' che lo studio intende perseguire. Prima di tutto, l'estensione VAP |
| 199 | permette soltanto la creazione di piu' AP o l'uso contemporaneo di modalita' |
| 200 | STA e AP (associato ad un BSS e contemporaneamente Master). Cosi' facendo, si |
| 201 | aggiungono effettivamente possibilita' interessanti (come eseguire sniffing su |
| 202 | reti su cui si e' autenticati e addirittura associati), ma se ne precludono |
| 203 | parecchie altre (si pensi alle reti ''ad-hoc''). |
| 204 | Inoltre l'implementazione non fa uso di strategie di channel-hopping, pertanto i |
| 205 | Virtual Access Point sono limitati a coesistere sullo stesso canale e ad |
| 206 | utilizzare lo stesso livello fisico - un altra limitazione alla quale si spera |
| 207 | di non dover sottostare. |
| 208 | |
| 209 | Altri aspetti del progetto MadWifi e dell'estensione in oggetto possono invece |
| 210 | rivelarsi interessanti, ad esempio l'interfaccia verso l'alto. Gli sviluppatori |
| 211 | hanno creato un tool (`wlanconfig`) per facilitare la creazione e la gestione |
| 212 | di interfacce virtuali che presentano all'utente la molteplicita' di usi della |
| 213 | medesima scheda fisica. |