Implementazione della modalità SplitMAC del protocollo CAPWAP Relatore: Prof. Massimo Bernaschi Candidato: Sotiraq Sima La mia tesi consiste alla gestione di reti wireless di grande dimensione, in particolare ho sviluppato la modalità SplitMAC per il protocollo CAPWAP. Corso di Laurea Specialistica in Informatica A.A. 2011/2012

Modalità Operative per CAPWAP Il Progetto OpenCAPWAP Indice Il protocollo CAPWAP Modalità Operative per CAPWAP Il Progetto OpenCAPWAP Mac80211 e Hostapd Disegno della modalità SplitMAC Risultati di Test Sviluppi futuri Inizialmente presenterò il protocollo CAPWAP, e le su modalità operative, dopo di che presenterò una implementazione del protocollo che prende il nome di OpenCAPWAP. Dopo di che presenterò come l’evoluzione del driver e come questo viene sfruttato per il sviluppo della soluzione SplitMAC, poi presenterò il software hostapd. Di seguito presento il disegno completo della soluzione di SplitMAC al interno del progetto OpenCAPWAP. In fine riporto dei test eseguiti in ambiente di collaudo e i sviluppi futuri. Sotiraq Sima Pag.1/15

Il protocollo CAPWAP Compiti del amministratore della rete Attività Manuale Administrator Protocollo Propriettario Administrator Attività Manuale Compiti del amministratore della rete Quando la rete Wireless LAN viene composta da soltanto un Access Point, questo viene chiamata anche Stand Alone Access Point. Il compito del amministratore di rete di configurare e mantenere l’aggiornamento di un Access Point, assegnare il canale radio, preoccuparsi della sicurezza, e eventualmente anche della Qualità del Servizio. Questo diventa un problema sui infrastrutture wireless di grandi dimensioni, per esempio biblioteche aeroporti, centri commerciali etc… dove il numero di AP cresce radicalmente, Per superare questo problema alcuni produttori hanno sviluppato protocolli proprietari per la gestione centralizzata dei AP, lasciando al amministratore della rete soltanto la configurazione del server. Il problema di queste soluzione e’ che il protocolli erano eterogenei tra i diversi produttori. La soluzione a questo, ha proposto IETF nel 2009 standarizando il protocollo CAPWAP… Configurazione/Mantenimento dei AP Assegnazione dei canali Radio Sicurezza QoS Sotiraq Sima Pag.2/15

Control And Provisioning of Wireless Access Points Il protocollo CAPWAP Control And Provisioning of Wireless Access Points Control Channel Data Channel Data CAPWAP e l’acronimo di Controling And Provisioing of Wireless Access Point. Il scopo del protocollo e’ di gestire i Access Point in infrastrutture wireless di grandi dimensioni, offrendo a esso anche connettività in rete. Il protocollo definisce l’entitia’ Access Controller come coordinatore della rete, e I Access Point prendendo il nome di Wireless Termination Point, questo perche il loro compito e di trasmettere e ricevere i frame radio, lasciano il carico computazionale al Access Controller. Per la gestione dei WTP e’ stato definito un canale UDP dedicato. Per esempio per l’associazione del WTP al AC, la configurazione etc… Mentre per i dati che vengono inviati e ricevuti dai vari stazioni, viene utilizzato un canale UDP su una porta differente. La mia tesi gestisce principalmente il canale dati. Sotiraq Sima Pag.3/15

Modalità Operative per CAPWAP LocalMAC vs SplitMAC CTS, RTS, ACK Beacon, Probe Autenticazione Associazione Network Layer Internet Protocol Logical Link Control 802.2 Data Link Layer Medium Access Control 802.11 MAC 802.11Non Real Time LMAC: 802.3 Le modalità operative per CAPWAP sono due, LocalMAC e SplitMAC. Nella modalità LocalMAC I due primi livelli del modello OSI vengono gestiti al Access Point, per questo il protocollo definisce che I pacchetti di dati che devono viaggiare tramite AC e WTP devono avere la forma di frame EthernetII. Mentre nella modalità SplitMAC viene fatto un suddivisione ulteriore al sottolivello MAC, classificando ogni operazione come critico rispetto al tempo. Tutte le operazioni real time rimangono in gestione al WTP, mentre quelle meno critiche vengono demandate al Access Controller. Per questo motivo I frame di tipo data in questa modalità dovranno avere la forma 802.11 MAC 802.11Real Time Physical Layer 802.11a 802.11b 802.11g SMAC: 802.11 Sotiraq Sima Pag.4/15

