Travail de fin d`études

Watelet Thierry
5X58
Travail de fin d’études
Réseaux mesh sans fil.
Professeur : Mr Lurquin Pascal
Année Scolaire 2009-2010
Table des matières
1. Introduction
1.1. Finalité du projet
1.2. Problèmes rencontrés
1.3. Outils utilisés
1.4. Etat actuel du projet
1.5. Avenir de ce projet & approche commerciale
2. Mesh & Wireless
2.1. Qu’est-ce qu’un réseau Mesh ?
2.2. Notions de redondance, de scalability et de load balancing.
2.3. Protocoles Mesh
2.3.1.OLSR
2.3.2.B.A.T.M.A.N.
2.3.3.Babel
2.3.4.Quel protocole choisir et pourquoi ?
2.4. Wireless
2.4.1.802.11 a/b/g/n
2.4.2.Matériel disponible sur le marché & choix du matériel utilisé
2.5.Aspects pratiques
2.6. Design de réseaux Mesh Wireless. Avantages et inconvénients.
3. Operating sytem
3.1. Description
3.2. Choix de l’operating system
3.3. Installation et utilisation d’OpenWrt pour personnaliser l’operating system
3.4. Fichiers de configuration d’OpenWrt
3.5.Résultats
4. Annexes
4.1. Bibliographie
4.2.Remerciements
1.
Introduction
1.1.
Finalité du projet.
Le but de ce projet est de concevoir un boitier de communication « tout en un », dont la
configuration est la plus simple possible et pouvant être installé dans des environnements difficiles
(fortes chaleurs, froid extrême, poussière, milieu industriel, etc…).
Ce boitier doit être capable de communiquer avec d’autres boitiers grâce aux technologies wireless,
formant ainsi un réseau mesh. Les vitesse de transmission doivent être celle décrites par la norme
802.11n.
Les cartes radio doivent fonctionner aussi bien dans la bande des 2.4 GHz (802.11g) que dans celle
des 5 GHz (802.11a)
Toutes les communications entre les boitiers doivent être réalisées sans fil et l’alimentation électrique
doit être la plus simple possible.
La fiabilité est un critère important : ces boitiers sont destinés à déployer des réseaux de
vidéosurveillance.
Les boitiers doivent être compatibles avec les tensions d’alimentation électriques de tous les pays (de
110 à 250 Volts) ou doivent être alimentés en PoE (Power over Ethernet).
Le coût de fabrication de ces boitiers doit être le moins élevé possible tout en garantissant une
qualité optimale.
1.1.
Problèmes rencontrés
Nous travaillons avec deux fabricants de chipset pour les cartes radio : Atheros et Ralink.
Atheros ne donne pas de version open-source de son driver. Actuellement, un groupe de
développement travaille au le développement d’un driver pour les cartes utilisant la norme 802.11n,
appelé couramment ath9k. Ce driver, même s’il est à présent mature et stable présente un énorme
problème : il n’intègre pas le DFS, même si cette fonctionnalité est codée nativement dans le chipset.
Le DFS (Dynamic Frequency Selection) est, comme son nom l’indique, un mécanisme permettant à
des appareils communiquant sur un certain canal WIFI de changer automatiquement de canal si, par
exemple, un radar effectue un balayage sur ce canal. Dans nos régions, cette détection de radar est
obligatoire sur tous les canaux WIFI à l’exception d’un seul, ce qui dans le cas d’appareil équipés de
plusieurs radios ne permet d’en utiliser qu’une seule.
De plus, les chipsets Atheros sont plutôt restrictifs à ce niveau, car ils utilisent une base de données
pour restreindre les canaux utilisables et les puissances d’émission dans ces canaux d’après le code de
pays renseigné.
Ce problème a été résolu de manière « brutale » : j’ai trouvé les sources de cette base de données,
dans laquelle j’ai inventé un nouveau pays (Zooland, en hommage à Zoobab, organisateur des
BattleMesh) pour lequel il n’existe aucune restriction au niveau du DFS ou de la puissance d’émission.
Le principal problème avec les cartes Ralink, qui intègre le DFS, vient du fait que les drivers fournis par
le fabricant ne compilent pas toujours lors de la création des images destinées à flasher les cartesmères. Ce problème a été résolu grâce à un coup de pouce du service technique de Ralink.
1.2.
Outils utilisés
SDK Ubiquiti : Ensemble de logiciels permettant de personnaliser l’operating system présent dans les
appareils Ubiquiti. Ce SDK a été utilisé pour implémenter le protocole OLSR et pour incruster un logo
personnalisé dans l’interface de configuration des appareils Ubiquiti
SDK OpenWrt (from trunk) : Ensemble de logiciels permettant de personnaliser l’operating system
OpenWrt, devenu de-facto le standard des operating system basé sur linux pour les appareils de
communication réseau. Ce SDK a été utilisé pour implémenter différents protocoles et pour
personnaliser l’interface utilisateur des appareils montés par nous-même.
Iperf : outil pour mesurer la bande passante et la qualité d'un lien réseau. Ce dernier est délimité par
deux machines sur lesquelles est installé Iperf.
La qualité d'un lien est déterminée principalement par les facteurs suivants:
Latence (temps de réponse ou RTT): peut être mesurée à l'aide d'un Ping.
Gigue ou jitter en anglais (variation de la latence): peut être mesurée par un test Iperf UDP.
Perte de paquet: peut être mesurée avec un test Iperf UDP.
Quant à la bande passante, elle est mesurée par des tests TCP.
Iperf utilise les différentes propriétés de TCP et d'UDP pour fournir des statistiques sur des liens
réseaux.
AirView : analyseur de sceptre développé en langage java par Ubiquiti et implémenté dans leurs
appareils de la gamme M.
1.3. Etat actuel du projet
Actuellement ce projet est toujours en phase de tests et de validation. Des tests grandeur nature
seront réalisés lors du prochain Battle Mesh qui aura lieu à Godarville, du 11 au 14 novembre.
1.4.
Avenir de ce projet & approche commerciale
Les applications commerciales d’un produit tel que celui décrit dans ce mémoire sont aussi variées
qu’infinies. Les projets commerciaux pour lesquels des contrats ont déjà été signés portent
uniquement sur des réseaux de vidéosurveillance urbains pour lesquels des travaux de câblages sont
exclus en raison de coûts prohibitifs.
Grâce à ce produit, il serait aisé de déployer un réseau semblable aux réseaux GSM, permettant à des
clients abonnés de se connecter à internet dans une ville par exemple. Dans ce cas, deux radios
seraient dédiées à la communication entre les appareils dans la bande des 5 GHz et la troisième radio
servirait pour l’accès des clients et serait configurée en 2.4GHz.
Comme nous allons le voir dans les chapitres suivants, un réseau basé sur ce type d’appareils peut
être étendu très facilement et pratiquement sans aucune configuration.
Le coût de production relativement faible de ces appareils permettrait également de déployer
rapidement une version améliorée du réseau citoyen bruxellois ou de fournir des accès internet « last
mile » dans des zones reculées.
2.
Mesh & Wireless
2.1.
Qu’est-ce qu’un réseau Mesh ?
La topologie mesh (terme anglais signifiant maille ou filet), est une topologie de réseau qualifiant les
réseaux (filaires ou non) dont tous les hôtes sont connectés de proche en proche sans hiérarchie
centrale, formant ainsi une structure en forme de filet.
Chaque nœud du réseau communique ainsi avec plusieurs homologues, créant une architecture
maillée. Chacun assure une double fonction : les communications sans fil avec les autres nœuds, ce
qui constitue l'infrastructure réseau, et la desserte de dispositifs clients. Il comporte pour cela des
aptitudes de routage élaborées et des fonctions de point d'accès Wi-Fi.
A l'inverse des réseaux Wi-Fi classiques, nul besoin d'un réseau filaire reliant les points d'accès : pour
un hot spot par exemple, il suffira de relier un ou deux nœuds du réseau sans fil maillé à l'accès
Internet. Avec, à la clé, deux avantages immédiats : des coûts de déploiement réduits et une
architecture plus flexible. Seule une alimentation électrique est requise au niveau de chacun des
nœuds.
Théoriquement, ces derniers n'émettront pas à pleine puissance pour dialoguer entre eux mais se
contenteront de celle requise pour atteindre les nœuds voisins, ce qui permet de limiter la
consommation électrique et d'optimiser l'utilisation des canaux hertziens. Mais, surtout, de cette
architecture résulte une forte tolérance aux pannes, en raison de la redondance inhérente à la
topologie maillée : les communications peuvent être reroutées vers un autre chemin si l'un des
éléments du réseau tombe en panne.
L'existence de chemins redondants permet également de réaliser un équilibrage de charge intelligent
C’est une technologie de rupture comparée aux solutions centralisées classiques sans-fil avec station
de base. Les solutions « Mesh » autorisent un déploiement rapide et simplifié, une grande évolutivité
de la couverture et, de par leur maillage, une forte tolérance aux pannes et aux interférences,
réduisant significativement les coûts d’installation et d’exploitation des réseaux. Ces solutions
reproduisent l'architecture de l'Internet tout en l'optimisant pour le sans-fil.
Schéma de l’équivalent Toulousain du réseau citoyen belge
2.2.
Notions de redondance, de scalability et de load balancing.
2.3.
Protocoles Mesh
Mesh network protocols are being developed in both commercial/proprietary and open source
contexts. In the commercial space, several vendors are now providing mesh networking solutions
based on their own proprietary routing solution. The open source efforts are led by a number of
university and research institutes who aim to develop free-to-use network protocols. The most
commons of these protocols are the Optimized Link State Routing (OLSR), which is set to emerge as
part of the IETF standard and against another open-source routing protocols: Better Approach To
Mobile Ad hoc Networking (B.A.T.M.A.N.), that claims to provide a new and more effective approach
to mesh networking.
2.3.1.OLSR
The OLSR protocol uses a link-state algorithm to proactively determine the most efficient path
between nodes. The network is structured using dynamic Multi-Point Relays (MPRs) that increase the
network data throughput by creating an efficient network routing scheme. This is achieved by
selecting only a subset of neighboring nodes to relay data instead of every node acting as a relay. This
technique minimizes the rebroadcasting contention and the number of control packets required to
establish a routing table. MPRs are elected in such a way that every node can communicate with a
MPR within one hop. The localized network information is shared between MPRs to maintain
network-wide routing paths. This allows every MPR to have a complete routing table while
simultaneously minimizing the number of topology control messages.
2.3.2.B.A.T.M.A.N.
B.A.T.M.A.N. is a proactive routing protocol that offers a fundamentally different approach to route
selection that is more aligned to the minimal resources available in embedded hardware. The first
distinguishing feature is the decentralized knowledge of routing information - no single node has the
routes to all destinations across the network. Instead, each node only perceives and maintains the
general direction toward the destination and relays the data to the best next-hop neighbor
accordingly. Any subsequent relay nodes then use the same mechanism to forward data until the final
destination is reached.
The second significant difference is the path determination algorithm. In order to establish the
general direction toward the destination, B.A.T.M.A.N. uses the principle that better links will provide
faster and more reliable communication. Every node periodically sends out broadcast messages
known as originator messages (OGMs) to inform its neighbors of its existence. The neighbors then
relay this information to
Their own neighbors until each node are aware of all other nodes. Given the unreliable nature of
broadcast transmission, the OGM flooding will not pass efficiently through congested links. Instead,
the best path will be established through links with lower utilization. This algorithm is shown to be
significantly less complex than link-state calculations and has more modest hardware requirements.
2.3.3.Babel
Babel was primarily designed for wireless ad-hoc networks. Because of that, Babel is extremely
robust in the presence of mobility: only under very exceptional situations circumstances will Babel
cause a transient routing loop. (This is unlike OLSR, which will cause transient routing loops just after
a mobility event before the new topology information is flooded throughout the network.)
In its default operation, Babel uses a link quality measurement that is designed for networks using
the IEEE 802.11 MAC. In other words, the paths chosen should be reasonable on any sort of network,
but are particularly suitable for 802.11 networks.
Babel uses history-sensitive route selection to avoid route flapping, the situation in which routers
repeatedly switch between two routes of similar quality.
Babel enjoys fairly fast convergence. Since Babel uses triggered updates and explicit requests for
routing information, it usually converges almost immediately after the link quality measure has
completed. The initial solution is not optimal — after converging to a satisfactory set of routes, Babel
will take its sweet time before optimizing the routing tables. In the presence of heavy packet loss,
converging on an optimal set of routes may take up to a minute or so (with the default update
interval of 30 seconds).
Babel has the following features:
•
it is a distance-vector protocol;
•
it is a proactive protocol, but with adaptative (reactive) features;
•
it senses link quality for computing route metrics using a variant of the ETX algorithm;
•
it uses a feasibility condition that guarantees the absence of loops (the feasibility condition is
taken from EIGRP and is somewhat less strict than the one in AODV);
•
it uses sequence numbers to make old routes feasible again (like DSDV and AODV, but unlike
EIGRP);
•
it speeds up convergence by reactively requesting a new sequence number (like AODV, and to
a certain extent EIGRP, but unlike DSDV);
•
it allows redistributed external routes to be injected into the routing domain at multiple
points (like EIGRP, but unlike DSDV and AODV).
2.3.4.Quel protocole choisir et pourquoi ?
2.4.
Wireless
2.4.1.802.11 a/b/g/n
2.4.2.Matériel disponible sur le marché & choix du matériel utilisé
Il existe sur le marché plusieurs produits répondant aux critères demandés. Deux marques ont
particulièrement retenu notre attention :
•
Luceor, qui a conçu un produit basé sur le protocole OLSR et destiné à des applications
militaires.
Le produit se rapprochant le plus de nos besoins est le Luceor OWR-200N. Il s’agit d’un
routeur sans fil extérieur haute performance, intégrant la technologie mesh OLSR standard,
validée par les armées française et américaine et par l’OTAN. OWR-200N est conçu pour
fournir une connectivité IP haut débit jusqu’à 150 Mbit/s
Dans un déploiement typique, un ou plusieurs OWR-200N peuvent être configurés comme
passerelles vers d’autres réseaux filaires ou sans fil. La flexibilité dans le choix des antennes
permet d’établir des liens de quelques dizaines de mètres à quelques kilomètres.
Grâce au mesh, les ´équipements se connectent automatiquement sans fil avec les produits
de la famille OWR, de proche en proche, d’une façon instantanée et optimisée sans aucune
hiérarchie centrale. Les réseaux maillés qui en résultent sont auto configurés et tolérants aux
pannes et aux interférences.
L’OWR-200N embarque deux interfaces radio, configurables logiciellement en 2,4 GHz ou 5
GHz, avec ou sans mesh.
Dans sa configuration par défaut, les deux cartes radio peuvent être dédiées au backbone
mesh, maintenant le haut débit de bout en bout.
OWR-200N hérite d’OLSR une gestion avancée du voisinage et une diffusion optimisée dans
le réseau. Il utilise donc une très faible bande passante pour gérer la connectivité.
Un outil ouvert, efficace et conforme au standard SNMP (le MeshTool) est d´développé pour
le portefeuille des produits Luceor, s’appuyant sur la nature proactive d’OLSR. Il permet la
découverte instantanée, la visualisation, l’aide à l’installation et l’administration du réseau.
Une interface Web intégrée permet aussi l’administration de l’OWR-200N.
•
Ruckus, qui est utilisé entre autres par Belgacom pour connecter leurs B-Box et les décodeurs
HD dans des habitations où le câblage est trop difficile ou impossible.
Les produits Ruckus communiquent à l’aide d’un protocole mesh propriétaire et intègrent
une notion supplémentaire : le beamforming.
Pour comprendre ce qu’est le beamforming, Il faut savoir que l’énergie des transmissions
radio est similaire à l’énergie lumineuse.
Si vous utilisez une lampe à bulbe traditionnelle, l’énergie est diffusée dans toutes les
directions et diminue rapidement avec la distance.
Si l’énergie de la même ampoule est dirigée et concentrée dans une direction définie,
l’énergie voyagera plus loin dans la direction donnée.
Les antennes omnidirectionnelles standard fonctionnent un peu comme une ampoule
normale. Grâce à sa technique de diversité d’antennes, Ruckus permet d’envoyer le signal
dans la direction où se situe le client. Cela permet de réduire significativement les pertes
d’énergie et les perturbations dues à la réflexion.
Les antennes omnidirectionnelles ne peuvent pas contrôler les phases des signaux ni la réflexion.
Grâce au beamforming, les effets négatifs dus à la réflexion sont convertis en effets bénéfiques car la
réflexion des ondes est prise en compte et le signal réfléchi est modulé de manière à amplifier le
signal direct.
Voici une vue d’une antenne Ruckus. Pour comprendre comment fonctionne le
beamforming, il faut savoir que chaque plaque qu’on voit sur cette photo est une miniantenne directionnelle.
Imaginons une boussole indiquant les quatre points cardinaux. Si le signal doit être émis suivant un
axe Sud-Nord, l’antenne Sud émet la première impulsion, lorsque cette impulsion arrive à la verticale
de l’antenne Nord, l’antenne émet la même impulsion, amplifiant de ce fait l’impulsion émise par
l’antenne Sud et lui imposant la direction voulue. En travaillant avec un système composé de neuf
antennes, l’énergie peut être dirigée dans toutes les directions avec précision.
Pour savoir dans quelle direction se situe le client, lorsque la station reçoit une impulsion de celui-ci,
les antennes situées dans un axe recevront plus d’énergie que les autres, ce qui permet de
déterminer où se trouve le client dans l’espace.
Ces schémas sont issus de la documentation technique de Ruckus et montrent clairement les
avantages du beamforming. On peut se rendre compte que les paquets sont transmis à plus grande
vitesse dans des zones plus étendues.
Après avoir testé ce matériel (Luceor nous gracieusement prêté plusieurs OWR-200N) et étudié les
couts des différentes solutions, il s’est avéré que les budgets nécessaires au déploiement d’un réseau
étaient prohibitifs. Pour info, voici un aperçu des prix pratiquées. Je précise que ce sont les prix
distributeurs.
Un nœud OWR-200N débridé et permettant une vitesse de 150 Mbits/sec coute 6.000€ HTVA chez
Luceor
Un Access Point Ruckus outdoor coûte 1999 € HTVA auxquels il faut ajouter un contrôleur. Le plus
petit modèle, permettant de gérer jusqu’à 25 Access Points coûte 6000€ HTVA.
J’ai dû alors explorer une autre solution : utiliser du matériel permettant l’utilisation d’un firmware
personnalisé.
Connaissant déjà la marque et ayant une bonne expérience quant à sa fiabilité, j’ai étudié la
possibilité d’utiliser du matériel Ubiquiti.
Trois modèles ont été retenus :
•
NanoStation M5
Fonctionne uniquement dans la bande des 5 GHz
Basé sur le chipset Atheros 9220
Deux modèles différents : l’un avec deux antennes 16 Dbi. L’autre avec deux antennes de 11 Dbi
Antennes à double polarisation
Deux interfaces Ethernet avec PoE pass-through
Largeur du faisceau hertzien : Polarisation verticale : 41° Polarisation horizontale : 43° Elévation : 15°
Résultat d’un test de vitesse avec deux NanoStation situés à une distance de 600m
Photo d’une NanoStation démontée. On peut voir sur celle de droite les deux antennes.
•
Rocket M5
e Rocket M5 possède les mêmes caractéristiques que le NanoStation M5 sauf qu’il possède deux
connecteurs RSMA. Il a été conçu pour être intégré à toutes les antennes sectorielles ou
directionnelles Ubiquiti.
•
NanoBridge M5.
Les modèles NanoBridge M5 sont intéressants à plus d’un titre : l’antenne est intégrée ainsi que le
radio émetteur pour former une antenne parabolique.
Le faisceau hertzien émis par ce type d’antenne est quasiment linéaire, ce qui lui permet de ne
presque pas être influencé par les problèmes dus à ce que l’on appelle l’effet de Fresnel.
Largeur du faisceau hertzien : Polarisation horizontale, verticale et élévation : 6°
Puissance de l’antenne : 22 Dbi
Avec des prix variant entre 70 et 100€ HTVA, le matériel Ubiquiti semblait correspondre au cahier des
charges, d’autant plus que les autrichiens du groupe funkfeuer ont écrit un patch permettant
d’intégrer le protocole OLSR au firmware Ubiquiti. Ces appareils sont basés sur les chipset Atheros, ce
qui nous a posé des problèmes avec le module DFS (voir chapitre 1.2).
Néanmoins, cette solution a quelques limites : les appareils Ubiquiti n’ont qu’une seule radio et une
seule interface réseau 10/100 (les NanoStation en a deux qui sont bridgées).
J’ai donc effectué quelques recherches pour trouver une autre solution.
Il existe sur le marché des cartes possédant des slots mini-PCI sur lesquels on peut connecter des
cartes WIFI. J’ai reçu un budget pour acheter quelques échantillons et effectuer des tests.
J’ai trouvé quatre marques qui fabriquent ce genre de cartes : Compex, Mikrotik, Ralink et Ubiquiti
•
Compex fabrique une carte possédant deux slots mini-PCI et des cartes radio basées sur le
chipset Atheros. Ce fabricant propose leur version d’OpenWrt intégrant un driver pour les
cartes Mini-PCI intégrant d’après eux un module DFS (Dynamic Frequency Selection). Ce
driver présente toutefois un gros inconvénient : il ne supporte pas le mode ad-hoc. De plus,
après un examen visuel, ces carte ne semblent pas de qualité suffisante pour fonctionner
dans des environnements exigeants : les soudures ne sont pas bien réalisées, la carte-mère
ne possède pas de vernis de protection, contrairement aux autres cartes testées et il faut
forcer pour installer les deux cartes radio superposées.
Caractéristiques des cartes-mères COMPEX WP543A-HV
o
o
o
o
o
o
o
CPU Atheros AR7161 680 MHz
8 Mb Flash
32 Mb RAM
2 slots Mini-PCI
Interface réseau 10/100
802.11af PoE
Cout +- 60 €
Les modèles de cartes radio testés sont toutes les deux basées sur le chipset Atheros AR9220.
La carte bleue possède une protection ESD supérieure.
•
Mikrotik a été éliminé d’emblée en raison du coût plus élevé que les autres à performances
égales. De plus, je me suis documenté sur plusieurs forums et apparemment, leurs cartes ne
sont pas complètement compatibles avec les systèmes d’exploitation basés sur Linux.
•
Ralink a lancé depuis le mois de septembre une nouvelle ligne de cartes-mères. Je possède
deux échantillons et leur propre SDK. Je n’ai pas encore testé celui-ci mais d’après les
informations que j’ai eues auprès de leur support technique, les drivers des cartes radio sont
implémentés. Ces cartes semblent de bonne facture et possèdent les caractéristiques
suivantes :
o
o
o
o
o
o
o
o
CPU Atheros AR7161 680 MHz
8 Mb Flash
64 Mb RAM
3 slots Mini-PCI
2 slots USB
1+4 interfaces réseau 10/100/1000
Alimentation 12V-18V DC (802.11af encore au stade expérimental)
Cout +- 160$
•
Ubiquiti fabrique aussi des cartes-mères possédant également trois slots mini-PCI et des
interfaces réseau en gigabit : le modèle RouterStation PRO. Ces cartes offrent le meilleur
rapport qualité-prix par rapport à tout le matériel que j’ai eu l’occasion de tester : leur surface
est vernie et est très bien durcie, le niveau de finition est exemplaire.
Voici les caractéristiques de ces cartes :
o
o
o
o
o
o
o
o
o
o
CPU Atheros AR7161 680 MHz
16 Mb Flash
128 Mb RAM
3 slots Mini-PCI
1 slot USB
1 slot pour carte SD
1 interface DB9 (série)
1+3 interfaces réseau 10/100/1000
Alimentation 802.11af
Cout +- 80$
Cette photo montre une carte RouterStation PRO montée dans un boitier en plastique « maison » et
utilisée pour les tests. Une carte radio Mikrotik basée sur le chipset Atheros et une carte Ralink y sont
installées.
Au niveau des cartes WIFI, deux constructeurs de chipsets sont utilisables pour ce projet :
•
Atheros, qui possède le plus de parts de marché dans la construction de systèmes WIFI en
802.11n grâce notamment aux chipsets de la famille ath9k.
•
Ralink, dont la production est plus confidentielle qui fabrique des cartes WIFI ayant des
caractéristiques similaires aux cartes Atheros. Ralink a dans sa gamme un produit très
intéressant et qui sera utilisé pour ce projet : il s’agit d’une carte radio mini-PCI possédant son
propre CPU et sa propre mémoire RAM dédiés uniquement aux transmissions radio, et ce
faisant déchargeant de manière significative le CPU et la RAM de la carte-mère. Cette carte
fonctionne en 2.4 GHz ou en 5 GHz et est compatible avec la norme 802.11n permettant des
vitesses de transmission de près de 200 Mbits/sec
Il existe d’autres fabricants, comme Intel, mais leurs drivers ne sont pas toujours compatibles avec le
système d’exploitation qui sera utilisé.
Pour conclure ce chapitre, nous allons travailler avec le matériel suivant :
•
•
•
cartes-mères Ubiquiti et cartes radio Ralink WMIR-270N pour le matériel actif
Boitiers sur mesure (voir chapitre suivant)
Connecteurs type-N femelle étanches pour les connexions des antennes
•
•
Passe-câble UTP avec système de presse-étoupe étanches
Antennes omnidirectionnelles haute puissance dans le cas où les nœuds sont très proches
(voir photo)
Antennes directionnelles ou sectorielles pour les plus longues distances.
•
2.5.
Aspects pratiques
Des boitiers étanches sur mesure doivent être fabriqués. La construction de ces boitiers est confiée à
une société Hollandaise basée à Breda.
Afin de garantir une solidité et une étanchéité maximales, les boitiers seront réalisés en aluminium
taillé dans la masse. Le couvercle aura une double encoche et sera muni d’un o-ring.
J’ai moi-même imaginé le design de ces boitiers et un premier prototype a déjà été produit. Le
modèle définitif devrait être disponible vers le 25 septembre. Il possède les caractéristiques initiales à
l’exception des passages de câble UTP, qui ne seront plus au nombre de cinq et qui seront placés sur
le côté des boitiers.
Sur la page suivante, le plan initial des boitiers est reproduit.
Obj100
2.6.
Design de réseaux Mesh Wireless. Avantages et inconvénients.
Il m’a été demandé au cours des mois précédents d’effectuer une étude de design pour deux réseaux
mesh : l’un situé à l’axis parc de Mont-Saint-Guibert, l’autre pour un projet à Karachi, ville côtière du
Pakistan.
Axis Parc.
Schéma 1
Schéma 2
Karachi
Schéma 3
Schéma 3
3.
Operating system
3.1.
3.2.
3.3.
3.4.
3.5.
4.
Description
Choix de l’operating system
Installation et utilisation d’OpenWrt pour personnaliser l’operating
system
Fichiers de configuration d’OpenWrt
Résultats
Annexes
4.1.
4.2.
Bibliographie
Remerciements
5.
Annexes
5.1.
Bibliographie
http://fr.wikipedia.org
http://www.nbs-system.com/blog/howto-iptables/
http://ebtables.sourceforge.net/
http://lartc.org/howto/lartc.cookbook.fullnat.intro.html
http://l7-filter.sourceforge.net/
http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/index.html
5.2.
Remerciements
Je tiens à remercier Philippe De Wolf, mon patron qui m’a permis de réaliser une partie de ce TFE
pendant mes heures de travail et pour son soutien tout au long du développement de cette
solution.
Je remercie également l’IFAPME et tous les formateurs qui m’ont dispensé des cours pour la
qualité de ceux-ci.
Un tout grand merci à Marie de MC Plan pour le travail d’impression et de reliure de ce
document.