Differences
This shows you the differences between two versions of the page.
|
isrm:laboratoare:11 [2014/10/29 20:14] dragos.niculescu |
isrm:laboratoare:11 [2019/05/17 16:25] (current) mbarbulescu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ==== Laboratorul 11 ==== | ==== Laboratorul 11 ==== | ||
| - | === Rate multiple (MCS) === | ||
| + | Acest laborator este o introducere în crearea unui setup practic AP (access point) - STA (stație) folosind calculatoarele din PR706. Acestea au montate pe PCI placa Wifi Intel AC7260 care suportă dual band 2.4GHz/5GHz și 802.11a/b/g/n/ac (Legacy/HT/VHT). Calculatoarele fiind dotate cu Linux ne vom folosi de utilitarele userspace pentru a ne crea infrastructura. | ||
| - | Se dă scriptul {{isrm:laboratoare:src:multirate.tcl}} care definește | + | În acest laborator vom lucra în echipe de minim 2 studenți, maxim 3. |
| - | nodurile WiFi 0,1,2,3,4 astfel: | + | |
| - | <code> | + | |
| - | 3 | + | |
| - | 4 0 2 | + | |
| - | + | === Pregătirea access pointului (AP) === | |
| - | 1 | + | |
| + | Pentru a putea porni cu succes daemon-ul de AP trebuie rulate următoarele comenzi (ca ''root''). Puteți rula un ''sudo su'' înainte. | ||
| + | |||
| + | <code bash> | ||
| + | root@pr706-pc:~# nmcli radio wifi off | ||
| + | root@pr706-pc:~# rfkill unblock wifi | ||
| + | root@pr706-pc:~# rfkill unblock all | ||
| + | root@pr706-pc:~# killall wpa_supplicant | ||
| </code> | </code> | ||
| - | Nodul 0 funcționează ca AP și emite la 11Mbps, iar celelalte noduri sunt clienți, cu legături uplink de 1Mbps. Sunt definite patru fluxuri UDP 1->3, 2->4, 4->0, 0->4, toate cu pachete de 1460 de octeți. | ||
| - | Distanțele de la clienți la AP sunt de 20m, RTS este dezactivat, RxThresh=250m, iar acești parametri nu vor fi modificați. | ||
| - | Scriptul **necesită** următorii | ||
| - | parametri pe linia de comandă: | ||
| - | * rate0 <rate> indică rata oferită pentru fluxul 1->3 | ||
| - | * rate1 <rate> indică rata oferită pentru fluxul 2->4 | ||
| - | * rate2 <rate> indică rata oferită pentru fluxul 4->0 | ||
| - | * rate3 <rate> indică rata oferită pentru fluxul 0->4 | ||
| - | La sfârșitul simulării de 100 secunde se afișează throughputul în bps | + | S-ar putea ca ''NetworkManager'' din Ubuntu încă se ne încurce așa că recomandăm oprirea lui. Dacă pierdeți accesul la internet rulați dhclient pe ''eno1'': |
| - | pentru fiecare flux, și numărul total de pachete transferat pe durata | + | |
| - | întregii simulări. Scriptul cere ca parametrii rate să fie diferiți de | + | <code bash> |
| - | zero, dar pentru a dezactiva un flux, trebuie furnizată o rată | + | root@pr706-pc:~# systemctl stop NetworkManager |
| - | neglijabilă, de exemplu 0.01bps. Unitatea de măsură nu se separă cu | + | root@pr706-pc:~# dhclient eno1 #doar daca nu mai avem conectivitate la Internet |
| - | spațiu: 11Mbps, 360Kbps, etc. | + | </code> |
| + | |||
| + | Acum trebuie să pornim daemonul ''hostapd'' pentru a activa AP-ul nostru. E nevoie de doi pași simpli: | ||
| + | - Copiați fișierul [[https://github.com/isrm-lab/isrm-lab-sol/blob/master/lab-11/hostapd.conf|hostapd.conf de aici]], salvați-l în ''/etc/hostapd/hostapd.conf'' | ||
| + | - Rulați comanda de mai jos, output-ul trebuie să vă spună ''AP-ENABLED'': | ||
| + | |||
| + | <code bash> | ||
| + | root@pr706-pc:~# hostapd /etc/hostapd/hostapd.conf | ||
| + | Configuration file: /etc/hostapd/hostapd.conf | ||
| + | Using interface wlp2s0 with hwaddr ac:fd:ce:22:77:9d and ssid "ISRMLABORATOR" | ||
| + | wlp2s0: interface state UNINITIALIZED->ENABLED | ||
| + | wlp2s0: AP-ENABLED | ||
| + | </code> | ||
| + | |||
| + | <note warning> | ||
| + | Recomandăm tuturor echipelor de studenți să schimbe ''ssid=ISRMLABORATOR'' din ''hostapd.conf'' pentru a evita conectarea accidentală la AP-ul altora. Puneți orice SSID doriți. | ||
| + | </note> | ||
| + | |||
| + | == Modul monitor == | ||
| + | |||
| + | <note warning>Pe Intel AC7260 care sunt in laborator merge modul monitor doar pe AP. Recomandarea însă pentru a prinde toate pachetele din aer e să fie făcut pe un calculator separat</note> | ||
| + | |||
| + | <code bash> | ||
| + | root@pr706-pc:~# iw phy phy0 interface add mon0 type monitor flags control otherbss | ||
| + | root@pr706-pc:~# ifconfig mon0 up | ||
| + | root@pr706-pc:~# tcpdump -s0 -ni mon0 | ||
| + | </code> | ||
| + | - ''-s0'' capturează toată lungimea pachetelor | ||
| + | - ''-n'' nu rezolvă DNS | ||
| + | - ''-i'' indică interfața | ||
| + | |||
| + | <code bash> | ||
| + | root@pr706-pc:~# tcpdump -s0 -ni mon0 -w ./m.pcap | ||
| + | root@pr706-pc:~# wireshark ./m.pcap | ||
| + | </code> | ||
| + | |||
| + | Examinați pachetele capturate și recunoașteți pachetele/protocoalele/câmpurile discutate la curs și în articole. | ||
| + | |||
| + | <note tip> | ||
| + | Comenzile de Linux pentru modul monitor le aveți și la [[https://sandilands.info/sgordon/capturing-wifi-in-monitor-mode-with-iw | ||
| + | |acest link]] | ||
| + | </note> | ||
| + | |||
| + | |||
| + | === Pregătirea stației (STA) === | ||
| + | |||
| + | Și aici trebuie oprite ''NetworkManager'' și ''wpa_supplicant''. Vom folosi întâi utilitarul ''iw'' apoi ''wpa_supplicant'' cu propriul fișier de configurare pentru a ne conecta la AP: | ||
| + | |||
| + | <code bash> | ||
| + | root@pr706-pc:~# systemctl stop NetworkManager | ||
| + | root@pr706-pc:~# killall wpa_supplicant | ||
| + | </code> | ||
| + | |||
| + | Pentru a face o scanare activă (asigurați-vă că folosiți modul monitor și capturați pachetul - ce tip de pachet va trimite stația?) rulați comanda: | ||
| + | |||
| + | <code bash> | ||
| + | root@pr706-pc:~# iw dev wlp2s0 scan | grep -i <yourSSID> -A 50 -B 20 | ||
| + | </code> | ||
| + | |||
| + | Pentru a vă asocia la AP-ul pornit anterior folosiți: | ||
| + | |||
| + | <code bash> | ||
| + | root@pr706-pc:~# iw dev wlp2s0 connect <yourSSID> | ||
| + | root@pr706-pc:~# iwconfig #to check/validate association | ||
| + | </code> | ||
| + | |||
| + | === Exerciții extra === | ||
| + | - Rulați o sesiune ''iperf'' TCP între cele două stații pentru a determina bandwidth-ul maxim la care TCP se simte bine. Serverul este receptor de date, Clientul e transmițător. Rulați server pe AP și client pe STA. Ce valoare are aceasta? Suntem în ''802.11b'', care e throughput maxim la acesta și la ce MCS (data rate)? | ||
| + | <code bash> | ||
| + | root@pr706-pc:~# iperf -s -i1 | ||
| + | root@pr706-pc:~# iperf -c <ip_AP> | ||
| + | </code> | ||
| + | - Rulați o sesiune ''iperf'' UDP între cele două stații cu cel mai mare packet length (1472 Bytes). Serverul este receptor de date, Clientul e transmițător. Rulați server pe AP și client pe STA. e valoare are aceasta? Suntem în ''802.11b'', care e throughput maxim la acesta și la ce MCS (data rate)? | ||
| + | <code bash> | ||
| + | root@pr706-pc:~# iperf -s -i1 -u | ||
| + | root@pr706-pc:~# iperf -c <ip_AP> -b54M -u -i1 -l1472 | ||
| + | </code> | ||
| + | - Pentru exercițiile anterioare urmăriți în PCAP câmpul ''Data rate'' din 802.11 radio tap header. Ce observați? Ce se întâmplă cu acesta dacă vom mișca antena? | ||
| + | <note tip> | ||
| + | Dacă nu mișcăm antenele observăm creșterea monotonă data rate (a MCS-ului) grație algoritmului de rate adaption. Intel folosește [[https://github.com/torvalds/linux/blob/master/drivers/net/wireless/intel/iwlwifi/dvm/rs.c|iwl-agn-rs]]. În Linux upstream se folosește algoritmul [[https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/ratecontrol/minstrel|Minstrel]] pentru vendorii care nu au dezvoltat propriul algoritm în driver/firmware. | ||
| + | |||
| + | Dacă mișcăm antenele pe lângă evoluție ne-monotonă a data rate throughputul iperf e afectat. | ||
| + | </note> | ||
| + | - Pe AP configurați ''802.11n'' (ca extra feature). Re-rulați iperf și urmăriți PCAP-urile. Ce apare în plus la MCS? Dar la frame format: apare formatul HT. Mai jos aveți ce trebuie pus în ''hostapd.conf'': | ||
| + | <code bash> | ||
| + | # 802.11n | ||
| + | wmm_enabled=1 | ||
| + | ieee80211n=1 | ||
| + | ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40][DSSS_CCK-40][DSSS_CCK-40] | ||
| + | </code> | ||
| + | |||
| + | |||
| + | <hidden> | ||
| + | === Multihop, autointerferență === | ||
| + | |||
| + | Se folosește un singur canal pentru toate hopurile din rețea. O topologie simplă este string: un șir de noduri care poate transporta trafic de la un capăt la altul. În general o rețea adhoc poate avea forma unui graf, dar două noduri care comunică vor folosi un șir de alte noduri pentru a transporta traficul. O particularitate a acestei topologii este aceea că pachetele aceluiași flux concurează pentru accesul la mediu. De fapt, un șir este o colecție de terminale expuse și ascunse. | ||
| - | - Să se calculeze capacitatea maximă a aerului în pps si bps pentru fiecare emițător luat în izolare. Cât durează transmiterea unui cadru de la stații? Dar de la AP? | + | === Experiment 1 === |
| - | - Dacă doar fluxul 0 (1->3) este activ, ce throughput se obține end to end? | + | Se dă topologia A - B - C, nodurile fiind plasate la interval de 20m. CSThresh=550m, RXThresh=250m. Scriptul {{isrm:laboratoare:src:string_bidir.tcl}} primește parametrii -sendingRate0 [R0] -sendingRate1 [R1] care descriu ratele în bps oferite fluxurilor UDP0 A->B->C și UDP1 C->B->A (-sendingRate0 nu poate fi 0, dar se pot folosi valori foarte mici 0.01Kbps). Scriptul afișează debitul obținut, și produce fișierul trace ".tr" în formatul cunoscut. |
| - | - Care este rata coliziunilor (cps)? Cât durează o coliziune? | + | |
| - | - Cum se justifică valoarea obținută? Care este compoziția cadrelor din aer? | + | |
| - | - Dacă doar fluxurile 0 (1->3) și 1 (2->4) sunt active, ce throughput se obține end to end? | + | |
| - | - Cum se justifică valoarea obținută? | + | |
| - | - Cum puteți obține o valoare mai mare? | + | |
| + | - să se determine capacitatea mediului în bps, și în pps. | ||
| + | - atunci când fluxurile au cereri egale, să se examineze performanța obținută de fiecare flux în funcție de debitul oferit. Care sunt regiunile importante ale graficului? | ||
| + | - Cum se justifică logic/numeric valoarea maximă și valoarea de saturație? | ||
| + | - Ce se schimbă la 2. și 3. când avem o topologie de 4 noduri spațiate la 20m: A - B - C - D? -sendingRate0 se transmite de la A, iar -sendingRate1 se transmite de la D, -nn 4 rulează cu 4 noduri. | ||
| + | - Ce valoare obține TCP în cele două situații? | ||
| + | * de ce este mai mică decât ..., și mai mare decât...? | ||
| - | === Rezolvare === | + | === Experiment 2 === |
| - | - Se dezactivează toate fluxurile în afară de unul pentru a studia un transmițător în izolare: <code> | + | Folosindu-se același script, se evaluează capacitatea pentru un șir de 20 noduri spațiate fie la 20m, fie la 200m (variabila hopDistance în script). |
| - | ns ./multirate.tcl -rate0 0.01bps -rate1 0.01bps -rate2 0.01bps -rate3 11Mbps </code> Se obțin 511pps, sau 5.97Mbps pentru AP. Un cadru durează \( \frac{1000}{511} = 1.95ms \) <code> | + | |
| - | ns ./multirate.tcl -rate0 0.01bps -rate1 0.01bps -rate2 11Mbps -rate3 0.01bps </code> Se obțin 77pps, sau 902Kbps pentru statii. Un cadru durează \( \frac{1000}{77} = 12.98ms \) | + | |
| - | - Se activează doar fluxul 0 (1->3): <code> | + | |
| - | ns ./multirate.tcl -rate0 902Kbps -rate1 0.01bps -rate2 0.1bps -rate3 0.1bps </code> Se obțin 755Kbps, sau 64pps. În aer se află cadre scurte, la 11Mbps, și cadre lungi, emise la 1Mbps, cel puțin câte 64 din fiecare, deoarece 64pps sunt livrate la destinație. Este posibil să mai fie și cadre în coliziune. | + | |
| - | - <code> cat ./multirate.tr | grep cbr | grep COL | wc -l </code> Rezultă 4cps coliziuni pe secundă. Deoarece toate dispozitive sunt în CS, nu avem terminale ascunse, și coliziunile sunt datorate ferestrei de contenție. Avem 2 transmițători: AP și stația 1, ce emit cadre de lungimi diferite. O coliziune durează până la sfârșitul cadrului cel mai lung (802.11 nu are CSMA/CD), adică 12.98ms. 4*12.98ms = 52ms = 5.2% din timp. | + | |
| - | - Trebuie să aflăm câte cadre din fiecare tip se află în aer într-o secundă. Fiecare emițător câștigă mediul în mod egal pe termen lung, x cadre pe secundă, dar fiecare îl ține ocupat în funcție de MCS folosit: (1Mbps, 11Mbps) \( R_1 = 77pps, R_2 = 511pps\). În plus mai avem și C coliziuni pe secundă. $$ \frac{x}{R_1} + \frac{x}{R_2} + \frac{C}{R_1} = 1 $$ $$ x = (1-\frac{C}{R_1})\frac{R_1R_2}{R_1+R_2} = 63pps$$ adică 63*1480*8 = 751Kbps, consistent cu ce am obținut în simulare.<code> | + | |
| - | * Stația 1 ocupă 64*12.98 = 823ms = 82% din timp. | + | |
| - | * AP ocupă 64*1.95=123ms = 12% din timp | + | |
| - | * coliziuni, restul de 5% din timp </code> Coada de pachete este probabil mereu goală în AP, și în creștere la stație, deoarece se generează mai mult decât se poate emite.<> | + | |
| - | - Activăm fluxurile 0 și 1, oferind maximul precedent: <code> | + | |
| - | ns ./multirate.tcl -rate0 755Kbps -rate1 755Kbps -rate2 0.1bps -rate3 0.1bps | + | |
| - | cat ./multirate.tr | grep cbr | grep COL | wc -l | + | |
| - | </code> Se obțin câte 199Kbps pentru fiecare flux, adică 17pps. Coliziuni 8.2cps. | + | |
| - | - Dacă se transmite un maximum de la fiecare sursă (1 și 2), AP-ul va avea de retransmis pentru ambele, dar nu câștigă mediul decât în 1/3 din arbitrări, deși cadrele lui sunt mai scurte. $$ \frac{x}{R_1} + \frac{x}{R_1} + \frac{x}{R_2} + \frac{C}{R_1} = 1 $$ Ce este diferit față de cazul precedent este că toți cei trei emițători sunt saturați, AP-ul însă nu dirijează decât \( \frac{x}{2} \) pentru fiecare flux, iar restul este pierdut. $$ x = (1 - \frac{C}{R_1})\frac{R_1 R_2}{R_1+2 R_2} = 32pps$$ Dar debitul obținut pentru fiecare flux este doar \(x/2\) = 16pps, adică 190Kbps.<code> | + | |
| - | * Stația 1 ocupă 32*12.98ms = 42% din timp | + | |
| - | * Stația 2 ocupă 32*12.98ms = 42% din timp | + | |
| - | * AP ocupă 32*1.95ms = 6% din timp | + | |
| - | * Coliziuni 8.2*12.98ms = 10% din timp </code> Adică 42% din timp este irosit pentru a transmite prin aer cadre care vor fi aruncate la AP! | + | |
| - | - Ar trebui ca fiecare cadru emis de o sursă să fie dirijat de către AP, si nu aruncat, deci împărțirea prin contenție nu se dorește echitabilă, ci AP-ul ar trebui să obțină dublu față de fiecare stație. \(x\) este acum debitul per flux: $$ \frac{x}{R_1} + \frac{x}{R_1} + \frac{2x}{R_2} + \frac{C}{R_1} = 1 $$ Din păcte C și x sunt interdependente, și o proporție de coliziuni este inevitabilă chiar dacă AP-ul este nesaturat. Cu 0 coliziuni am obține $$ x = \frac{0.5 R_1 R_2}{R_1 + 2 R_2} = 18pps = 396Kbps $$ Dacă rulăm, obținem 214Kbps și 7.9cps, ceea ce este departe de formulă, dar totuși crește debitul și scad coliziunile, deci este clar că trebuie trimis mai puțin de la surse. Un alt indiciu este că nu se pot emite mai mult de 755Kbps pentru un flux, deci 755Kbps/2 = 377Kbps de la fiecare stație 0 și 1, deoarece mediul este comun. <code> ns ./multirate.tcl -rate0 377Kbps -rate1 377Kbps -rate2 0.1bps -rate3 0.1bps | + | |
| - | </code> Se obțin câte 337Kbps pentru fiecare flux, adică 29pps. Coliziuni C = 5.9cps. Folosind acest ultim C, obținem: $$ x = (1 - \frac{C}{R_1})\frac{0.5 R_1 R_2}{R_1+2 R_2} = 31pps = 365Kbps $$ Dacă oferim doar 365K, se obțin 362K, si doar 4cps (similar cu 2., 3.), probabil optimul pentru această configurație. | + | |
| + | * trasați un grafic care arată capacitatea unui șir de noduri în funcție de lungimea lui (1-19 hopuri) | ||
| + | * ce cantitate de trafic injectați în rețea pentru a obține graficul? | ||
| + | * repetați graficul pentru UDP bidirecțional. | ||
| + | * rulați manual pentru diverse valori de trafic injectat | ||
| + | * repetați graficul pentru TCP. Opțiunea -run_tcp 1 generează trafic TCP unidirecțional. | ||
| + | * Explicați asemănările și diferențele pentru cele 2 tipuri de transfer (UDP/TCP) | ||
| + | * repetați graficul pentru TCP bidirecțional. | ||
| + | * comparați | ||
| + | * TCP vs UDP | ||
| + | * 20m vs 200m | ||
| + | * unidirecțional vs. bidirecțional | ||
| + | | ||
| + | === Experiment 3 === | ||
| + | TCP, 10 noduri, distanța 20m: | ||
| + | * Cum se comportă fereastra de congestie TCP? (cwnd_ în fișierul trace), RTT(srtt_ și rttvar_) | ||
| + | * care este valoarea BDP (bandwidth-delay product) pentru legătura obținută? | ||
| + | * unde se aruncă pachete din cozile ruterelor și unde se pierd în coliziuni? | ||
| + | * Ce dimensiune are coada unei interfețe wireless? | ||
| + | * Se poate obține throughput mai bun mărind coada? | ||
| + | </hidden> | ||
