Wifi TP2 BONY Simon 23 mars 2012 1
Table des matières Introduction... 3 I. Etude sans CSMA/CA... 4 I.1 Préparation... 4 I.2 Etude du trafic... 6 I.3 Etude du trafic avec les tables ARP vides... 7 I.4 Etude du débit... 8 II. Etude avec CSMA/CA... 9 II.1 RTS/CTS... 9 II.2 Etude du débit... 12 III. Le débit et la retransmission... 13 Conclusion... 14 2
Introduction BONY Simon L objectif de ce TP est d étudier le système CSMA/CA permettant d éviter un maximum de collisions. Nous commencerons par configurer notre système avant d étudier le débit sans CSMA/CA puis avec CSMA/CA. Nous pourrons alors comparer les deux résultats pour mieux apprécier ce système. 3
I. Etude sans CSMA/CA BONY Simon Cette première partie va nous permettre d en apprendre plus sur l échange de trame entre deux machines et d étudier les performances du système sans activer CSMA/CA I.1 Préparation Nous souhaitons étudier les échanges entre deux machines. Nous commençons donc par installer les cartes sur les deux. Pour cela nous utilisons la commande modprobe rt61pci (nos cartes sont des RaLink 2561). Cette commande va créer une interface sans fils wlan0 que nous souhaitons espionner. Pour cela nous rajoutons sur la première machine une interface virtuelle sniffant le trafic sur wlan0 à l aide de la commande airmon-ng start wlan0 Fig 1 : Résultat de la commande airmon-ng start wlan0 Nous apprenons alors qu il existe une interface mon0 monitorant wlan0 A l aide de la commande ifconfig mon0, nous pouvons effectivement la remarquer. Fig 2 : Résultat de la commande ifconfig mon0 Nous pouvons alors lancer une capture Wireshark sur cette interface pour étudier les paquets sniffés par ce moniteur. Nous étudierons ces captures par la suite. 4
Nous configurons alors cette machine en mode Ad-Hoc Fig 3 : Configuration de la machine en mode Ad-Hoc Nous étudions alors les trames Beacon Frame envoyés par cette station Fig 4 : Extrait d une capture Wireshark Les Beacon frame sont envoyés par une station émettrice afin d annoncer sa présence sur le réseau. C est la raison pour laquelle ces trames sont envoyées en broadcast et que nous capturons aussi celles des stations environnantes. Fig 5 : Contenu d une trame Beacon frame 5
Le premier champ contient des informations sur la trame elle-même : Le type de trame : Indique le type de la trame (Beacon frame) Frame Control : contient diverses informations sur le traitement de la trame Les adresses : sources, destinations, Le contrôle de séquence : en cas de fragmentation qui n a pas lieu ici. Le second champ contient des informations sur la station qui se déclare : Des paramètres fixes renseignant sur l émission de cette trame Des paramètres propres à la station o Le SSID o Les débits supportés o Le channel actuel o L ATIM Window Nous plaçons alors une seconde machine en mode Ad-Hoc de la même manière que la précédente pour continuer notre étude. I.2 Etude du trafic Nous lançons un ping d un paquet de la machine 192.168.4.11 vers la machine 192.168.4.10 à l aide de la commande ping c 1 192.168.4.10 Fig 6 : Extrait d une capture Wireshark Etudions ces trames au niveau LLC. Nous pouvons y trouver les informations suivantes : DSAP (Destination Service Access Point) : désigne le protocole destinataire des données. Ici c est le protocole SNAP SSAP (Source Service Access Point) : désigne le protocole émetteur des données. Ici c est le protocole SNAP IG Bit : renseigne sur le type d adresse : individuelle ou de groupe. Ici, c est individuel. CR Bit : renseigne le type de LLC : contrôle avec/sans connexion avec/sans acquittement. 6
Nous remarquons donc que la machine émettrice émet une requête ping que le destinataire n acquitte pas : elle se contente de renvoyer la réponse. La machine émettrice envoi quant à elle un acquittement de la réponse. Nous étudions alors la couche physique de ces trames : Nous souhaitons connaitre le Débit. Pour cela, nous consultons le champ Data Rate qui nous indique que le débit est de 6.0 Mb/s pour ce paquet. En consultant le flag Retry, nous constatons que celui-ci est à 0. Cela signifie que si le paquet est perdu, il ne sera pas retransmit. Nous constatons aussi que la trame n à pas été fragmenter au niveau de la couche 2 : le flag Fragmentation est à 0. Nous remarquons au passage que le champ Duration à pour valeur 0 ce qui signifie que pour transmettre cette trame, le canal de transmission n a pas été réservé par la station. I.3 Etude du trafic avec les tables ARP vides Nous souhaitons maintenant étudier le trafic en l absence de contenu dans les tables ARP. Pour cela nous vidons les tables à l aide du script suivant : #!/bin/bash for i in `arp -n grep ^[0-9] awk '{print $1}'`; do arp -d $i; done; Fig 7 : Script de vidage des tables ARP Nous confirmons l absence de données dans les tables avec la commande arp a puis nous lançons à nouveau un ping. Fig 8 : Extrait d une capture Wireshark Nous remarquons alors que les deux machines commencent par remplir leurs tables ARP avant de s envoyer le ping. 7
I.4 Etude du débit Nous allons maintenant étudier le débit pratique du réseau en fonction d un débit de carte fixé. Notons que le débit théorique est le débit que devrait avoir l échange tandis que le débit pratique est le débit constaté sur le réseau. Nous allons donc remplir le tableau de la figure 9 (chaque séquence dure 30 secondes). Pour cela, nous allons utiliser les trois programmes mgen, trpr et gnuplot. Pour plus de détail, consulté le rapport du TP1. Paquet/s Taille paquet Débit théorique (Kbits/s) Débit avec Bit rate = 54 Mb/s Débit avec Bit rate = 1 Mb/s 50 128 51,2 (Kbits/s) 31 (Kbits/s) 45 100 128 102,4 86 72 1000 128 1024 19 68 50 1024 409,6 325 145 100 1024 819,2 776 217 1000 1024 8192 636 396 50 8192 3276,8 1174 357 100 8192 6553,6 26 397 1000 8192 65536 26 425 Fig 9 : Tableau des débits relevés Les faibles valeurs pour le 54 Mbits/s pour les deux derniers types de paquets peuvent être expliquées à la fois par une mauvaise connexion et par une surcharge du buffer qui réduit considérablement le nombre de paquets émis. Cependant, outre ces pertes de réseaux ponctuelles, nous remarquons que le débit pratique est sensiblement plus élevé avec 54 Mbits/s, le débit augmentant avec la taille des paquets et par leur nombre d envoi à la seconde. 8
II. Etude avec CSMA/CA Nous allons maintenant activer le RTS/CTS afin d éviter les collisions sur le réseau II.1 RTS/CTS La technique RTS/CTS permet à une station de réserver le support pendant un labs de temps afin d émettre ses trames sans collisions. Par défaut, celle-ci n est pas activée sur les cartes. Effectivement, afin que les trames RTS et CTS atteignent le maximum de stations, celles-ci sont envoyées à 2Mbits/s maximum. Ce temps de transmission couplé à la réservation du support fait baisser le débit utile, notamment sur des réseaux encombrés. Nous activons donc le RTS/CTS en fixant le seuil à 800 octets avec la commande iwconfig wlan0 rts 800 Fig 10 : Activation du RTS 9
Nous pouvons alors distinguer 2 cas lors d un ping: Transmission d un paquet inférieur à 800 octets : Dans ce cas là, la station émet un RTS pour réserver le support puis reçoit un CTS pour lui confirmer la réservation. Il émet alors son paquet normalement. Fig 11 : Extrait d une capture Wireshark Transmission d un paquet supérieur à 800 octets : Cette fois ci, le paquet est fragmenté. Un acquittement est envoyé pour chaque trame mais un seul RTS/CTS est émit Nous remarquons au passage que le champ Duration possède une valeur prouvant que le canal est réservé. Nous étudions maintenant la trame RTS et CTS, et plus précisément 4 de leurs champs : rate, Transmitter adress (MAC source), Receiver adress (MAC destination) et Duration. Nous commençons avec la trame RTS. Fig 12 : Trame RTS 10
La trame a été envoyée à un débit faible (1,0 Mbits/s) de l adresse MAC 00:0e:2e:a8:5e:08 vers l adresse MAC 00:0e:2e:a8:5d:fa avec le champ Duration à 990 indiquant que le support est réservé durant ce labs de temps. Nous continuons avec la trame CTS. Fig 13 : Trame RTS La trame a été envoyée au même débit (1,0 Mbits/s) vers l adresse MAC 00:0e:2e:a8:5e:08 avec le champ Duration à 676 indiquant le temps restant avant libération du support. Cependant, le champ Transmitter adress n est pas renseigné. Mais il est intéressant de noter que le destinataire du CTS est l émetteur du RTS. On remarque que dans les deux trames, le débit est très faible. Ce faible débit permet à la trame d être moins sensible aux bruits et de parcourir une plus grande distance afin d atteindre le maximum de stations et plus de stations sont atteintes, plus le support est de qualité. 11
II.2 Etude du débit Nous allons maintenant étudier la qualité du réseau de la même manière qu en I.4. Paquet/s Taille paquet Débit théorique (Kbits/s) Débit sans RTS/CTS Débit avec RTS/CTS = 800 50 128 51,2 45 48 100 128 102,4 72 76 1000 128 1024 68 40 50 1024 409,6 145 336 100 1024 819,2 217 488 1000 1024 8192 396 202 50 8192 3276,8 357 393 100 8192 6553,6 397 262 1000 8192 65536 425 197 Fig 14 : Tableau des débits relevés Nous remarquons alors que le débit avec RTS/CTS est beaucoup plus important que sans RTS/CTS à l exception des paquets de 8192 octets qui sont beaucoup trop fragmentés ce qui réduit le débit utile et lorsque nous envoyons 1000 paquets à la secondes ce qui représente un trop grand nombre de trame RTS/CTS à émettre. Pour finir avec cette technique, nous précisons qu en cas de fragmentation, un RTS/CTS est émis en début d échange mais pas pour chaque fragment. Effectivement, le RTS réserve le support pour le temps nécessaire à la transmission de tous les fragments. Fig 15 : Echange de trames 12
III. Le débit et la retransmission Nous finissons ce compte-rendu avec une petite partie traitant de la transmission du débit et de la retransmission. Tout d abord, nous souhaitons savoir si le débit est bel et bien transmit via le champ rate. Pour cela, nous lançons un ping avec un débit de 1Mbits/s puis nous changeons le débit à 36 Mbits/s en pleine émission avec la commande iwconfig wlan0 rate 36M A l aide de Wireshark, nous étudions les changements effectués. Nous remarquons alors que le champ rate passe bien de 1Mbits/s à 36 Mbits/s Etudions maintenant la retransmission. Lorsqu un paquet est perdu, celui-ci est retransmit. Cependant, si après N retransmissions le paquet est toujours perdu, la station arrête d émettre ce paquet. Par défaut, notre carte effectue 7 retransmissions maximum. Nous pouvons le vérifier avec la commande iwconfig wlan0 : il est indiqué dans le champ Retry long limit. Si cependant nous souhaitons le changer, il nous suffi d utiliser la commande iwconfig wlan0 retry X (avec X la valeur à affecter). Fig 16 : Modification de la retransmission 13
Conclusion Après avoir appris à mettre un œuvre une interface virtuelle en mode monitor, nous avons pu étudier le système d échange de trame avec et sans RTS/CTS. Nous avons aussi pu comparer les débits sur le support dans les deux cas. Ce TP nous a donc a donc fournit une meilleure compréhension de la communication entre stations dans un réseau Ad-Hoc. 14