Il Progetto OpenCAPWAP (1/3) Implementazione Open Source del protocollo CAPWAP Sviluppato da studenti dell'Università “La Sapienza” in collaborazione con I'IAC (CNR), l'Università Campus Biomedico di Roma e con il CASPUR Sviluppato interamente in C Implementa il binding per lo standard IEEE 802.11 Multi Thread (pthreads) 2 demoni (AC, WTP) Esecuzione in User Space La prima implementazione OpenSource del protocollo prende il nome di OpenCAPWAP, e stato sviluppato principalmente dei studenti di questa Universita, con la collaborazione dall‘Istituto per le Applicazioni del Calcolo del CNR, Con l’universtia Campus Biomedico di Roma e con il CASPUR. E una soluzione sviluppato principalmente in C, e implementa il binding per le reti wirelless 802.11. La sua architettura e basata nella modello di mutlit threading, la compilazione crea dur demoni, uno per Access Controller e uno per il Access Point, tutti I due demoni lavorano in UserSpace. Sotiraq Sima Pag.5/15

Il Progetto OpenCAPWAP (2/3) UDP { CAPWAP } WTP AC WTP AC User Space Kernel Space wlan0 L’immagine presenta, il progetto in alto livello, il demone WTP che e installato nel Access Point, inizialmente recupera e si collega con il demone presente in AC, dopo di che accetta e invia dei paramenti di configurazione, il demone WTP utilizzata ioctrl(); per la configurazione del driver che ha il compito di mantenere il stato della interfaccia radio. MADWiFi Sotiraq Sima Pag.6/15

Il Progetto OpenCAPWAP (3/3) LocalMAC in OpenCAPWAP WTP US KS wlan0 MADWiFi MADWiFi implementa a livello di driver (in Kernel) lo stack MAC 802.11 !!! Fino ad oggi e stato utilizzato principalmente il driver MADWiFi, un driver OpenSource che opera in Kernel Space, il suo compito e di gestire il livello MAC e di dialogare con I registri della interfaccia Radio. Dal User Space viene utilizzato l’API IOCTL(); che parlerà con il modulo Wirelees Extesnsion, e un estensione di kernel di linux per la gestione delle interfeccia di wireless. La ragione perche fino ad oggi non e’ stato sviluppata la modalità SplitMAC e perche il driver madwifi gestisce il stack 802.11 completamente al interno del driver che si trova in kernel space. Una soluzione possibile e di creare un progetto parallelo partendo da MADWiFi e modificarlo in modo che la gestione del AP viene eseguita in User Space, ma una soluzione non e ammessa sul contesto che e stato sviluppato OpenCAPWAP. Soluzione: Partendo dal driver MADWiFi, implementare un nuovo driver che dialoga con User Space per la gestione di un AP Sotiraq Sima Pag.7/15

Mac80211 e Hostapd (1/2) ioctl(); netlink User Space Application Kernel Space Wireless Extensions WEXT e MADWiFi non vengono più sviluppate, loro posto prende un nuovo modello. Partendo dal codice di MADWiFi, viene sviluppato il modulo mac80211 che il suo compito e di gestire il livello MAC, e il ruolo di WEXT viene messo il modulo cfg80211, lasciando il minimo indispensabile al driver (per esempio ath5k), questo modello viene chiamato anche SoftMAC. La comunicazione con il User Space aviene tramite il socket NETLINK. cfg80211 MADWiFi mac80211 ath5k Sotiraq Sima Pag.8/15

Mac80211 e Hostapd (2/2) hostapd Wrapper (NL80211) cfg80211 mac80211 Data: Kernel Space Control: Kernel Space Management: User Space (Beacon in Kernel Space) hostapd Wrapper (NL80211) User Space Kernel Space mon.wlan0 wlan0 I frame 802.11 che vengono ricevuti o inviati dalla interfaccia radio, hanno tre diversi tipi. Dati, Controllo, Gestionale. I frame di tipo dati sono I frame che contengono I dati veri e propri di livello superiore. I frame di controllo sono necessari per il controllo del canale (RTS,CTS,ACK,…). Mentre I frame di tipo gestionale sono necessari per la l’associazione autenticazione e la riassociazione. Il modulo mac80211, quanto l’interfaccia Wireless si impostata in modalità Access Point (Master). Tutti I frame ricevuti di tipo data vengono inviati verso la interfaccia wlan0, mentre I frame di modalità controllo vengono gestiti al livello kernel, mentre per I frame gestionali, alcuni li gestisce in livello Kernel (beacon) e altri li demanda a una applicazione di livello User Space per l’elaborazione.mac80211 per questo crea una interfaccia in modalità “cooked monitor” che il livello User Space o il livello Kernel Space può leggere e scrivere I frame gestionali. Il demone hostapd che opera in livello User Space , e un software che gestisce un Access Point come e’ definito nello standard IEEE802.11. Il demone questo utilizza un strato di software chiamato “wrapper” che e intermedio tra il core hostapd e il dialogo netlink, e per il recupero e la scrittura dei frame gestionali. Il comportamento di mac80211 e il software hostapd, sono stati I punti chiave dello sviluppo della soluzione SplitMAC. Detto questo presentero il disegno di SplitMAC cfg80211 mac80211 ath5k Sotiraq Sima Pag.9/15

