WiFi e driver HostAp
1.1 Introduzione
In questo capitolo introduttivo parleremo innanzitutto della tecnologia WiFi, evidenziando in particolar modo le caratteristiche di questo standard e le problematiche annesse.
In seguito illustreremo l’architettura del driver delle schede di rete utilizzato per le prove sperimentali effettuate in questa Tesi, ovvero il driver HostAP versione 0.3.7, relativamente alla sua parte trasmissiva. Infine verrà spiegato il criterio e le motivazioni che hanno portato all’individuazione del punto più idoneo per l’inserimento del framework realizzato in questa Tesi.
Lo standard IEEE 802.11b (noto anche come WiFi, acronimo per Wireless Fidelity) fa parte di un gruppo di specifiche, standard 802.11, sviluppate dall’IEEE per la tecnologia wireless, cioè l’interfaccia via etere tra un client ed una stazione ricetrasmittente.
Fig. 1.1 Struttura dello standard
Lo standard 802.11 del 1997 specificava tre tecniche di trasmissione, tutte ad 1 0 2 Mbps. A detta di molti, le prestazioni fornite erano insufficienti. Il comitato si mise di nuovo al lavoro e nel 1999 furono approvati due nuovi standard:
• 802.11b, compatibile con 802.11, che permetteva di raggiungere velocità trasmissive nell’ordine dei 5.5 e 11 Mbps.
• 802.11a, che, sfruttando una delle più versatili tecniche di modulazione ( 64-QAM), permetteva di raggiungere una velocità trasmissiva pari a 54 Mbps.
Lo standard 802.11a utilizzava però la banda a 5 GHz, e quindi, due anni dopo, il comitato propose una sua variante, 802.11g, che permetteva di raggiungere i 54 Mbps nella banda ISM tradizionale a 2.4 GHz, quindi preservando la compatibilità verso i dispositivi 802.11b.
Molti governi hanno mantenuto libere alcune bande di frequenze, note come bande ISM. Esse possono essere usate liberamente da chiunque, senza dover richiedere licenze, a patto di rispettare precisi limiti di potenza e di utilizzare tecniche di spread spectrum (che consistono nel distribuire il segnale su una banda molto più larga del necessario, in modo che esso appaia come rumore ai dispositivi non interessati alla comunicazione) atte a limitare le interferenze fra i diversi dispositivi.
Molti apparecchi sfruttano le bande ISM:
• telefoni cordless;
• forni a microonde;
• radiocomandi per cancelli automatici e sistemi d’allarme;
• apparati radar;
• Bluetooth
ed interferiscono con il normale funzionamento delle WLAN. In Europa ed in Giappone è disponibile solo la banda a 2.4 GHz mentre negli USA sono disponibili 3 bande, una a 902 MHz, una a 2.4 GHz e l’ultima a 5.725 GHz.
Inoltre all’aumentare della frequenza, aumentano gli effetti di riflessione ed assorbimento delle onde elettromagnetiche e di conseguenza diminuiscono le distanze raggiungibili. In particolare a 2.4 GHz è possibile coprire una distanza 4 volte superiore che a 5GHz.
Per questi ed altri motivi la maggioranza degli standard utilizza la banda ISM a 2.4 GHz.
Lo standard Wifi prevede tre tipi di topologie di rete:
1. Basic Service Set (BSS), nel quale un AP pone in comunicazione tra loro le stazioni wireless (modalità bridge locale);
2. Extended Service Set (ESS): si tratta di una struttura in cui più AP comunicano tra loro, consentendo una ottimizzazione del traffico tra le stazioni;
3. Independent Basic Service Set (IBSS), priva di AP: le stazioni wireless comunicano direttamente tra loro.
Un esempio di questa tipologia di reti sono le MANET (Mobile Ad-Hoc Network);
Sostanzialmente sono presenti quindi due tipi di apparati:
• Le stazioni base di ricetrasmissione AP che fungono da “centro stella” per i collegamenti via etere e da interfaccia (bridge) con le reti locali su rame o fibra.
• Le stazioni WiFi, costituite da computer collegati alla rete 802.11b tramite antenna.
Lo standard 802.11b si riferisce ai primi due livelli del modello ISO/OSI, il livello fisico e al livello Data Link (collegamento). Il livello fisico utilizza un codice CCK (Complementary Code Keying) con modulazione QPSK ( Quadrature Phase Shift Keying ), implementati con tecnologia DSSS (Direct Sequence Spread Spectrum).
Viene utilizzata una variazione dinamica della velocità trasmissiva che viene adattata allo stato del canale sulla base del tasso di errore e del rumore.
Tra il livello fisico di rivelazione della portante ed il sottolivello MAC è presente una codifica con pacchetto denominata PLCP; il sottolivello MAC utilizza la correzione d’errore
CRC e la tecnica di accesso CSMA/CA con codifica della priorità. Mostriamo di seguito uno schema riassuntivo.
1.2.1 Problematiche legate al WiFi
Le reti wireless sono caratterizzate da una serie di problematiche non riscontrabili nei sistemi cablati che impongono una sostanziale revisione e adattamento dei meccanismi di gestione della comunicazione utilizzati in questi ultimi, a partire dalle tecniche di routing per finire con i protocolli di trasporto utilizzati.
Riportiamo di seguito alcune delle problematiche più sentite:
• Scelta di una banda radio disponibile a livello mondiale;
• Problema della stazione nascosta/esposta (hidden node, exposed node);
• Le trasmissioni radio sono soggette ad una elevata rumorosità;
• I segnali radio ad alta frequenza sono soggetti alla riflessione e quindi vengono “ricevuti più volte” con sfasamenti temporali dipendenti dalla lunghezza del percorso compiuto ( multipath fading);
• Minimizzare il consumo delle batterie;
• Le microonde sono ionizzanti ed è quindi necessario limitarne la potenza;
• La mobilità dei computer impone l’uso di tecniche di routing specializzate;
• Molte implementazioni di TCP o UDP sono ottimizzate per sole reti affidabili;
• I dati trasmessi via radio sono facilmente intercettabili e quindi vanno crittografati. Il WiFi supporta un meccanismo per criptare il traffico e autenticare i nodi di connessione che risponde al nome di WEP (Wired Equivalent Privacy, un sistema di encryption basato su una chiave condivisa ai fini della sicurezza contro le intercettazioni, crittografia). La chiave segreta (secret key) lunga 40 bit è concatenata a un vettore di inizializzazione lungo 24 bit; si ottiene così una sequenza di 64 bit totali. Si prevedono per il futuro algoritmi di crittografia WEP a 128 bit, con una chiave segreta di 104 bit in previsione di crescenti requisiti in termini di robustezza e affidabilità.
• Vulnerabilità alle interferenze dovute ai dispositivi che lavorano alle stesse frequenze ( o ad attacchi di tipo “Denial of Service”).
Introduciamo ora il problema che affronteremo in questa Tesi, l’anomalia delle prestazioni che affligge le WLAN dovuta al fatto che gli scheduler tradizionali non tengono conto della qualità del canale wireless.
Prendiamo in esame una situazione tipica dell’ambiente wireless: una stazione mobile che si allontana dall’AP al quale è associato. Naturalmente la qualità del collegamento tra la stazione mobile e l’AP è strettamente correlata alla loro distanza, di conseguenza un allontanamento di una stazione causa un degrado del collegamento che può essere giustificato con l’aumento di fading e interferenze. In questa situazione, qualora la stazione mobile riscontri che le trasmissioni effettuate sono fallite (ad esempio perché non ha ricevuto gli ACK relativi alle ultime trasmissioni) abbassa la propria bit rate variando il tipo di modulazione al fine di prevenire ulteriori
errori. In questo modo abbassa la propria velocità trasmissiva dagli 11 Mbit/sec nominali a 5.5, 2 fino ad arrivare a 1 Mbit/sec.
Quindi, se all’interno di una BSS è presente almeno una stazione che trasmette con una bit rate bassa, in questa cella si verifica una performance anomaly (anomalia delle prestazioni): il throughput di tutte le altre stazioni mobili (che invece trasmettono alla bit rate massima avendo un collegamento di qualità maggiore) subisce un notevole degrado attestandosi al di sotto della bit rate della stazione più lenta.
La ragioni di questa anomalia delle prestazioni è da ricercarsi nella strategia di accesso al mezzo CSMA/CA (Carrier Sensing Mutiple Access Collision Avoidance ) utilizzata nell’ 802.11 la quale ha lo scopo di garantire un accesso al mezzo equo a lungo termine per tutte le stazioni. La stazione mobile con una bassa bit rate occuperà il canale per un tempo maggiore rispetto alle altre stazioni quando ne entra in possesso proprio a causa della sua lentezza, tutto a scapito delle stazioni che trasmettono ad una bit rate maggiore che usufruiranno del canale per un tempo relativamente minore.
In effetti la stazione in posizione cattiva consuma più risorse di quante gliene spetterebbero a scapito delle altre stazioni appartenenti alla BSS.
1.3 Il Driver HostAP versione 0.3.7
Il driver costituisce il mezzo attraverso il quale il software gestisce un dispositivo hardware, come nel caso delle schede di rete o un modem. Il driver che gestisce le schede di rete prism2 utilizzate nelle
prove sperimentali è il driver HostAP-0.3.7 che si può scaricare gratuitamente sul sito www.epitest.fi.
La parte di codice analizzata in questo paragrafo è quella relativa alla parte trasmissiva del driver HostAP, ovvero verrà analizzata la successione delle funzioni chiamate durante la fase della trasmissione dei pacchetti.
Tra tutti i “moduli” costituenti il sorgente del driver, ci soffermeremo in particolar modo su due di loro:
• hostap_80211_tx.c
• hostap_hw.c
Per avere una chiara idea visiva sul ruolo svolto dalle funzioni chiamate in causa si faccia riferimento allo schema riportato nella pagina seguente.
LIVELLI SUPERIORI IP LAYER DATA DEVICE wlan0 hostap_data_start_xmit () { …….. dev_queue_xmit(skb) } MASTER DEVICE wifi 0 TRAFFIC CONTROL hostap_master_start_xmit () { ……. ……. local->func->tx } prism2_tx_80211 () { …… …… prism2_transmit () } HARDWARE
Il punto di partenza della nostra trattazione è la funzione hostap_data_start_xmit, presente nel modulo hostap_80211_tx.c, la quale riceve in ingresso i pacchetti dai livelli protocollari superiori e si preoccupa di “indirizzarli” verso l’opportuno dispositivo fisico che si occuperà in seguito della loro effettiva trasmissione.
In sostanza la funzione hostap_data_start_xmit è la hard_start_xmit() per la interfaccia dati di tipo wlan0, che possiamo considerare un “dispositivo virtuale ” che ha il compito di costruire la trama IEEE 802.11 in tutti i suoi campi per poi passarla al corretto dispositivo fisico di tipo wifi0 (master device) che effettuerà la trasmissione della trama 802.11 ricevuta in ingresso.
E’ doveroso precisare che con il termine dev_queue_xmit () intendiamo la funzione che si occupa di accodare pacchetti in una coda relativa ad un certo dispositivo (sia fisico come wifi0 che virtuale come wlan0) mentre con il termine hard_start_xmit () intendiamo la funzione che si occupa di estrarre pacchetti dalla coda relativa a quel dispositivo.
Nel nostro caso quindi la funzione hostap_data_start_xmit è la hard_start_xmit per il dispositivo wlan0 e al tempo stesso al suo interno contiene la dev_queue_xmit per il dispositivo wifi0, mentre la funzione hostap_master_start_xmit è la hard_start_xmit per il dispositivo fisico wifi0.
Riportiamo nella pagina successiva un grafico che mira a chiarire il meccanismo di accodamento dei pacchetti all’interno dei vari device presenti nel driver HostAP.
IP LAYER dev_queue_xmit(skb) CODA DISPOSITIVO wlan0 hostap_data_start_xmit () dev_queue_xmit(skb) CODA DISPOSITIVO wifi0 hostap_master_start_xmit () local->tx_func prism2_tx_80211 () | V prism2_transmit () | V CODA HARDWARE
Fig. 1.4 Successione code dei diversi device nel driver HostAP
Dopo aver illustrato l’architettura del driver continuiamo con l’analisi delle funzioni che abbiamo precedentemente menzionato.
La funzione hostap_data_start_xmit riceve in ingresso due parametri:
che individua univocamente un pacchetto.
• struct net_device *dev, un puntatore alla struttura net_device che individua univocamente il dispositivo, in questo caso wlan0.
Il ruolo svolto da questa funzione è quello di convertire l’header Ethernet (formato nel quale ricevo il pacchetto dai livelli superiori) nell’header IEEE 802.11 in base alla configurazione del dispositivo, che può operare in quel momento in una qualsiasi modalità, sia essa master (cioè sta fungendo da AP), managed (cioè è una stazione gestita da un AP) o ad-hoc (cioè un nodo mobile appartenente ad una MANET).
Mostriamo di seguito la struttura dell’header 802.11:
Fig. 1.5 Struttura dell’header di un frame 802.11
Sfruttando le informazioni passate dai livelli superiori la funzione hostap_data_start_xmit riesce a riempire e completare
opportunamente i campi ancora vuoti del Frame Control e soprattutto degli indirizzi.
Nelle tabelle riportate di seguito per completezza mostriamo i possibili valori assunti dai campi Type e Subtype del Frame Control che identificano rispettivamente il tipo di frame (management, control o data) e la funzione specifica del pacchetto.
Fig. 1.6 Possibili valori assunti dal campo Subtype nel caso di un frame di tipo management
Fig. 1.7 Possibili valori assunti dal campo Subtype nel caso di un frame di tipo control
Fig. 1.8 Possibili valori assunti dal campo Subtype nel caso di un frame di tipo data
Il riempimento dei quattro campi relativi agli indirizzi merita una particolare attenzione.
Grazie alle tabelle riportate di seguito vediamo come avviene la classificazione dei pacchetti e, in base a questa classificazione, in che maniera vengono riempiti i campi relativi agli indirizzi.
Fig. 1.9 Tabella relativa alla classificazione dei pacchetti
Riempiendo i membri della struttura hostap_ieee80211_hdr hdr (presente nella funzione ma definita in hostap_80211.h)
struct hostap_ieee80211_hdr { u16 frame_control; u16 duration_id; u8 addr1[6]; u8 addr2[6]; u8 addr3[6]; u16 seq_ctrl; u8 addr4[6]; } __attribute__ ((packed));
la funzione hostap_data_start_xmit costruisce l’header 802.11 sfruttando il valore dei bit From/To DS e acquisendo le informazioni già presenti nel Frame Control sul Type e Subtype del frame:
Fig. 1.10 Modalità riempimento dei campi di indirizzamento Una volta scritti i campi di sua competenza e aggiornato le ultime statistiche, tra le quali riportiamo l’aggiornamento dei pacchetti trasmessi e quello dei byte contenuti in essi
hdr.frame_control = cpu_to_le16(fc); iface->stats.tx_packets++;
iface->stats.tx_bytes += skb->len;
alla funzione hostap_data_start_xmit non resta che accodare il pacchetto appena “rimodellato” nella coda del dispositivo wifi0. Da notare infine che il valore restituito dalla hostap_data_start_xmit è sempre 0 e che inoltre in caso di errore effettua la kfree_skb() liberando così la memoria riservata al pacchetto appena scartato. Vedremo in seguito perché questo aspetto è molto importante per la realizzazione del framework presentato in questa Tesi.
La hostap_master_start_xmit riceve in ingresso due parametri:
• struct sk_buff *skb, un puntatore skb alla struttura sk_buff che individua univocamente un pacchetto.
• struct net_device *dev, un puntatore alla struttura net_device che individua univocamente il dispositivo, in questo caso wifi0.
A differenza della hostap_data_start_xmit, ora l’intestazione del pacchetto (sempre individuato dal puntatore skb), si riferisce ad un frame IEEE 802.11 e non più ad una trama Ethernet.
Questa funzione è di cruciale importanza in quanto, oltre a svolgere operazioni di processing dell’AP come ad esempio il controllo sulla velocità trasmissiva o l’encryption dei dati, chiama al suo interno la hardware TX function, cioè la funzione che fisicamente si occupa della trasmissione del pacchetto. Questa funzione risponde al nome di prism2_tx_80211.
Questa funzione rappresenta quindi il punto più basso in cui poter inserire un modulo per la gestione delle code di pacchetti, “al di sotto” di lei entra in gioco l’hardware e quindi l’unica coda fisica FIFO messa a disposizione dallo standard.
In realtà la prism2_tx_80211 non viene chiamata direttamente, bensì tramite il puntatore a funzione local->func->tx(skb,dev).
Riportiamo di seguito le righe di codice relative alla chiamata della funzione prism2_tx_80211:
if (local->func->tx == NULL || local->func-> tx(skb, dev)) { ret = 0; meta->iface->stats.tx_dropped++; } else { ret = 0; meta->iface-> stats.tx_packets++; meta->iface->stats.tx_bytes += skb->len; }
La funzione prism2_tx_802.11 è definita infatti nel modulo hostap_hw.c dove è presente nell’init_module l’operazione di assegnamento:
local->func->tx = prism2_tx_80211;
che giustifica quanto affermato precedentemente.
Anche la prism2_tx_80211 riceve in ingresso due parametri:
• struct sk_buff *skb, un puntatore skb alla struttura sk_buff che individua univocamente un pacchetto.
• struct net_device *dev, un puntatore alla struttura net_device che individua univocamente il dispositivo.
I compiti della prism2_tx_80211 sono quelli di convertire l’header 802.11 (che era stato riempito da hostap_data_start_xmit) nel prism2 TX descriptor e di inviare il payload con questo descrittore.
La struttura relativa a questo descrittore è la struttura
hfa384x_tx_frame nella quale possiamo notare la presenza dei campi relativi al rate trasmissivo, al frame control e agli indirizzi.
struct hfa384x_tx_frame { /* HFA384X TX frame descriptor */ u16 status; /* HFA384X_TX_STATUS_ flags */ u16 reserved1; u16 reserved2; u32 sw_support; u8 retry_count; /* not yet implemented */
u8 tx_rate; /*Host AP only; 0 = firmware, or 10,20,55,110*/ u16 tx_control; /* HFA384X_TX_CTRL_ flags */ /* 802.11 */ u16 frame_control; /* parts not used */
u16 duration_id; u8 addr1[6]; u8 addr2[6]; /* filled by firmware */ u8 addr3[6]; u16 seq_ctrl; /* filled by firmware */ u8 addr4[6]; u16 data_len; /* 802.3 */ u8 dst_addr[6]; u8 src_addr[6]; u16 len;
/* followed by frame data; max 2304 bytes */
} __attribute__ ((packed));
Tale struttura è definita in hostap_wlan.h.
Una volta convertito l’header 802.11 nel TX descriptor il frame può essere finalmente trasmesso.
All’interno di prism2_tx_80211 viene chiamata la funzione prism2_transmit () che ha il compito di scrivere il TX command nel command register, che è il registro usato per scrivere i comandi (event command) che devono essere eseguiti.
La funzione prism2_cmd_ev viene chiamata dall’hardware interrupt handler prism2_interrupt (chiamata quindi solo da hardware IRQ) per gestire l’evento scritto nel command register.
A seguito di un event command generato dal firmware,
prism2_interrupt (che possiede lo stato di tale evento leggendo il bit settato dal firmware nell’event register, ad esempio TX o TXEXC a seguito di un TX command) in accordo con l’evento riscontrato chiama la funzione o schedula il tasklet corrispondente (per trasmissioni andate a buon fine viene schedulato prism2_tx_ev mentre a seguito di una trasmissione fallita viene schedulato prism2_tx_exc).
Per concludere questo paragrafo riportiamo nella pagina successiva uno schema con l’intento di chiarire le ultime fasi del processo trasmissivo appena descritte.
FIRMWARE
scrive l’event command nell’event register prism2_tx_80211 ( ) prism2_transmit ( ) HARDWARE INTERRUPT prism2_interrupt ( ) prism2_tx_ev prism2_txexc prism2_cmd_ev SOFTWARE INTERRUPT TASKLET SOFTWARE INTERRUPT TASKLET SOFTWARE INTERRUPT TASKLET
Fig. 1.11 Descrizione parte trasmissiva hardware
1.4 Motivazioni riguardo la scelta sul punto di inserimento del framework
Dopo aver presentato l’architettura del driver HostAP è possibile motivare e comprendere le scelte che hanno portato alla
realizzazione del framework.
Anzitutto ricordiamo quali sono le specifiche di progetto da rispettare:
• Realizzazione di uno scheduler channel aware, cioè che tenga conto della qualità del canale wireless;
• Modificare architetture pre-esistenti o realizzare una nuova architettura al fine di superare il problema noto come “anomalia dell’802.11”.
L’ idea di base è mantenere il buffer della scheda di rete vuoto al fine di evitare l’accumulo di pacchetti verso una destinazione in posizione cattiva;
• Riuscire a sfruttare la ricezione degli ACK per stimare la qualità del canale utilizzando una sola scheda di rete senza ricorrere ad una ulteriore scheda in modalità monitor;
• Lavorare in modalità master, ovvero fungere da AP. La scelta è ricaduta, dopo una attenta ed accurata analisi, sulla realizzazione di una nuova architettura da inserire all’interno del device driver che fosse il più generale possibile, ovvero che permettesse di gestire diverse discipline di scheduling basate su filosofie differenti.
Il primo problema da affrontare è stato individuare il punto migliore per l’inserimento del framework, un punto nel quale “non si dava fastidio” all’architettura pre-esistente e si riuscivano ad ottenere le informazioni necessarie per lo scheduling.
A prima vista le funzioni più interessanti sembravano essere la hostap_data_start_xmit (già scelta in [bibliog Annese] per realizzare un framework orientato allo standard 802.11e) e la
hostap_master_start_xmit.
Riportiamo le righe di codice inserite in [bibliog Annese] per realizzare l’inserimento del proprio modulo:
int hostap_data_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct sk_buff *skb2q; if(atomic_read(&queue_mgr_present)==1){ skb2q = skb_copy(skb,GFP_ATOMIC); dev_kfree_skb(skb); queue_mgr_new_skb(skb2q, dev); return 0; } else{
return real_prism2_tx(skb, dev); }
Tra le due funzioni c’è però una differenza sostanziale: la prima si trova al di sopra del livello del Traffic Control mentre l’altra sta al di sotto.
Il punto cruciale è il seguente: si può lavorare sul device driver senza dover obbligatoriamente sfruttare o tener conto del Traffic Control ? Analizzando il funzionamento del Traffic Control si riesce a dare una risposta a questa domanda, e la risposta è (ovviamente) affermativa.
Questa risposta viene fuori osservando che:
1. Ogni volta che viene chiamata la dev_queue_xmit per il dispositivo wlan0 nel Traffic Control viene chiamata la funzione q->enqueue() che realizza l’accodamento del pacchetto. Questa funzione ritorna sempre un valore maggiore di zero, quindi mai negativo, anche in caso di
errore, nel qual caso effettua solo la dev_kfree_skb non ritornando valori come -EPERM. L’importanza del valore ritornato dalla funzione chiamata deriva dalle informazioni implicite che esso fornisce ai livelli “di sopra”, cioè alle funzioni chiamanti.
2. La dev_kfree_skb va fatta solo in caso di errore. Quindi, se il funzionamento è corretto, la dev_kfree_skb verrà effettuata “dal livello sottostante” non appena esso ha finito di trasmettere il pacchetto oppure ha riscontrato un qualsiasi errore su di esso, comunque sia in maniera del tutto trasparente per il nostro framework.
Abbiamo visto che il valore ritornato dalla hostap_data_start_xmit è sempre 0, quindi l’inserimento effettuato da [bibliog Annese] per il suo framework è giustificato.
L’idea è però quella di inserire il framework il più “vicino possibile” all’ hardware in modo tale da gestire con maggior prontezza e velocità tutti gli eventi.
Anche la funzione hostap_master_start_xmit torna sempre 0, quindi, valendo le stesse considerazioni fatte precedentemente, risulta essere anche essa un buon punto per l’inserimento del framework.
Inoltre la funzione hostap_master_start_xmit riceve in ingresso un puntatore skb che punta all’header del frame 802.11 e quindi permette di ottenere facilmente le informazioni riguardanti i campi di indirizzamento necessari al fine di effettuare una classificazione dei pacchetti basata sull’indirizzo MAC del nodo di destinazione.
In conclusione la funzione hostap_master_start_xmit è la funzione scelta per effettuare l’inserimento del framework all’interno del device driver.
Riportiamo di seguito le righe di codice che mi hanno permesso di effettuare l’inserimento del nostro framework:
int hostap_master_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct sk_buff *skb2q; if(atomic_read(&sched_queue_mgr_present)==1){ skb2q = skb_copy(skb,GFP_ATOMIC); dev_kfree_skb(skb); queue_mgr_new_skb(skb2q, dev); return 0; } else{
return real_prism2_tx(skb, dev);
Un’ altra importante considerazione da fare è che di default il driver HostAP non gestisce le notifiche per tutte le trasmissioni andate a buon fine, ovvero per la ricezione degli ACK, con l’intento di salvaguardare l’utilizzo della CPU.
Questo meccanismo viene utilizzato solo per riscontrare i frame di management.
Ciò è comprensibile se si pensa che gli algoritmi di scheduling attuali non sono channel aware e quindi non necessitano di conoscere informazioni quali l’istante di ricezione di un ACK o l’esito dell’ultima trasmissione.
Al contrario il nostro framework ha bisogno di conoscere queste informazioni per poter funzionare correttamente.
Per ricevere un TX (OK) event (ovvero uno dei command event che il firmware gestisce e per cui manda un interrupt hardware verso prism2_interrupt che schedula il tasklet corrispondente, in questo caso prism2_tx_ev) per ogni ACK ricevuto occorre modificare leggermente il driver HostAP.
E’ necessario aggiungere il flag HFA384X_TX_CTRL_TX_OK al campo tx_control.
E’ possibile ottenere questo risultato in due modi:
• modificando la macro HFA384X_TX_CTRL_FLAGS definita in hostap_hw.c inserendo anche il caso HFA384X_TX_CTRL_TX_OK
• aggiungendo un OR al flag local->tx_control sempre contenuto in hostap_hw.c, cioè facendo
local->tx_control | HFA384X_TX_CTRL_TX_OK.
Un’altra importante precisazione da fare è che il framework non considera trasmissione fallita ogni ritrasmissione effettuata al fine di trasmettere un frame, ma considera fallita una trasmissione solo quando dall’hardware viene settato il bit txexc nell’event register, ovvero solo quando si è raggiunto il retry_limit per le ritrasmissioni.
A conclusione di questo capitolo si riporta nella pagina seguente uno schema dell’inserimento del framework all’interno dell’architettura pre-esistente.
