École polytechnique de l`université de Nantes Département

Commentaires

Transcription

École polytechnique de l`université de Nantes Département
École polytechnique de l'université de Nantes
Département INFORMATIQUE
Quatrième Année
PROJET TRANSVERSAL
En collaboration avec :
L’association Nantes-Wireless
ANNEE UNIVERSITAIRE 2007/2008
“ AUTO-CONFIGURATION DE BORNES POUR RESEAU
METROPOLITAIN SANS FIL ”
Dossier de Conception
Présenté par Florian DUPONT & Benoît FARRE
Le : 15 février 2008
Jury :
José MARTINEZ
Rémi LEHN
Fabien POULARD
Sommaire
Introduction............................................................................................................................................. 4
1.
2.
Présentation du sujet ...................................................................................................................... 5
1.1
La première problématique..................................................................................................... 5
1.2
La deuxième problématique ................................................................................................... 5
1.3
Le réseau pour notre étude..................................................................................................... 5
1.4
Les étapes de la réalisation ..................................................................................................... 7
L’existant du projet.......................................................................................................................... 9
2.1
Le chargement d’un Firmware ................................................................................................ 9
2.2
Enrichir le Firmware .............................................................................................................. 10
2.3
La configuration pour recevoir Internet ................................................................................ 10
2.4
La configuration des interfaces réseaux................................................................................ 11
2.5
La configuration du Wifi ........................................................................................................ 12
2.6
Le routage OLSR .................................................................................................................... 13
2.7
Les règles Iptables ................................................................................................................. 13
2.7.1
Network Address Translation ........................................................................................ 13
2.7.2
Communication entre les sous-réseaux ........................................................................ 14
2.8
2.8.1
Domain Name Server .................................................................................................... 14
2.8.2
Dynamic Host Control Protocol ..................................................................................... 14
2.9
3.
4.
5.
La configuration de DnsMasq ................................................................................................ 14
Remarques générales ............................................................................................................ 15
La conception des solutions .......................................................................................................... 16
3.1
Solution au problème du WDS .............................................................................................. 16
3.2
Idées de solution pour la configuration automatique des interfaces ................................... 18
3.2.1
Utilisation d’un serveur DHCP ....................................................................................... 18
3.2.2
Utilisation d’un tirage aléatoire + test de disponibilité ................................................. 18
Aspects techniques de la réalisation ............................................................................................. 21
4.1
Flashage du routeur avec le Firmware Kamikaze .................................................................. 21
4.2
Installation des paquetages manquants sur le système ....................................................... 22
4.3
Configuration initiale ............................................................................................................. 22
4.4
Tirage aléatoire et utilisation de WifiDog ............................................................................. 27
4.5
Configuration finale du routeur ............................................................................................ 28
Tests & Evaluations de notre solution........................................................................................... 32
2
Polytech’Nantes
Année 2007-2008
5.1
Les contraintes ...................................................................................................................... 32
5.2
Mesure de la bande passante ............................................................................................... 32
5.3
Efficacité du tirage aléatoire ................................................................................................. 32
Conclusion ............................................................................................................................................. 34
3
Polytech’Nantes
Année 2007-2008
Introduction
Ce dossier présente la partie conception de notre projet transversal. Nous commencerons par faire
un rappel de notre sujet, puis nous présenterons l’existant du projet. Nous présenterons ensuite les
solutions que nous allons apporter aux différents problèmes que nous auront présentés. Nous
terminerons enfin par la présentation des différents tests que nous réaliserons à la fin du projet et
qui nous permettront de tester la qualité de notre réalisation.
Etant donné le caractère particulier de notre projet, nous n’avons pas suivi les étapes classiques de
développement. En effet, notre sujet (« Auto-configuration de bornes pour un réseau sans fil ») ne
nous permet pas de réaliser les parties « Conception » et « Réalisation » indépendamment. Par
conséquent ces deux parties se retrouvent entremêlées. Nous avons donc suivi une méthode de
développement qui s’apparente plus aux méthodes agiles qu’à une méthode classique dans le sens
où pour réaliser la phase de conception, nous avons été obligés de réaliser des tests en parallèle qui
nous ont permit de vérifier la faisabilité de la solution que nous proposons. La partie réalisation a
donc été largement entamée durant cette phase.
Nous présenterons donc dans ce dossier la conception de la première partie de notre projet (qui en
constitue la plus grosse partie) et un bon nombre d’éléments qui se rapportent directement à la
réalisation. La deuxième partie du sujet ne sera présentée que lors de la dernière phase du projet, en
même temps que la réalisation définitive des deux solutions, et ne sera que brièvement abordée
dans ce dossier.
4
Polytech’Nantes
Année 2007-2008
1. Présentation du sujet
Notre sujet de Projet Transversal nommé « Auto-configuration de bornes pour un réseau
métropolitain sans fil » est redéfini dans cette partie. Nous abordons les différentes problématiques
que nous devons résoudre et les contraintes auxquelles nous sommes confrontés.
1.1
La première problématique
L’association Nantes-Wireless désire mettre en place une solution pour faciliter la configuration des
routeurs Wifi qu’elle déploie sur l’agglomération Nantaise. Dans l’idéal, nous devrons apporter une
solution d’auto-configuration qui permettra de libérer les administrateurs des phases d’installation et
de configuration.
Les avantages d’une telle solution sont, par exemple, le déploiement rapide d’un réseau pour un
événement exceptionnel ou encore la facilité d’utilisation qui permettrait à tout individu de réaliser
cette installation.
1.2
La deuxième problématique
Nous devons apporter une solution au problème de l’accès des clients du réseau Wifi à Internet. En
effet, lorsqu’Internet est disponible sur le réseau, un client qui se connecte peut y avoir accès mais le
client qui était connecté au réseau avant que l’accès apparaisse, n’en bénéficie pas.
La solution actuelle à ce problème est, pour l’hôte, d’attendre la fin de son bail DHCP ou bien une
déconnexion temporaire au réseau pour ensuite devenir un nouveau membre du réseau et récupérer
les nouvelles configurations.
Une solution est donc à apporter pour que les clients connectés avant l’arrivée d’une connexion
Internet soient mis à jour et puissent en disposer pleinement.
1.3
Le réseau pour notre étude
La figure 1 présente le réseau que nous utiliserons pour mettre au point des solutions pour résoudre
les problèmes de l’association et pouvoir les tester.
5
Polytech’Nantes
Année 2007-2008
Figure 1: Plan du réseau Wifi de Nantes-Wireless
Nous utiliserons 3 routeurs Wifi Linksys WRT54GL v1.1 : NW31, NW32, NW34. Chacun d’entre eux
fonctionne en mode Point d’accès pour les clients qui veulent se connecter au réseau et en mode
WDS avec les autres points d’accès Wifi. Le protocole de routage OLSR est utilisé sur les interfaces
communiquant en WDS.
Tout d’abord, le point d’accès Linksys WRT54GL est constitué physiquement de 4 ports Ethernet, 1
port Internet et d’une carte réseau Wifi. La figure 2 décrit le point d’accès.
Figure 2: Image d'un routeur Wifi Linksys WRT54GL
6
Polytech’Nantes
Année 2007-2008
Un vlan « 0 » est créé entre les 4 ports Ethernet du point d’accès et un second, vlan « 1 » avec le
port WAN seul (Port Internet). Une interface Wifi « wl0 » est configurée pour communiquer en Wifi.
La figure 3 présente l’architecture de fonctionnement du routeur Wifi.
Figure 3: Schéma de l’architecture d’un routeur WRT54G
1.4
1
Les étapes de la réalisation
La figure 4 présente les grandes étapes de configuration et d’installation des routeurs Wifi de
l’association. Le travail à réaliser est décomposé en 5 étapes que nous détaillons dans la partie
suivante. L’étude de ces étapes nous a amené à comprendre les problèmes auxquels l’association fait
face et à développer des solutions. Une partie plus technique sera présentée plus loin dans le dossier
pour donner les directives et les conditions de développement de ces solutions.
1
Source : http://www.grimonet.info/index.php?2007/11/10/38-openwrt-creation-d-une-dmz
7
Polytech’Nantes
Année 2007-2008
Figure 4: Les différentes étapes de mise en fonctionnement des routeurs
8
Polytech’Nantes
Année 2007-2008
2. L’existant du projet
Cette partie présente les configurations actuelles qu’utilise l’association et que nous avons mises en
place avec les trois routeurs wifi Linksys WRT54GL v1.1 que l’association nous a prêtés. Nous avons
donc réalisé un mini-réseau (uniquement trois points d’accès) semblable à celui actuellement
déployé. Dans ce chapitre, nous allons présenter les différents modules qui composent la mise en
place de ce dernier ainsi que les problèmes que rencontre l’association et que nous devons résoudre.
2.1
Le chargement d’un Firmware
La première étape fut de mettre à jour chacun des points d’accès avec le même Firmware, pour une
question de simplicité de mise en œuvre de nouveaux changements. Le Firmware utilisé sera la
version en cours de développement d’OpenWRT : Kamikaze.
Kamikaze est un Firmware récent et adapté aux périphériques que nous utilisons. Il a la particularité
de permettre la configuration d’un point d’accès en mode AP (Access Point) et client (Station) en
même temps. Kamikaze ne dispose pas d’une interface graphique pour la configuration par un
navigateur Web ; ce point peut être un inconvénient pour les non-initiés. Au-delà de ce problème, le
Firmware propose pour la première fois, un système de configuration contenu dans des fichiers qui
sont situés sur le disque dur et non plus dans la NVRAM.
Notre problème dans le projet est que Kamikaze est long à installer en termes de configuration des
interfaces, des protocoles, de téléchargement de paquetages … Notre première idée est de concevoir
un script ou un programme permettant en un minimum de commandes d’installer le Firmware et de
mettre à jour celui-ci. L’idée est donc de faciliter l’installation en ne laissant à l’utilisateur que
quelques paramètres à entrer.
Figure 5: Envoi du Firmware par TFTP
9
Polytech’Nantes
Année 2007-2008
2.2
Enrichir le Firmware
Il est nécessaire de mettre à jour le Firmware, une fois l’installation terminée. L’opération consiste
donc à télécharger les paquets manquants sur la version. Ces paquets sont relatifs à des commandes
ou des services utilisables sous Kamikaze.
Les paquets manquants pour notre projet sont les suivants :
-
OLSR (pour la mise en œuvre du routage OLSR entre les points d’accès)
IP (la commande IP permet une plus grande souplesse pour la configuration ou la
consultation des interfaces réseaux)
WL ou WLC (pour la configuration du Wifi et du WDS)
WifiDog (C’est le portail d’authentification sur le réseau qu’utilise l’association
actuellement)
Ces téléchargements se font grâce à la commande « ipkg » qui permet d’indiquer vers quels sites
web nous allons pouvoir trouver les paquets compatibles avec Kamikaze. Nous pouvons voir ici un
des problèmes qui pourrait se poser : si le routeur ne dispose pas d’un accès Internet, alors il est
impossible d’utiliser la commande ipkg. Il faut donc trouver une alternative, comme par exemple
charger « manuellement » les paquets.
Pour faciliter ces installations longues et répétitives, nous allons créer un script ou un programme
rassemblant l’ensemble des étapes à effectuer séquentiellement pour obtenir ces paquets et les
installer proprement sans difficulté pour l’administrateur. Cette solution constitue une étape de
l’auto-configuration ; en effet ce script ou ce programme sera lancé une seule fois : lors du premier
démarrage du routeur avec le nouveau Firmware chargé.
Figure 6: Etapes de Flashage et d'installation des paquets manquants
2.3
La configuration pour recevoir Internet
La mise à jour et le téléchargement des paquets nécessitent une connexion à Internet. Cette
connexion se fait automatiquement à l’aide du port Internet situé au dos du routeur. Ce port a la
particularité d’être en demande permanente d’adresse IP, il est client d’un service d’adressage
dynamique (DHCP). Lorsque l’on branche un câble sur ce port, il est nécessaire qu’un serveur DHCP
10
Polytech’Nantes
Année 2007-2008
soit démarré pour adresser le routeur wifi dynamiquement. Une fois cette étape réalisée, le routeur
ajoute les nouvelles données dans sa table de routage et permet l’envoie de paquets par défaut vers
une passerelle Internet.
La connexion vers Internet est automatisée et prévue dans les configurations générales du Firmware.
Le problème pour l’administrateur du point d’accès est la nécessité d’avoir à portée de main une
connexion Internet distribuée par un serveur DHCP.
Pour palier ce problème, la création d’un script ou programme permettant de rentrer manuellement
et statiquement les renseignements utiles pour se connecter à Internet pourra être développé. Ce
script (ou programme) sera situé dans le dossier de l’utilisateur « root » et pourra être exécuté par
l’administrateur. Celui-ci n’aura qu’à compléter les renseignements affichés. Il pourra être exécuté à
n’importe quel moment mais ne sera pas un script inclut au démarrage.
2.4
La configuration des interfaces réseaux
A la suite du flashage, le routeur redémarre en activant les ports LAN et en s’attribuant l’adresse IP
192.168.1.1/24. Cette configuration par défaut permet de se connecter tout d’abord en Telnet pour
attribuer un mot de passe « root » à l’aide de la commande « passwd root ». Un redémarrage est
ensuite nécessaire. Durant ce redémarrage, le serveur Dropbear (serveur SSH) est lancé. Ce serveur
permet une administration du point d’accès par une connexion SSH (Secure Shell) et désactive
automatiquement l’accès en Telnet. Une fois connecté en mode SSH, la première étape est de
donner un nom au point d’accès en modifiant le fichier /etc/config/system. La seconde étape est la
configuration des interfaces du routeur contenues dans le fichier /etc/config/network. Cette étape
nécessite une modification du contenu avec l’éditeur de texte « Vi ». On peut ainsi attribuer les
adresses IP et les masques que l’on souhaite.
Le problème dans ces configurations est le risque d’entrer de mauvaises adresses entrainant un
dysfonctionnement du point d’accès. La redondance des configurations peut être automatisée, pour
éviter à l’administrateur d’effectuer pour chaque routeur ces manipulations et limiter le risque de
mauvais paramétrage.
La création d’un script ou d’un programme est envisagée pour résoudre ce problème. Il s’appuiera
sur le fait que la seule différence dans cette étape entre chaque routeur est le numéro du point
d’accès. En effet, à partir de ce numéro, nous allons pouvoir déterminer l’adressage de toutes ses
interfaces. L’avantage sera une diminution du temps de configuration (par l’exécution du script) et
une simplicité de mise en œuvre.
11
Polytech’Nantes
Année 2007-2008
Figure 7: Plan d'adressage de l'association
Comme nous pouvons le constater, la plage d’adresse 10.44.31.192/26 n’est pour l’instant pas
utilisée. Elle nous permettra par la suite de configurer une interface Wifi virtuelle en mode client qui
nous permettra de scanner le réseau sans avoir à déconnecter les clients du point d’accès. Ce point
sera vu plus loin dans le dossier.
2.5
La configuration du Wifi
Cette étape permet d’activer et de configurer les interfaces Wifi. A la suite du flashage, aucune
interface Wifi n’est activée sur le point d’accès. Le fichier à configurer pour résoudre ce problème est
/etc/config/wireless. Dans ce fichier, on règle différents paramètres pour chaque interface et on peut
créer des interfaces virtuelles (notamment pour faire du WDS et pour simuler le mode client).
Chaque interface est décrite par son nom, le périphérique auquel elle est rattachée, son mode de
fonctionnement (Client, Point d’accès, Adhoc, WDS) et différentes options liées au mode de
fonctionnement.
Cette étape est redondante dans la configuration du matériel pour l’association et ne dépend que de
l’utilisation que l’on veut faire du routeur. Pour notre projet, chaque point d’accès est configuré en
mode « AP » (point d’accès) pour les clients, doit pouvoir communiquer avec les autres points
d’accès du réseau par l’intermédiaire d’interfaces WDS et doit pouvoir scanner le réseau via une
interface client virtuelle (le scan du réseau ne peut être effectué qu’en mode client).
12
Polytech’Nantes
Année 2007-2008
La configuration du Wifi est donc divisée en trois étapes : la première est la configuration en mode
point d’accès, la deuxième en mode client et la dernière en mode WDS. Les deux premières étapes
peuvent être automatisées par un script permettant la mise en place du routeur en mode AP pour les
clients et en mode client virtuel. La dernière est par contre plus difficilement réalisable. En effet, la
configuration d’une interface WDS nécessite de connaître l’adresse MAC du routeur avec lequel nous
souhaitons créer la liaison. Pour créer une interface WDS avec chacun des routeurs situés dans sa
zone de couverture, nous allons donc devoir récupérer chacune de leur adresse MAC.
L’enregistrement des adresses MAC des points d’accès dans le réseau est réalisable par un script qui
scannera le réseau et retiendra les adresses MAC des voisins. La modification du fichier
/etc/config/wireless se fera en conséquence. Le principe est de créer des interfaces virtuelles avec
chacun des routeurs voisins au moment du scan. Pour trouver les routeurs voisins, un scan du réseau
via l’interface client virtuelle que nous venons de créer sera fait périodiquement et sera lancé au
démarrage.
2.6
Le routage OLSR
Le protocole de routage utilisé par l’association est OLSR (Optimized Link State Routing). Il n’est pas
préinstallé sur Kamikaze mais il peut être téléchargé avec la commande « ipkg install olsrd ». Le
paquet s’installe sans problème et met en place une configuration « de base ». Pour l’association, il
est nécessaire de modifier quelques paramètres notamment les interfaces sur lesquelles OLSR doit
fonctionner.
La configuration du protocole est similaire sur tous les routeurs de l’association et ne dépend que du
numéro du routeur qui permet de retrouver les adresses de toutes les interfaces. Cette configuration
unique peut être faite au premier lancement du routeur Wifi et modifiée par différents scripts si
nécessaire accédant au fichier de configuration /etc/olsrd.conf.
2.7
Les règles Iptables
Iptables est la commande qui permet aux administrateurs réseaux de configurer Netfilter. Netfilter
est un module qui fournit à Linux des fonctions de pare-feu, de traduction d’adresse et de
journalisation du trafic réseau. Il intercepte les paquets IP et procède avant et après au routage.
Dans notre cas, Iptables doit être installé par la commande « ipkg install iptables » car le module
n’est pas présent dans la configuration d’origine de Kamikaze. Ce module doit ensuite être paramétré
pour faire de la translation d’adresse, faire suivre les paquets entre les différents sous-réseaux (LAN,
WLAN, WDS) et sécuriser le réseau global.
2.7.1
Network Address Translation
Pour l’accès Internet, il est nécessaire d’ajouter une règle précisant que tous les paquets à
destination de l’interface eth0.1 (interface de sortie vers Internet) soient translatés par le principe du
Network Address Translation (NAT). Un routeur fait du NAT (en Français de la « Translation d’Adresse
Réseau ») lorsqu'il fait correspondre les adresses IP internes non-uniques et souvent non routables
13
Polytech’Nantes
Année 2007-2008
d'un intranet à un ensemble d'adresses externes uniques et routables. Ce mécanisme permet de
faire correspondre une seule adresse externe publique visible sur Internet (ici, l’adresse IP de
l’interface eth0.1) à toutes les adresses d'un réseau privé (les sous-réseaux LAN, WLAN, WDS).
La configuration de Netfilter s’effectue donc en modifiant le fichier de configuration
/etc/firewall.user. Dans ce fichier, il est possible d’ajouter de nouvelles règles de filtrage et de NAT.
2.7.2
Communication entre les sous-réseaux
Le second problème est le fait que les sous-réseaux soient à l’origine bloqués pour communiquer
entre eux. Il est donc nécessaire d’ajouter des règles de FORWARD (« de retransmission ») des
paquets sur les autres interfaces du routeur. Celles-ci sont aussi généralisables pour tous les routeurs
de l’association. Un script ou un programme sera réalisé pour généraliser les configurations du
firewall Netfilter.
2.8
La configuration de DnsMasq
DnsMasq est un serveur de cache DNS (Domain Name Server) intégrant un serveur DHCP (Dynamic
Host Control Protocol). Il est spécialement adapté aux petits réseaux locaux.
2.8.1
Domain Name Server
Le serveur cache DNS est conçu pour répondre aux requêtes DNS (requête de résolution de nom de
domaine) des ordinateurs du réseau local (WLAN et LAN dans notre réseau). Son principal avantage
est de réduire significativement le temps de latence car il interroge le moins possible les serveurs
DNS du FAI (Fournisseur d’Accès Internet) et enregistre les requêtes déjà effectuées. Il ne transmet
donc la requête aux serveurs du FAI que si la réponse n’est pas présente dans le cache.
2.8.2
Dynamic Host Control Protocol
Le serveur DHCP permet de transmettre aux ordinateurs du réseau local la configuration de ce
réseau. Il suffit de définir dans la configuration de DnsMasq les plages d’adresses IP disponibles sur
chaque interface pour les clients. Ceci s’effectue en modifiant le fichier /etc/config/dhcp.
Le problème présenté peut être résolu de manière automatique en une seule fois lors de
l’installation. Un script ou un programme configurera le fichier /etc/config/dhcp lors de l’installation
du Firmware. Les plages d’adresse IP respecterons le plan d’adressage proposé par l’association.
La configuration du serveur DNS s’effectue en modifiant le fichier /etc/dnsmasq.conf.
14
Polytech’Nantes
Année 2007-2008
2.9
Remarques générales
La configuration d’un routeur Linksys WRT54GL v1.1 utilisant Kamikaze peut se schématiser par la
figure 8 qui modélise l’ensemble des fichiers de configuration qui devront être modifiés pour faire
fonctionner le réseau de l’association.
Figure 8: Arbre des dépendances des fichiers de configuration
L’ensemble des fichiers et processus à configurer ne dépend que de deux choses :
-
Le numéro du point d’accès
Le nombre de point d’accès voisins ainsi que leurs adresses MAC.
Le numéro du point d’accès permet de configurer l’ensemble des interfaces en attribuant des plages
d’adresses IP et le nom du routeur automatiquement de la même manière sur chaque machine. C’est
un paramètre clé dans la configuration du routeur.
En revanche, il est difficile de créer les interfaces WDS pour communiquer avec les autres points
d’accès du réseau de l’association. Il est nécessaire de connaître l’adresse MAC des voisins pour
ensuite créer une interface virtuelle et la configurer pour communiquer avec eux. Cette étape doit
être automatisée.
L’ensemble des solutions que nous proposons tiennent compte de ces remarques et répondent au
problème en substituant ces deux paramètres.
15
Polytech’Nantes
Année 2007-2008
3. La conception des solutions
Cette partie justifie l’utilisation du Firmware Kamikaze dans notre projet et met en avant les
solutions que nous avons exploitées pour résoudre les problèmes de l’association Nantes-Wireless.
3.1
Solution au problème du WDS
La figure 9 modélise le fonctionnement d’un point d’accès incluant le principe automatique de scan
du réseau en mode Client pour trouver les routeurs voisins. Des explications du fonctionnement sont
fournies à la suite du schéma.
Figure 9: Principe de fonctionnement d'un Routeur
Le démarrage s’effectue selon 3 points :
-
Présence ou non de Kamikaze sur le point d’accès
Nécessité d’installer des paquets manquants
Démarrage en mode opératoire (mode normal)
Dans le premier cas, le point d’accès n’est pas du tout configuré pour fonctionner sur le réseau de
l’association ; il est donc nécessaire de le flasher et de le configurer. Dans le second cas, le routeur
utilise déjà Kamikaze mais n’est pas configuré pour communiquer comme les autres ; il faut donc le
16
Polytech’Nantes
Année 2007-2008
mettre à jour et installer les paquets nécessaires à la configuration. Dans le dernier cas, le routeur
fonctionne de manière autonome s’il démarre en mode normal ; sinon il est reconfiguré.
A la suite de chacune de ces trois parties, nous pouvons enfin commencer la configuration générale
du point d’accès (de tous les services) et le chargement des configurations pour le mode normal. Le
routeur est donc autonome et peut fonctionner normalement avec son WLAN (Wireless Local Area
Network) et son LAN (Local Area Network). Une nouvelle phase est ici rajoutée : l’automatisation du
WDS.
Cette phase permet de scanner le réseau Wifi périodiquement (la période est à définir) en utilisant
l’interface virtuelle client que nous avons créée précédemment. Suivant les résultats du scan, on
détecte ou non la présence d’un ou plusieurs routeurs de l’association et on récupère leurs adresses
MAC. La récupération de ces informations permet ensuite de créer un nombre nécessaire
d’interfaces virtuelles WDS (au maximum 3) pour communiquer avec les routeurs voisins. Une
reconfiguration et un redémarrage du routeur est nécessaire. Celui-ci redémarre en mode normal et
retrouve son autonomie et se lance dans une nouvelle phase d’attente.
Avantage
L’avantage principal de cette première phase de résolution du problème est que l’administrateur du
point d’accès est soulagé du travail de configuration des interfaces WDS. Celui-ci n’a plus à intervenir
dans la configuration de chaque routeur pour les faire communiquer ensemble.
Inconvénient
Le principal inconvénient est que les étapes de configuration dépendent encore d’un paramètre qui
n’est pas auto-configuré : le numéro du routeur. Cette solution ne propose pas de système
permettant d’attribuer un numéro automatiquement au routeur lors de sa configuration ainsi il est
encore nécessaire de le passer en paramètre au premier démarrage du point d’accès. La partie
suivante propose une solution à ce problème.
17
Polytech’Nantes
Année 2007-2008
3.2
Idées de solution pour la configuration automatique des
interfaces
3.2.1
Utilisation d’un serveur DHCP
La première solution à laquelle nous avions pensé était basée sur l’utilisation d’un serveur DHCP
central. Cette solution consistait à mettre le premier point d’accès démarré en mode serveur DHCP
pour l’ensemble des autres points d’accès sur les différents liens WDS créés. Cette solution aurait
alors permis une simplification de l’adressage de chaque point d’accès puisque chacun d’entre eux
aurait donc été capable de déterminer les plages d’adresses pour ses sous-réseaux Wifi et LAN
d’après l’adresse qu’il aurait reçue par le serveur DHCP (adresse qui contient notamment le numéro
affecté au routeur et qui est la base de l’adressage de toutes les interfaces).
Après étude de cette solution, nous nous sommes rendu compte que malgré son apparente
simplicité de mise en œuvre, cette-dernière était beaucoup plus compliquée qu’il n’y paraissait. Le
premier problème est le fait que si le routeur possédant le serveur DHCP tombe en panne, alors c’est
l’ensemble du réseau qui s’effondre. Nous avons alors cherché une solution qui pourrait résoudre ce
problème, et donc telle que le réseau ne soit pas centralisé autour d’un serveur.
Le deuxième problème est le fait que le serveur DHCP doit être joignable par tous les points d’accès
arrivant sur le réseau ; hors cela n’est pas possible. En effet, un serveur DHCP ne peut attribuer des
configurations dynamiques qu’à des clients DHCP se situant sur son sous-réseau car les trames ARP
et BOOTP ne traversent pas les routeurs.
Ce problème pourrait néanmoins être résolu en utilisant des agents de relais DHCP. Comme son nom
l’indique, un agent de relais DHCP relaie les messages DHCP échangés entre un client et un serveur
DHCP situés sur deux sous-réseaux différents séparés par ce-dernier. Ainsi chaque point d’accès
serait client DHCP du serveur central et à la fois serait agent de relais DHCP pour les autres points
d’accès arrivant dans le réseau. Un autre problème se pose, un serveur et un agent de relais DHCP
doivent avoir des adresses IP statiques. Ainsi cette solution paraît trop difficile à mettre en œuvre et
serait dangereuse de part sa stratégie de centralisation. De plus le fait de devoir spécifier des
adresses statiques rentre en conflit avec notre sujet puisqu’il va à l’encontre d’une autoconfiguration.
3.2.2
Utilisation d’un tirage aléatoire et test de disponibilité
La deuxième solution que nous proposons est un système de tirage aléatoire d’un numéro au
démarrage du routeur, présenté sur la figure 10.
18
Polytech’Nantes
Année 2007-2008
Figure 10: Principe de fonctionnement de la solution par tirage aléatoire
Pour résoudre le problème de l’auto-configuration des interfaces, il faut d’abord affecter un numéro
au routeur. C’est ensuite à partir de ce numéro que seront configurées les adresses de chacune des
interfaces du routeur.
Présentation de la solution
Tout d’abord, le routeur va configurer ses interfaces avec une adresse que l’on spécifie réservée :
10.44.254.x. Le routeur va donc maintenant pouvoir communiquer avec les autres points d’accès et
notamment disposer d’une connexion Internet si elle existe. Le routeur va ensuite se connecter au
serveur d’authentification WifiDog pour récupérer la liste des numéros des points d’accès qui sont
déjà en service. Une fois la liste récupérée, le routeur va tirer au hasard un nombre entre 1 et 253 et
vérifier si ce numéro n’est pas déjà utilisé. S’il est libre, le routeur va alors reconfigurer toutes ses
interfaces puis va s’enregistrer auprès du service d’authentification pour réserver le numéro sinon il
va recommencer l’opération jusqu’à obtenir un numéro libre. Si le routeur ne dispose pas d’une
19
Polytech’Nantes
Année 2007-2008
connexion internet, il sera alors demandé à l’opérateur de rentrer manuellement le numéro du
routeur.
Avantage
Cette solution offre l’avantage, si le routeur possède une connexion internet, de limiter le risque
d’erreur, notamment en évitant que deux routeurs possèdent le même numéro. Cette solution est
intéressante dans la mesure où la plupart des routeurs disposeront d’un accès Internet.
Inconvénient
Un inconvénient est lié au fait que le routeur « réserve » le sous-réseau 10.44.254.X durant sa phase
de lancement. Rien n’empêche cependant deux routeurs de démarrer en même temps et de prendre
cette même adresse.
Pire encore, imaginons une coupure de courant qui toucherait plusieurs points d’accès, ces-derniers
redémarreraient alors tous au même moment. Une solution pour palier à ce problème pourrait être
de demander à l’opérateur si la configuration doit être faite au démarrage du routeur. Dans ce cas,
l’opérateur indiquerait au routeur de ne pas se reconfigurer s’il s’agit d’un redémarrage intempestif.
20
Polytech’Nantes
Année 2007-2008
4. Aspects techniques de la réalisation
Nous faisons dans cette partie référence au travail qui sera produit pour mettre en œuvre les
solutions expliquées dans la partie précédente. Nous expliquons, dans l’ordre, les étapes partant du
flashage des routeurs à la mise en œuvre de l’auto-configuration. La chronologie n’est plus respectée
dans la solution proposée.
Figure 11: Chronologie actuelle des modifications dans les différents fichiers par l’administrateur
4.1
Flashage du routeur avec le Firmware Kamikaze
Il existe différentes manières de flasher un routeur Linksys WRT54GL. Il est préférable de flasher le
routeur par TFTP, notamment dans le cas où le flash ne fonctionnerait pas il serait alors toujours
possible de transférer l’image du Firmware précédant.
La procédure de base en utilisant un client TFTP pour charger un nouveau Firmware sur le routeur
est :
-
-
Mettre le routeur hors-tension
Lancer le client TFTP
o Donner l’adresse du routeur (TFTP 192.168.1.1)
o Mettre en mode octet/binary (binary)
o Mettre le client en réception jusqu’à la fin de la transmission (rexmt 1)
o Envoyer le fichier (put openwrt-version-du-Firmware.bin)
Allumer le routeur
Le client TFTP reçoit un accusé de réception et commence l’envoi
Cette procédure peut être réalisée en une seule ligne :
echo –e "binary\nrexmt 1\ntimeout 60\ntrace\nput openwrt-wrt54g-2.4squashfs.bin" | tftp 192.168.1.1
Remplacer « openwrt-wrt54g-2.4-squashfs.bin » par le fichier correspondant si la version utilisée est
différente.
21
Polytech’Nantes
Année 2007-2008
Attendre ensuite le redémarrage du point d’accès (jusqu’à ce que le voyant Power arrête de
clignoter) puis se connecter en Telnet via la commande suivante :
telnet 192.168.1.1
Il est ensuite nécessaire de changer le mot de passe administrateur du routeur avec la commande
suivante :
passwd root
Une fois le mot de passe root saisi, l'accès par telnet est désactivé. La connexion au point d’accès se
réalise maintenant via ssh :
ssh 192.168.1.1
Ces différentes commandes devront donc être regroupées dans un script qui prendra en paramètre
le nom du fichier binaire image du Firmware.
4.2
Installation des paquetages manquants sur le système
Nous allons maintenant installer certains paquets qui nous seront nécessaires par la suite pour
réaliser les différentes configurations.
ipkg install ip wlc wl olsrd tcpdump iptables wifidog
Pour réaliser cette étape, il faut que le routeur possède déjà un accès Internet. Si ce n’est le cas, il
faudra commencer par la configuration des interfaces pour essayer de récupérer une connexion sur
un point d’accès voisin avant de la réaliser. Si, dans le pire des cas, le routeur ne peut obtenir aucun
accès Internet, alors les fichiers seront transférés manuellement depuis un média amovible (clé USB,
…).
4.3
Configuration initiale
La configuration initiale active l’interface Wifi dans le fichier /etc /config/wireless. Nous pouvons
trouver, dans cette étape, deux états possibles :
-
Internet est connecté directement sur le port WAN
Internet n’est pas présent sur le point d’accès.
Dans le premier cas, nous pouvons directement utiliser l’accès Internet pour se connecter sur le
serveur WifiDog de l’association. Nous récupérons ainsi la liste des numéros de routeurs
actuellement utilisés en analysant la page Web :
22
Polytech’Nantes
Année 2007-2008
http://auth.nantes-wireless.org/hotspot_status.php?format=XML
Cette partie sera détaillée dans la suite du dossier.
Dans le deuxième cas, nous pouvons chercher s’il y a d’autres points d’accès de l’association à
proximité. Pour cela, il est nécessaire de configurer l’interface Wifi « wl0 » en mode client pour
pouvoir scanner les points d’accès présents dans la zone de couverture du routeur :
config wifi-device
option type
option channel
wl0
broadcom
9
config wifi-iface
option network sta
option device
wl0
option mode
sta
option ssid
nantes-wireless.org
option hidden
0
option encryption none
L’étape suivante est le redémarrage des configurations réseaux à l’aide de la commande :
/etc/init.d/network restart
Nous pouvons ainsi réaliser un scan de la zone en utilisant la ligne de commande suivante :
iwlist wl0 scan
Le résultat de cette recherche nous amènera dans deux situations différentes :
-
Il existe un point d’accès Wifi de l’association dans le périmètre
Aucun voisin du point d’accès n’a été détecté.
La situation où aucun point d’accès n’a été détecté nous conduit ensuite vers une étape d’autoconfiguration du routeur sans prise en compte de l’existence éventuelle d’autres points d’accès du
réseau. Le point d’accès est isolé.
Si le point d’accès a détecté d’autres routeurs de l’association, il en extrait les adresses MAC qu’il
retrouve dans le résultat de la commande iwlist. Le routeur doit alors être configuré en mode WDS
avec les autres routeurs du réseau de l’association. Il crée un script d’autocréation d’interface WDS
et modifie le fichier /etc/init.d/done pour qu’il soit exécuté à chaque démarrage du routeur.
echo ‘#!/bin/ash
let tocount=1
echo $tocount
let counter=$(uci show |grep mode=wds |sed -n '$=')
let counter=counter+1
echo $counter
while [ $tocount -lt $counter ]
do
23
Polytech’Nantes
Année 2007-2008
ifconfig wds0.$tocount up
let tocount=tocount+1
echo $counter
done
ifconfig |grep wds|awk {'printf $1'} |sed 's/wds0/\nwds0/g'|grep '.'
|sed 's/^/brctl addif br-lan /g' > /tmp/addwds.sh && chmod +x
/tmp/addwds.sh && /tmp/addwds.sh’ >/etc/wdsauto.sh
# On le rend executable
chmod +x /etc/wdsauto.sh
Le fichier /etc/init.d/done doit être complété de la manière suivante :
#!/bin/sh /etc/rc.common
# Copyright (C) 2006 OpenWrt.org
START=95
boot() {
[ -d /tmp/root ] && {
lock /tmp/.switch2jffs
firstboot switch2jffs
lock -u /tmp/.switch2jffs
}
# set leds to normal state
. /etc/diag.sh
set_state done
# Démarrage automatique du wds
sh /etc/wdsauto.sh
}
On crée une interface virtuelle en mode WDS dans le fichier /etc/config/wireless en ajoutant les
lignes suivantes.
config wifi-iface
option network wds
option device
wl0
option mode
wds
option ssid
wdsnetwork
option encryption none
option bssid
<@MAC du routeur Voisin>
Le champ bssid est suivi de l’adresse MAC d’un des routeurs voisins qui a été au préalable enregistré
lors du scan par la commande iwlist. Pour extraire l’adresse MAC du voisin dans le résultat du scan,
nous utilisons les commandes du type grep et cut.
La modification du fichier /etc/config/network est réalisée en ajoutant les lignes suivantes :
24
Polytech’Nantes
Année 2007-2008
### WDS configuration
configuration network wds
option ifname
"none"
option ipaddr
10.44.254.129
option netmask 255.255.255.192
option broadcast 255.255.255.255
À ces modifications vient s’ajouter celle du protocole de routage OLSR dans le fichier /etc/olsrd.conf :
DebugLevel
0
IpVersion
4
AllowNoInt
yes
Pollrate
0.1
TcRedundancy
2
MprCoverage
7
LinkQualityFishEye
1
LinkQualityWinSize
100
LinkQualityDijkstraLimit 0 5.0
Hna4 {
10.44.254.0 255.255.255.0
}
LinkQualityLevel 2
UseHysteresis
no
Interface "wl0"
{
Ip4Broadcast
HelloInterval
HelloValidityTime
TcInterval
TcValidityTime
MidInterval
MidValidityTime
HnaInterval
HnaValidityTime
}
255.255.255.255
5.0
90.0
2.0
270.0
15.0
90.0
15.0
90.0
L’importance dans la modification du fichier de configuration d’OLSR est la spécification de l’interface
sur laquelle il est exécuté et de la route statique (paramètre HNA4) qui permet de fixer une route
vers le propre réseau du point d’accès. À ce stade de la configuration, OLSR n’est pas encore
fonctionnel. Il est nécessaire d’effectuer les modifications suivantes pour adapter OLSR à notre
Firmware:
### Supprime le fichier non utilisé
rm /etc/init.d/S60olsrd
### Creation du fichier pour le démarrage d'OLSR
echo '#!/bin/sh
case "$1" in
boot|start) olsrd -f /etc/olsrd.conf
;;
stop) killall olsrd
25
Polytech’Nantes
Année 2007-2008
;;
*)
echo "$0 start" >&2
exit 1
;;
esac' >/etc/init.d/olsrd
chmod 755 /etc/init.d/olsrd
ln -s /etc/init.d/olsrd /etc/rc.d/S60olsrd
Il est ensuite nécessaire de redémarrer dans un premier temps les configurations réseaux du
routeur, puis le protocole de routage OLSR :
/etc/init.d/network restart
/etc/init.d/olsrd restart
Le routeur peut ainsi communiquer en mode WDS avec le routeur voisin dont on a spécifié l’adresse
MAC dans le fichier /etc/config/wireless.
Nous sommes alors encore confrontés à deux situations possibles :
-
Le point d’accès voisin ou un point d’accès du réseau sur lequel on est connecté offre un
accès Internet
Aucun des points d’accès du réseau ne possède d’accès Internet.
Dans le premier cas, si nous pouvons utiliser l’accès internet d’un autre routeur, nous récupérons les
informations nécessaires à la configuration du routeur sur le serveur WifiDog de l’association.
Dans le second cas, nous retombons sur une issue où le point d’accès ne peut pas récupérer
d’information par le serveur WifiDog via Internet. La solution est donc de tirer un numéro aléatoire
et de vérifier qu’aucun routeur ne possède une adresse avec ce numéro. Pour cela nous utilisons la
commande ping à destination de la première interface WDS de ce routeur s’il existe:
ping –c 10 10.44.X.129
Deux cas sont possibles :
-
Aucun routeur distant ne répond au ping qu’il envoie
Un routeur du réseau a répondu.
Dans le premier cas, le routeur peut utiliser le nombre qu’il a tiré aléatoirement et dont personne ne
se sert sur le réseau joignable.
Nous développerons ces étapes dans une des sections suivantes.
Dans le deuxième cas, le routeur est obligé d’abandonner le nombre reçu au premier tirage aléatoire.
Il doit recommencer son mécanisme à partir du tirage d’un nombre aléatoire jusqu’à obtenir un
numéro auquel aucun autre routeur ne répond. Une boucle est ainsi formée et tant que le routeur
n’a pas tiré un nombre non utilisé sur le réseau, il ne sort pas de cette boucle.
26
Polytech’Nantes
Année 2007-2008
Cette solution (utilisation d’un ping) reste tout de même un peu instable dans la mesure où un
routeur possédant l’adresse spécifiée peut ne pas être accessible à ce moment précis pour des
raisons diverses et variées. On voit alors le problème qui se pose : les deux routeurs possèderont le
même numéro. Cette solution mériterait probablement une amélioration mais nous supposerons
pour le moment que dans la plupart des situations, il existe au moins un accès Internet disponible et
donc que nous allons pouvoir utiliser la liste des numéros présente sur WifiDog.
4.4
Tirage aléatoire et utilisation de WifiDog
Dans cette section, nous décrivons plus précisément le tirage aléatoire d’un nombre et l’utilisation
que nous faisons de WifiDog.
Tirage aléatoire
Aucune commande Shell n’existe pour générer des nombres aléatoires. Néanmoins, ce tirage peut
être réalisé à l’aide des fichiers spéciaux /dev/urandom et /dev/random. Ces fichiers spéciaux
caractères fournissent une interface avec le générateur de nombres aléatoires du noyau.
Le générateur de nombres aléatoires regroupe du bruit provenant de son environnement par
l'intermédiaire des pilotes de périphériques et d'autres sources, et le stocke dans un réservoir
d'entropie. Le générateur mémorise également une estimation du nombre de bits de bruit dans son
réservoir d'entropie, et utilise son contenu pour créer des nombres aléatoires.
A l’aide des commandes cut et hexdump, nous pouvons extraire des nombres entiers. Le script
d’automatisation de cette étape effectuera un test sur le nombre pour vérifier qu’il est compris dans
l’intervalle [1-253].
Utilisation du serveur WifiDog
L’utilisation du serveur WifiDog de l’association est possible lorsque le routeur dispose d’Internet.
Nous pouvons ainsi trouver les points d’accès actuellement répertoriés sur le serveur en consultant
le fichier suivant à l’aide de la commande :
wget
http://auth.nantes-wireless.org/hotspot_status.php?format=XML
dont le contenu est :
…
<hotspot>
<hotspotId>a674135184717650a526e701ef3ec450</hotspotId>
<name>nw01</name>
<nodes>
<node>
<nodeId>a674135184717650a526e701ef3ec450</nodeId>
<numOnlineUsers>0</numOnlineUsers>
<creationDate>2006-08-01</creationDate>
27
Polytech’Nantes
Année 2007-2008
<status>down</status>
<gisLatLong lat="47.319429" long="-1.684400"/>
</node>
</nodes>
<openingDate>2006-08-01</openingDate>
<webSiteUrl>http://www.nantes-wireless.org</webSiteUrl>
<globalStatus>0</globalStatus>
<description>Point d'accès nw01 (Rémi)
</description>
<city>Vigneux de Bretagne</city>
<postalCode>44360</postalCode>
<country>France</country>
<gisCenterLatLong lat="47.319429" long="-1.684400"/>
</hotspot>
…
Dans ce fichier, nous voulons récupérer les lignes contenant la balise <name> et effectuer un
traitement sur la chaîne de caractère pour en extraire le numéro du point d’accès. Par exemple, si
nous obtenons sur une ligne : « <name> nw31</name> », à l’aide des commandes cut et grep, nous
récupérons « 31 » et le routeur sait que ce numéro est pris. Le routeur doit donc choisir un nombre
compris dans l’intervalle [1-253] et qui n’est pas dans la liste récupérée par le traitement du fichier
hostpot_statut-2 .php ?format=XML.
4.5
Configuration finale du routeur
La configuration finale est effectuée uniquement lorsque le routeur connaît l’ensemble des
paramètres qui permettent de le configurer totalement. Les fichiers suivants seront modifiés de
manière à ce que le routeur fonctionne en toute autonomie :
-
Configuration de /etc/config/system
Configuration de /etc/config/network
Configuration de /etc/config/wireless
Configuration de /etc/config/dhcp
Configuration de /etc/dnsmasq.conf
Configuration de /etc/firewall.user
Pour une question de simplicité des configurations, nous préférons recréer entièrement chacun des
fichiers plutôt que de les modifier.
Pour débuter, le routeur doit changer son nom qui est à l’origine « Openwrt » pour devenir « nwXX »
dans le fichier /etc/config/system.
config system
option hostname nwXX
Nous continuons maintenant avec le fichier /etc/config/network. Le numéro du routeur est ici
remplacé par « XX ».
28
Polytech’Nantes
Année 2007-2008
#### VLAN configuration
config switch eth0
option vlan0
"0 1 2 3 5*"
option vlan1
"4 5"
#### Loopback configuration
config interface loopback
option ifname
"lo"
option proto
static
option ipaddr
127.0.0.1
option netmask 255.0.0.0
#### LAN configuration
config interface lan
option type
option ifname
option proto
option ipaddr
option netmask
bridge
"eth0.0"
static
10.44.XX.65
255.255.255.192
### WAN configuration
config interface wan
option ifname
"eth0.1"
option proto
dhcp
### AP configuration
config interface ap
option ifname
option proto
option ipaddr
option netmask
"none"
static
10.44.XX.1
255.255.255.192
### Sta configuration
config interface sta
option ifname
"none"
option proto
static
option ipaddr
10.44.XX.193
option netmask 255.255.255.192
### WDS configuration
Config interface wds
option ifname
"none"
option proto
static
option ipaddr
10.44.XX.193
option netmask 255.255.255.192
option broadcast 255.255.255.255
Le fichier /etc/config/wireless en accord avec le fichier network est le suivant :
config wifi-device wl0
option type
option channel
broadcom
9
29
Polytech’Nantes
Année 2007-2008
###Mode AP
config wifi-iface
option device
wl0
option network ap
option mode
ap
option ssid
nantes-wireless.org
option encryption none
###Mode Station
config wifi-iface
option device
option network
option mode
option hidden
option ssid
option encryption
wl0
sta
sta
1
nantes-wireless.org
none
### Mode WDS
config wifi-iface
option device
option network
option mode
option hidden
option ssid
option encryption
option bssid
wl0
wds
wds
1
wdsap
none
<@MAC routeur voisin>
Il faut ensuite configurer le serveur DHCP par l’intermédiaire du fichier /etc/config/dhcp.
# Serveur DHCP sur le
config dhcp
option interface
option start
option limit
option leasetime
LAN
# Serveur DHCP sur le
config dhcp
option interface
option start
option limit
option leasetime
WIFI
lan
66
30
12h
ap
2
30
12h
Le serveur DHCP démarré sur le réseau local et le Wifi dépend des configurations de DnsMasq. Les
configurations du serveur DnsMasq se font dans le fichier /etc/dnsmasq.conf. Il est possible de
modifier le fonctionnement du serveur DNS en ajoutant ou en modifiant certaines options. Dans le
cadre d’un fonctionnement optimal du réseau, nous réécrirons ce fichier lors de la phase de
réalisation.
30
Polytech’Nantes
Année 2007-2008
La dernière configuration concerne le pare-feu Netfilter. Sa configuration est réalisable à l’aide de la
commande iptables qui permet de créer des règles de filtrage, de NAT et de journalisation. Ces
configurations se font dans le fichier /etc/firewall.user car il n’est pas recommandé d’écrire
directement les règles dans le fichier /etc/init.d/firewall. Nous rédigerons de nouvelles règles
adaptées à notre solution.
31
Polytech’Nantes
Année 2007-2008
5. Tests & Evaluations de notre solution
Pour évaluer notre solution, nous serons amenés à faire des tests qui détermineront si la solution est
utilisable et respecte les contraintes du projet énoncées dans le cahier des charges. Ces tests
évalueront différents points que nous expliquons dans cette partie.
5.1
Les contraintes
Les contraintes actuelles sont fixées par le choix de l’association dans le déploiement de son réseau
libre. Un grand nombre de contraintes est fixé par les limites quantitatives du réseau en terme
d’allocation d’adresses IP. Les capacités d’adressage du réseau Nantes-Wireless sont rappelées dans
le tableau 1.
CONTRAINTES
Nombre maximum de points d'accès sur le réseau
Nombre maximum d'hôtes sur un point d'accès
Nombre maximum d'hôtes sur le réseau
EFFECTIF
255
62 x 2 = 124
124 x 255 = 31620
Tableau 1: Les capacités d’adressage du réseau Nantes-Wireless
Actuellement, il reste une plage de sous-réseau non-utilisée par l’association : 10.44.XX.192/26.
Cette plage sera peut être exploitée par notre solution, notamment dans le cadre où un point d’accès
est configuré en mode Station (ou client). Cet usage restera cependant réservé à la phase de test.
5.2
Mesure de la bande passante
Notre projet a pour but de simplifier le déploiement du réseau Nantes-Wireless et en aucun cas de
limiter ses performances. Ainsi nous proposons d’effectuer des mesures de la bande passante
comme l’explique le paragraphe suivant.
Nous proposons de faire différents tests permettant d’évaluer la qualité de notre solution. Ces tests
se caractérisent sur une durée (une échelle de temps) et l’étude des différents protocoles utilisant la
bande passante. Ces résultats seront modélisés sous la forme de tableaux et de graphiques,
montrant à divers instants de capture, le pourcentage d’utilisation de bande passante en fonction
des différents protocoles.
Par ailleurs, dans le cas où l’utilisation de la bande passante serait jugée non-viable, nous proposons
de mettre en œuvre de la qualité de service (QoS). Nous pourrions créer à l’aide de la commande
iptables et de la table « mangle » du pare-feu Netfilter des règles régulant le trafic.
5.3
Efficacité du tirage aléatoire
Il est intéressant de visualiser à grande échelle l’efficacité du tirage aléatoire d’un nombre compris
dans l’intervalle [1-253]. Il est évident que plus le nombre de points d’accès augmente, moins il y a
32
Polytech’Nantes
Année 2007-2008
de chance pour trouver un nombre non-utilisé sur le réseau. Pour juger de la pertinence de cette
solution nous proposons de simuler, selon des critères probabilistes, différentes étapes de tirage
aléatoire que ferait un routeur. Il en résultera divers diagrammes et des conclusions portées sur cette
étude.
33
Polytech’Nantes
Année 2007-2008
Conclusion
Comme nous l’avons vu tout au long de ce dossier, les parties conception et réalisation de notre
projet sont entremêlées, un peu à la manière des méthodes de développement agiles. Nous avons
donc présenté ici la conception de la première partie de notre sujet, à savoir la partie autoconfiguration des routeurs qui constitue la plus grosse partie de notre projet. Nous avons aussi
présenté un bon nombre d’éléments qui nous seront utiles lors de la partie réalisation.
La conception de la deuxième partie de notre projet a été abordée plus brièvement. Elle sera
développée plus amplement lors de la phase de réalisation. Nous avons cependant commencé à
explorer des solutions envisageables pour résoudre les problèmes qui nous seront posés dans cette
partie.
34
Polytech’Nantes
Année 2007-2008