Studio di fattibilita': singolo client wireless connesso a due differenti reti

Questo Wiki intende costituire il punto di riferimento per il gruppo di studenti che sta lavorando al progetto del corso "Laboratorio di reti calcolatori". La ricerca intende analizzare la possibilita' di sfruttare in maniera, possibilmente conveniente, simultanea due reti wireless distinte avendo a disposizione un solo client. 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.

Se desiderate contattare l'intero gruppo per proporre critiche, suggerimenti o riflessioni, potete creare un nuovo ticket oppure spedire un messaggio di posta elettronica all'indirizzo reti0506[SU]xt3[DOT]it.

Potete trovare le informazioni sugli incontri che ci saranno, o che ci sono stati nel CalenDario.

Ultime modifiche

Link utili

• Specifiche ufficiali del protocollo:
  • ​IEEE 802.11 - prima versione considerata legacy (1999)
  • ​IEEE 802.11b - miglioramento del 802.11 col supporto di 5.5 e 11 Mbit/s (1999)
  • ​IEEE 802.11g - 54 Mbit/s, 2.4 GHz standard (compatibile con il 802.11b) (2003)
• ​Interessante articolo su SlashDot di un tizio che si e' interessato all'argomento

---

Introduzione

Si intende descrivere in maniera sintetica quanto detto, discusso, analizzato fino ad ora.

L'avvio e l'approccio di questo studio dipende in maniera forte dagli aspetti architetturali del protocollo 802.11. La questione non entra in gioco soltanto nel definire una bozza di implementazione, ma, ancor prima, nel comprendere quali siano le strade da intraprendere per una realizzazione a livello mentale.

Dalle conoscenze iniziali dell'intero gruppo di lavoro e' risultato evidente che la ricerca non poteva perseguire una soluzione che lavorasse al di sopra di tutto lo stack IEEE 802.11. In questo tipo di scenario si renderebbe necessaria la ri-associazione ad ogni cambio di canale, una operazione che richiede tempi lunghi (o biblici, e' da considerare anche l'autenticazione), se comparati ai tempi di trasmissione dei dati.

Se come riferimento si prende lo stack ISO/OSI, da quanto detto risulta evidente che la ricerca sara' orientata al di sotto del livello "network".

Prima di poter proseguire in maniera sensata, si ritiene pertanto necessario approfondire la conoscenza dell'interfaccia offerta dal livello MAC e da quello PHY e come esse possano essere utilizzate. In aggiunta a questo e' da chiarire quanto forte sia la dipendenza fra il livello PHY e l'hardware del dispositivo sottostante.

Architettura dello standard IEEE 802.11

SoujaK

I due livelli (data link e fisico) su cui lo standard e' definito possiedono un insieme di operazioni primitive proprie, ma lungi dal poter essere considerate vere e proprie interfacce: si tratta delle "MAC layer management entities" (MLME) e delle "PHY layer management entities" (PLME). E' assai importante notare che lo strato MAC non oscura il sottostante PHY, ma permette alla "station management entity" (SME) di interagire direttamente con esso. Le varie entita' hanno la possibilita' di comunicare fra loro secondo le specifiche dello standard, attraverso i SAP (service access point). Tale concetto intende aggregare l'insieme di chiamate che una determinata entita' espone alle altre per realizzare forme di comunicazione o invocazione.

gnappo

In generale il livello MAC, come ovvio, deve essere il piu' possibile indipendente da quello fisico anche se a volte e' necessario che il livello MAC gestisca stati opportuni del livello fisico.

Le funzioni legate al livello PHY sono distinte nella seguente maniera:

• funzioni di convergenza del livello fisico (adattamento del medium a PHY service) - PLCP := Physical Layer Convergence Procedure
• PMD (Physical Medium Dependent): insieme di funzioni caratterizzate dallo specifico wireless-medium (trasmissione, ricezione ecc..).

Anche in questo caso entra in gioco un SAP specifico per la porzione PMD (PMD SAP) che definisce le interfacce che verranno utilizzate dalle funzioni di convergenza (PMD-SAP).

Primitive di gestione generica

Get e set sugli attributi dello specifico strato

Interfaccia offerta da MLME SAP

• POWERMGT: richieste al modulo che gestisce il risparmio energetico
• SCAN: scansione della rete alla ricerca di BSS disponibili
• JOIN: sincronizzazione con un BSS
• AUTHENTICATE: autenticazione con un BSS
• DEAUTHENTICATE: deautenticazione con un BSS
• ASSOCIATE: associazione fra una STA e un AP
• REASSOCIATE: associazione fra una STA e un altro AP
• DEASSOCIATE: disassociazione fra una STA e un AP
• RESET: azzeramento
• START: creazione di un nuovo BSS (diventa AP) o IBSS (prima STA di una rete ad-hoc)

Interfaccia del livello PHY

Descrizione astratta dei servizi che devono essere forniti al livello MAC: non vi e' alcun riferimento a particolari implementazioni delle interfacce.

Le primitive tra MAC e PHY si possono dividere in due categorie:

• primitive per il supporto d'interazioni punto-a-punto a livello MAC (primitiva PHY-DATA.{request,confirm,receive,indication}).
• primitive con significato locale per agevolare l'interazione tra sottolivelli (e.g. PHY-TXStart.{request,...}).

FHSS (Frequency hopping spread spectrum) PHY specifications for the 2.4GHz band

Si tratta attualmente della tecnologia piu' diffusa nelle trasmissioni radio. Vengono in generale definite un sacco di primitive che vanno dal controllo del consumo energetico del medium, alla trasmissione, al CS/CCA. Frequency hopping: il salto delle frequenze (channel) e' fatto alfine di ottenere un maggior throughput della rete (non si impegna mai una stessa frequenza per "troppo" tempo). Questo hopping deve avvenire entro un tempo limite di 224us.

Appunti vari

20061014-1305

Roma

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). 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).

MadWifi e l'estensione per VAP

20061011-1744

soujak

I driver ​MadWifi per schede Atheros su piattaforme Linux implementano gia' la funzionalita' di associazione multipla simultanea grazie ad ​HAL. Per ulteriori informazioni si veda il relativo ​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 ​sorgenti.

20061013

soujak

Da una rapida occhiata ai driver e alla relativa documentazione (User's Guide e README) sono emersi una serie di dettagli rilevanti. 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.

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). 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.

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.