Disegno della modalità SplitMAC (1/2) WTP AC UDP {CAPWAP-Control} hostapd UDP {CAPWAP-Data } hostapd demone WTP demone AC thread thread thread thread Real time Non Real time (+) SCTP UDP PIPE mgmt. Frame (+) .3  .11 .3  .11 RAW Wrapper WTP Data Frame Wrapper AC Data Frame mgmt. Frame Lato demone WTP, e stato sviluppato un nuovo wrapper, che collega il demone hostapd e il layer mac80211. Questo wrapper per ogni frame di tipo real time ricevuto nella interfaccia monitor (probe Request) lo invia verso il demone hostapd local. Mentre per tutti i altri frame ricevuti, vengono propagati verso il demone WTP, che a sua volta propaga attraverso il canale dati di CAPWAP verso il demone AC, dove viene controllato il tipo di frame e viene inviato verso un nuovo wrapper per AC, il wrapper questo consegna il frame gestionale al core hostapd, come se fosse ricevuti da un interfaccia wireless locale. I frame provenienti dal hostapdAC seguino la stessa strada in contrario fino al invio dalla interfaccia radio. Tra i nuovi wrapper e il demoni WTP/AC viaggia anche messaggi di configurazione, per esempio ADD_WLAN, ADD_STATION etc.. Questo messaggi viaggiano nel canale di controllo di CAPWAP. Mentre per I frame dati, lato WTP viene creato un thread dedicato al demone WTP che tramite socket RAW recupera i frame in formato EthernetII trasforma il frame in formato 802.11 (come richiesto da SplitMAC) E viene propagato verso il demone AC, il quale ha creato con l’aiuto del driver tun/tap un interfaccia virtuale che rispecchia la interfaccia fisica presente in AP. Cosi facendo viene creato un bridge tra interfaccia virtuale e interfaccia fisica in WTP. Stream Control Trasmission Protoccol bridge User Space Kernel Space mon.wlan0 cfg80211 mac80211 wlan0 tap0 tun/tap ath5k Sotiraq Sima Pag.10/15

Disegno della modalità SplitMAC (2/2) hostapd hostapd hostapd demone AC L’Access Controller gestisce tanti demoni quanti sono I Access Point serviti al momento. Sotiraq Sima Pag.11/15

Risultati dei Test (1/2) WTP AC Sistema Embedded Alix3d1 (x86) CPU Single Core (433MHz), 128MB Ram OpenWrt (Backfire v10.03) Atheros AR52111G AC Sono stati eseguiti I test in ambiente di collaudo, dove sono stati utilizzati dei sistemi Embedded da PC Engines, dove installato una versione minima di Linux per sistemi embedded. E come Access Controller viene utilizzato un PC di medie caratteristiche Notebook PC (x86) CPU Dual Core (2.1GHz), 2GB Ram Debian (Kernel v3.0) Sotiraq Sima Pag.12/15

Risultati di Test (2/2) Data Ack WTP AC wlan0 eth0 eth0 tap0 II I 5% 100Mbps AC wlan0 eth0 eth0 tap0 II 5% I 95% Per misurare la latenza e il Throughput sono eseguiti dei test, I quali sono eseguiti inviando dalla una stazione dei datti verso l’access controller. e ti seguito misurando il tempo del arrivo del acknowlege. Il primo test consiste di inviare un byte, al interno di un pacchetto TCP, I test vengono eseguiti per 6 volte, per un totale di 3000 pacchetti TCP, il Round Trip Time medio calcolato e di 3.5 ms. Mentre per misurare il throughput viene eseguito lo stesso test inviando messaggi TCP di 1448 byte, dalla stazione verso l’access controller, il throughput misurato e quasi di 0.9MBps, Sniffando il traffico di in tre punti sostanziali della rete viene verificato che il 5% del tempo per l’invio del pacchetto viene impegnato tra Stazione e Access Point, e il 95 restante viene del tempo viene consumato tra il bridge di Access Point e il Access Controller, per questo fatto …. RTT TCP (1Byte) Tot. Test RTT min (ms) RTT avg (ms) Pacchetti TCP  6 2.8 (avg) 3.5 (avg)  ~3K Throughput TCP (1448Byte) Tot. Test RTT avg (ms) Throughput (KBps) Pacchetti TCP  3 81.0 (avg) 900.892  ~4K Sotiraq Sima Pag.13/15

Sviluppi futuri Analisi del codice di OpenCAPWAP con l’ottica di migliorare il tempo richiesto ad un pacchetto per essere propagato dalla interfaccia fisica presente nel WTP fino alla interfaccia virtuale presente nell’AC. Sui sviluppo futuri dovrà essere fatto una analessi del codice accurato per minimizzare il RTT e massimizzare il throughput. Attualmente il modulo SplitMAC è in fase di rilascio nel progetto OpenCAPWAP OpenCAPWAP Project: https://opencapwap.atlassian.net/ Sotiraq Sima Pag.14/15

Grazie per l’attenzione The end... Grazie per l’attenzione Domande ?  Sotiraq Sima Pag.15/15