Surveillance de la sous-couche MAC

Tout d’abord, il faut rappeler que l’algorithme de prévention de perte de route présenté au cha- pitre 4 consiste à surveiller la puissance de signal reçue des nœuds voisins afin d’évaluer la durée de vie restante d’un lien afin de prendre une décision anticipée lors d’un changement de route. Ainsi, la seule information nécessaire au bon déroulement du projet consiste à obtenir des

relevés de puissance reçue de la part de l’interface réseau utilisée. En parallèle à ce mécanisme de surveillance, un filtre de Kalman pour chaque nœud voisin procède au calcul la durée de vie restante du lien.

Comme mentionné à la section précédente, ce mécanisme doit être intégré au protocole OLSR existant pour la plateforme WRT54GS. Dans les faits, le mécanisme de surveillance et de calcul est un processus à part entière qui communique l’état de chacun des liens au processus OLSR par le biais d’un tunnel1_{. Il est permis de se demander pourquoi le mécanisme n’est pas intégré}

directement dans le protocole de communication OLSR. Dans les faits, il s’agit d’une décision quelque peu arbitraire, mais qui tire son fondement des deux principaux arguments qui suivent. En premier lieu, ce choix s’adapte mieux à l’intégration qui a été faite de l’algorithme dans le protocole OLSR. Il a été vu au chapitre 6 que le mécanisme d’hystérésis du protocole a été exploité afin d’utiliser le mécanisme de prévention de perte de route afin de quantifier la qualité des routes. L’algorithme de choix de route d’OLSR est donc totalement inchangé, seule la source de son indicateur de qualité est modifié. Ainsi, puisqu’une implémentation existante du protocole est utilisée, le découplage du mécanisme préventif dans un processus séparé permet de déverminer le nouveau mécanisme séparément. De plus, cette séparation limite les modifications nécessaires au protocole OLSR à des corrections minimes, réduisant du même coup le risque d’y insérer des erreurs.

Deuxièmement, il existe une multitude de trames de signalisation décrites et utilisées par la norme IEEE 802.11. Ces trames, bien qu’utiles seulement à la sous-couche MAC, ne sont au- cunement connues de la couche réseau (IP) et donc du protocole OLSR. Par contre, lors de la réception d’une telle trame, la puissance de réception peut être lue par l’interface réseau et donc amener de l’information supplémentaire au filtre de Kalman. Or, plus d’information sur la puis- sance permet au filtre de converger plus rapidement et d’éliminer plus facilement le bruit. Même si ces trames sont utiles au mécanisme préventif, avoir à traiter une surchage de trames nuirait au fonctionnement propre du protocole OLSR et pourrait réduire les performances de la com- posante logicielle. Ainsi, l’encapsulation du mécanisme de prévention de perte de route dans un processus distinct permet de ne pas alourdir la tâche du protocole OLSR, tout en permettant la surveillance de trames qui n’ont aucun intérêt pour la couche réseau. Le mécanisme se trouve donc à faire le pont entre cette dernière et la sous-couche MAC.

L’application Kalsniff vient répondre à ce besoin. Le code source de l’application est détaillé à l’annexe D. Ce logiciel en charge de la surveillance de la puissance reçue a trois tâches princi- pales : lire la puissance reçue de chacun des nœuds voisins, effectuer l’évaluation de la qualité

1_{Un tunnel (ou « pipe » en anglais) est une méthode de communication inter-processus dans les systèmes}

du lien à l’aide du filtre de Kalman et finalement, transmettre le résultat de cette évaluation dans le tunnel vers le protocole de routage OLSR.

La première de ces tâches est exécutée grâce à l’utilisation de deux dispositifs existant sous le système d’exploitation OpenWRT. Premièrement, le système permet à l’administrateur du point d’accès de configurer l’interface réseau sans-fil en mode moniteur brut2[OpenWrt, 2010]. C’est d’ailleurs cette fonctionnalité qu’exploite l’utilitaire Kismet, un analyseur de paquets réseau dé- crit à la section 7.2.2. Ce mode d’utilisation crée, du point de vue du système d’exploitation, une interface réseau supplémentaire. Tout paquet transitant par l’interface sans-fil peut être accédé par cette interface et assorti d’une entête comprenant des informations supplémentaires dont la puissance du signal reçu, le bruit de fond du canal, la longueur de trame, etc.

Le second dispositif est une librairie nommée libpcap. Il s’agit d’une librairie dédiée à la capture de paquets sur les interfaces réseau de bas niveau [The libpcap project, 2010]. Cette librairie est disponible pour de multiples systèmes, dont linux et plus particulièrement OpenWRT. Dans le contexte de l’application Kalsniff, l’utilisation de libpcap permet de capturer tous les paquets transitant sur l’interface réseau supplémentaire décrite au paragraphe précédent. Lorsqu’un pa- quet est capturé, la librairie rappelle la fonction de réception de paquet qui lui a été déléguée. Dans cette fonction, il est possible d’extraire l’adresse matérielle (adresse MAC de 6 octets) ainsi que la puissance reçue du paquet qui a été passée en paramètre.

La seconde tâche de l’application consiste à utiliser l’information recueillie par le processus décrit précédemment pour mettre à jour le filtre de Kalman et calculer la qualité de lien qui sera fournie au protocole OLSR. Cette tâche correspond intégralement au mécanisme qui a déjà été décrit au chapitre 4 et intégré à OLSR au chapitre 6. Il n’est donc pas nécessaire d’élaborer davantage sur le sujet.

En troisième et dernier lieu, pour chaque nouvelle valeur de qualité de lien calculée, l’application envoie l’information sur un tunnel sous forme d’une structure de données contenant la paire d’informations suivante : l’adresse matérielle (MAC) du nœud voisin concerné et le niveau de qualité du lien sous forme d’un nombre réel compris dans l’intervalle[0, 1].

Afin de déverminer le comportement de cette application avant de l’intégrer au protocole OLSR directement, un autre logiciel simple a été développé pour lire le flux de données sortant du tunnel système. Cette application nommée Kalreader ne fait que lire les structures de données (décrites au paragraphe précédent) et afficher les résultats en utilisant une ligne par paire reçue d’adresse matérielle et de valeur de qualité reçue. Il est ainsi possible de valider la valeur de la qualité associée à un lien en fonction de la puissance de réception entre deux nœuds. Bien

sûr, il ne s’agit que d’un utilitaire aidant au développement qui n’est pas nécessaire dans le fonctionnement normal du banc d’essais.