| 62 | | * client singolo connesso a diversi BSS (anche independent?) |
| 63 | | * introduzione |
| 64 | | * obiettivi supplementari: basso overhead (costo intrinseco per il mantenimento) e |
| 65 | | portabilita' |
| 66 | | * livello a cui operare: pro/contro e trade-off tra efficienza |
| 67 | | * breve excursus delle soluzioni analizzate |
| 68 | | * livello di sistema operativo, sopra il firmware |
| 69 | | * descrizione |
| 70 | | * idea: il firmware offre primitive piu' elementari (anche legate a PHY) |
| 71 | | sfruttiamo il firmware a nostro piacimento! |
| 72 | | * il driver sara' in grado di gestire in un unico punto d'entrata le |
| 73 | | interfacce multiple offerte dal SO |
| 74 | | * rivisitazione di MAC, smanettandolo per i nostri sporchi fini |
| 75 | | (cambiamenti vigliacchi di BSSID mask, stato d'associazione, tipi di |
| 76 | | auth) |
| 77 | | * componente scheduler (-> interfacce virtuali) che pianifica le |
| 78 | | trasmissioni |
| 79 | | * -> riscrittura / patching del driver |
| 80 | | * all'esterno (-> idee generali) |
| 81 | | * lo sgamo del power-saving |
| 82 | | * pro |
| 83 | | * nessuna perdita di dati |
| 84 | | * power-saving e bufferizzazione dei dati da parte degli AP |
| 85 | | * buone prestazioni |
| 86 | | * reale associazione multipla -> nessun overhead per |
| 87 | | riautenticazione/riassociazione |
| 88 | | * si puo' non partire da zero (madwifi) |
| 89 | | * contro |
| 90 | | * grosso sforzo per l'implementazione |
| 91 | | * parziale :'-( reimplementazione di MAC per occuparsi di beghe causate |
| 92 | | dalla molteplicita' dei BSS (coordinamento, beacon persi, sottotipi di |
| 93 | | autenticazione/crittografia eventualmente differenti) |
| 94 | | * complessita' intrinseca dovuta al livello |
| 95 | | * firmware spesso solo binari |
| 96 | | * prestazioni non eccellenti |
| 97 | | * power-saving e obblighi temporali (TIM...) |
| 98 | | * troppo specifico |
| 99 | | * dipendenza dalla piattaforma -> portabilita' minima |
| 100 | | * necessita' di power saving |
| 101 | | * scarsa programmabilita' di parecchie implementazioni |
| 102 | | {{{ |
| 103 | | * livello utente, sopra il driver livello driver |
| 104 | | * portabilita' dovuta alle interfacce unificate |
| 105 | | * wext + wpasupplicant |
| 106 | | * ndis |
| 107 | | * overhead di questa soluzione |
| 108 | | * associazione (analisi costi) |
| 109 | | * sincronizzazione (analisi costi) |
| 110 | | * autenticazione (analisi costi) |
| 111 | | * autenticazione multipla - possibilita' e vantaggi effettivi (wext |
| 112 | | e wpa_supplicant) |
| 113 | | * ricezioni mancate ma comunque gestibili dai livelli di rete |
| 114 | | superiori (TCP) |
| 115 | | * conclusione sui costi |
| 116 | | * influenza della frequenza di swing sul troughput effettivo |
| 117 | | * idee implementative generali |
| 118 | | * virtualizzazione delle interfacce di rete (MAC address multipli) |
| 119 | | * gestione in maniera ottimale le scelte di swinging (QoS - priorita' |
| 120 | | delle comunicazioni, sincronizzazione, qualita' dei BSS ...) |
| | 75 | | * client singolo connesso a diversi BSS (anche independent?) |
| | 76 | * obiettivi supplementari |
| | 77 | . * basso overhead (costo intrinseco per il mantenimento) |
| | 78 | . * minimizzare la perdita di dati |
| | 79 | . * portabilita' |
| | 80 | . * facilita` implementativa |
| | 81 | : * virtualizzazione delle interfacce di rete (-> massima trasparenza): |
| | 82 | compliant a wext, con MAC address multipli, bridging/routing triviale, |
| | 83 | wpa_supplicant autentica agile |
| | 84 | |
| | 85 | * Scenario |
| | 86 | : * mezzo fisico partizionato in canali -> necessita` di sfruttarne |
| | 87 | : "contemporaneamente" + di 1 (spesso BSS differenti -> canali differenti) |
| | 88 | * standard |
| | 89 | | * introduzione ai concetti di autenticazione e associazione e alla loro |
| | 90 | | interrelazione (molteplicita` si/no ...) |
| | 91 | * imposizioni temporali |
| | 92 | : * sincronizzazione: beacon, timestamping, CFP ... |
| | 93 | : * mantenimento dell'autenticazione |
| | 94 | * powersaving |
| | 95 | : * notifica dello stato del CLI al AP (power-saving o no) |
| | 96 | : * bufferizzazione |
| | 97 | : * trasmissioni on-demand (PS-poll, TIM ...) |
| | 98 | * Linux Wireless Extensions |
| | 99 | . * interfacce unificate per i driver delle piattaforme GNU/Linux |
| | 100 | . * wireless tools a livello utente |
| | 101 | * implementazioni |
| | 102 | * architettura |
| | 103 | | livello di implementazione dello strato MAC, quasi tutto |
| | 104 | | e` nel firmware, a causa delle esigenze real-time precedentemente |
| | 105 | | menzionate, eccezion fatta per 802.11i (stato dell'autenticazione |
| | 106 | | mantenuto internamente). |
| | 107 | * distanza dallo standard |
| | 108 | | * preautenticazione non implementata da alcuno, probabile assenza di |
| | 109 | | strutture per supportare autenticazione multipla |
| | 110 | . * powersaving opzionale |
| | 111 | : * scarsa programmabilita` dei fw (ed eccezioni: atheros, forse broadcom) |
| | 112 | |
| | 113 | * caso reale |
| | 114 | * Atheros |
| | 115 | . * il chipset |
| | 116 | . * fw molto permissivo |
| | 117 | . * HAL (binarieta` e brevissima descrizione) |
| | 118 | * MADWiFi |
| | 119 | : * possibilita` offerte (modalita` multipla eterogenea) |
| | 120 | . * interfaccia verso l'alto |
| | 121 | |
| | 122 | * Soluzioni |
| | 123 | * trattasi di idee e non di SOLUZIONI FINALI |
| | 124 | : * introduzione sul livello a cui operare: pro/contro e trade-off tra |
| | 125 | : efficienza e portabilita`/facilita` implementativa |
| | 126 | |
| | 127 | * livello di sistema operativo, sopra il firmware |
| | 128 | * descrizione |
| | 129 | | * il firmware offre primitive piu' elementari (anche legate a PHY) |
| | 130 | | sfruttiamo il firmware a nostro piacimento! e riscriviamo/pacciamo un |
| | 131 | | driver |
| | 132 | : * il driver sara' in grado di gestire in un unico punto d'entrata le |
| | 133 | : interfacce multiple offerte dal SO |
| | 134 | | * rivisitazione di MAC, smanettandolo per i nostri sporchi fini |
| | 135 | | (cambiamenti vigliacchi di BSSID mask, stato d'associazione, tipi di |
| | 136 | | auth) |
| | 137 | | * lo sgamo del power-saving, la vigliaccheria, i buffer |
| | 138 | . * componente scheduler (-> interfacce virtuali wext compliant) che |
| | 139 | . pianifica le trasmissioni |
| | 140 | * pro |
| | 141 | : * nessuna perdita di dati |
| | 142 | . * power-saving e bufferizzazione dei dati da parte degli AP |
| | 143 | * buone prestazioni |
| | 144 | . * reale associazione multipla -> nessun overhead per |
| | 145 | . riautenticazione/riassociazione |
| | 146 | . * totale trasparenza grazie alle interfacce wext compliant |
| | 147 | . * si puo' non partire da zero (-> madwifi) |
| | 148 | * contro |
| | 149 | * grosso sforzo per l'implementazione |
| | 150 | . * parziale reimplementazione di MAC per occuparsi di beghe causate |
| | 151 | dalla molteplicita' dei BSS: |
| | 152 | . * tempistiche: sincronizzazione, rilevamento beacon persi ed eventuale |
| | 153 | . sfruttamento dei CFP. (beacon interval noti e mantenimento di informazioni |
| | 154 | . necessarie per ogni BSS) |
| | 155 | . * sottotipi di autenticazione/crittografia: mantenimento chiavi |
| | 156 | . (|di sessione), stato della crittografia e dell'autenticazione. |
| | 157 | . (getter e setter sugli attributi MIB relativi) |
| | 158 | . * complessita' intrinseca dovuta al livello implementativo |
| | 159 | . * firmware spesso solo binari, quindi probabile reverse engineering |
| | 160 | . * prestazioni non eccellenti, perche` limitate da power-saving e relativi |
| | 161 | . obblighi temporali (TIM...) {non posso proprio fare i miei comodi al 100%} |
| | 162 | * troppo specifico |
| | 163 | . * dipendenza dalla piattaforma fw -> portabilita' minima |
| | 164 | . * necessita' di power saving |
| | 165 | . * la soluzione dipende fortemente dal firmware di riferimento, scarsa |
| | 166 | . programmabilita' di parecchie implementazioni |
| | 167 | |
| | 168 | * livello utente, sopra il driver livello driver |
| | 169 | * descrizione |
| | 170 | : * idea: cheppalle riscriversi un driver, chissenefrega degli overhead, |
| | 171 | : lavoriamo pure a livello alto |
| | 172 | . * riassociazione ad ogni cambio di BSS |
| | 173 | . * GNU/Linux e Wireless Extensions come riferimento |
| | 174 | : * forse autenticazione multipla |
| | 175 | . * interfacce virtuali wext compliant (->) |
| | 176 | . * autenticazioni multiple a livelli superiori 802.1x (con wpa_supplicant) |
| | 177 | * pro |
| | 178 | . * facilita` implementativa |
| | 179 | . * totale trasparenza grazie alle interfacce wext compliant (in questo |
| | 180 | . la cosa e` non banale, per il livello implementativo e permette il |
| | 181 | . comodo uso di wpa_supplicant) |
| | 182 | . * portabilita' dovuta alle interfacce unificate |
| | 183 | * contro |
| | 184 | * dataloss [ma si puo` risolvere a livelli superiori (TCP, ATM)] |
| | 185 | : * latenze (|assai) ingenti (con|senza) autenticazione multipla |
| | 186 | * analisi costi vago in termini di ordini di grandezza: |
| | 187 | * associazione |
| | 188 | * sincronizzazione ~ 100 ms |
| | 189 | * autenticazione (PSK) |
| | 190 | |
| | 191 | : * Ottimizzazioni ulteriori (scelte di swinging) |
| | 192 | * obblighi temporali da rispettare [sincronizzazione] |
| | 193 | * costi dello switch |
| | 194 | * qualita' dei BSS (carico di lavoro, segnale) |
| | 195 | * caratteristiche delle comunicazioni (esigenze di interattivita` o meno, |
| | 196 | priorita' ...) -> politiche di QoS di 802.11e |
| | 197 | |
| | 198 | * Bibliografia |
| | 199 | * standard vari |
| | 200 | * la guida definitiva |
| | 201 | * madwifi |
| | 202 | * cisco (che fa figo) |
| | 203 | |
| | 204 | * Ringraziamenti |
| | 205 | * Vittorio Ghini, mentore |
| | 206 | * Luciano Bononi |
| | 207 | * Sam Leffler, autore di HAL (-> Atheros) |
| | 208 | * Jouni Malinen, autore di hostap e wpa_supplicant |
| | 209 | |
| | 210 | |
| | 211 | 8===D - - - |
| | 212 | |
| | 213 | "Non siamo mica dei tecnici" |
| | 214 | |
