| 23 | | ''20061014-1305''[[BR]] |
| 24 | | 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). |
| 25 | | 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). |
| 26 | | |
| 27 | | ---- |
| 28 | | ||''La seguente introduzione intende descrivere in maniera sintetica quanto detto, discusso, analizzato fino ad ora.''|| |
| | 18 | == Introduzione == |
| | 19 | ||''Si intende descrivere in maniera sintetica quanto detto, discusso, analizzato fino ad ora.''|| |
| | 55 | ||gnappo|| |
| | 56 | In generale il livello MAC, come ovvio, deve essere il piu' possibile |
| | 57 | indipendente da quello fisico anche se a volte e' necessario che il livello MAC |
| | 58 | gestisca stati opportuni del livello fisico. |
| | 59 | |
| | 60 | Le funzioni legate al livello PHY sono distinte nella seguente maniera: |
| | 61 | * funzioni di convergenza del livello fisico (adattamento del medium a PHY |
| | 62 | service) - PLCP := Physical Layer Convergence Procedure |
| | 63 | * PMD (Physical Medium Dependent): insieme di funzioni caratterizzate |
| | 64 | dallo specifico wireless-medium (trasmissione, ricezione ecc..). |
| | 65 | |
| | 66 | Anche in questo caso entra in gioco un SAP specifico per la porzione PMD (PMD |
| | 67 | SAP) che definisce le interfacce che verranno utilizzate dalle funzioni di |
| | 68 | convergenza (PMD-SAP). |
| | 69 | |
| 79 | | ==== Interfaccia del PLME SAP ==== |
| 80 | | ||''La sezione e' volutamente vuota perche' da completare''|| |
| 81 | | |
| 82 | | |
| 83 | | |
| 84 | | == Appunti sul livello fisico == |
| 85 | | |
| 86 | | |
| 87 | | In generale il livello MAC, come ovvio, deve essere il piu' possibile |
| 88 | | indipendente da quello fisico anche se a volte e' necessario che il livello MAC |
| 89 | | gestisca stati opportuni del livello fisico. |
| 90 | | |
| 91 | | |
| 92 | | === PHY === |
| 93 | | |
| 94 | | 802.11 definisce sostanzialmente due classi di funzioni di protocollo: |
| 95 | | * funzioni di convergenza del livello fisico (adattamento del medium a PHY |
| 96 | | service) - PLCP := Physical Layer Convergence Procedure |
| 97 | | * PMD (Physical Medium Dependent): insieme di funzioni caratterizzate |
| 98 | | dallo specifico wireless-medium (trasmissione, ricezione ecc..). |
| 99 | | |
| 100 | | Il servizio di livello fisico (PHY service) e' fruibile dal MAC attraverso il |
| 101 | | SAP (Service Access Point). |
| 102 | | Similmente e' possibile definire delle interfacce tra il PMD e le funzioni di |
| 103 | | convergenza (PMD-SAP). |
| 104 | | |
| 105 | | === PHY Service === |
| 106 | | |
| | 86 | === Interfaccia del PLME SAP === |
| | 104 | |
| | 105 | == Appunti vari == |
| | 106 | ||20061014-1305||Roma|| |
| | 107 | 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). |
| | 108 | 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). |
| | 109 | |
| | 110 | |
| | 111 | == MadWifi e l'estensione per VAP == |
| | 112 | ||20061011-1744||soujak|| |
| | 113 | 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]. Al momento, dunque, gli sforzi sono indirizzati a 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]. |
| | 114 | ||20061013||soujak|| |
| | 115 | Da una rapida occhiata ai driver e alla relativa documentazione (User's Guide e README) sono emersi una serie di dettagli rilevanti. |
| | 116 | 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-trsmettitore radio con capacita' tecniche (bande in cui poter operare) che possono infrangere quelle che sono le limitazioni imposte dagli Stati Uniti 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. |
| | 117 | |
| | 118 | In aggiunta a questo, l'implementazione espone un limite che poco si confanno 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''). |
| | 119 | 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. |
| | 120 | |
| | 121 | 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 la creazione e la gestione di interfacce virtuali. |
