Discussion Utilisateur:Grompf
Un article de Toulouse Sans Fil, un réseau wifi libre sur Toulouse.
| Cette page est utilisée en tant que bloc notes par certains contributeurs. Elle n'est donc pas finalisée et le contenu qui y est présent ne reflète pas forcément la politique de l'association. |
Edito
Grompf 24 mai 2006 à 14:08 (CEST) -- Grompf : Effort de dépollution de la zone publique sur le Wiki. Transfert des notes personnelles //ailleurs//. Tout n'était pas propre, et parfois avait même un sous-entendu subversif.
WIKI : liste des pages et de l'arborescence que je monitore et ai à finir
- specifications
- specification openvpn
- client et serveur SSH
- plugin http info
- serveur http informatif
- Installation simplifiée pour OpenBSD
WIKI : idées à creuser
- Synchro / base de temps : implanter un service ntpd léger de type openntpd ouvert sur toutes les machines appartenant au réseau TSF. La précision n'apasbesoind'être démoniaque, mais unestabilité de la base de temps du réseau est nécessaire.
- GPS : Si le noeud est équipé d'un GPS, prévoir la synchro de celui-ci sur le GPS,
- noeud simple : Sans GPS, prévoir un script récupérant les adresses des relais sélectionnés par OLSR pour modifier le fichier /etc/ntpd.conf et relancer le daemon openntpd. Chaque changement de relais fera l'objet d'une mise à jour du fichier de configuration, en tenant compte d'une latence consequente pour éviter les changement de relais trop nombreux.
BLOG-Note
Perte de perf sur un noeud central pointé par des antennes directionnelles sans vue croisée.
(Note pour Ouin2 et Drien suite à la réunion du 04/12/2006)
Solution proposée
Pour utiliser une antenne directionnelle (i.e. parabole ou cavité) comme une omni et non pas en point à point comme il le faudrait, il faut desactiver le protocole RTS/CTS des stations distantes qui ne se voient pas tout en etant dans la meme zone SS et laisser le protocole RTS/CTS activé sur la station "commune" car les stations distantes se doivent de repondre à une transaction CTS/RTS as per specs 802.11, 802.11b, et 802.11g (que je viens de me peler).
Raison
La zone de contention est limité au recouvrement des zones de Fresnel autour de la station "commune". Et donc toute station en fond de lien qui émet un RTS va provoquer la reception sur toutes les stations d'un CTS provenant de la station "commune" sans pour autant pouvoir determiner à quelque station est destiné le CTS. D'ou perturbation et mise en faute du systeme de contention amélioré par le protocole CTS/RTS.
(Idée originale : Drien).
Implémentation
Prévoir l'ajout d'une variable SHARED_LONG_SHOT_TARGET={YES,NO} qui d'un coup de SED va modifier le fichier de configuration WiFi pour désactiver ou non le mode le DCF type RTS/CTS pour laisser uniquement la contention virtuelle et la contention physique activées. Une autre solution est de laisser le script de configuration WiFi s'en débrouiller en gérant dynamiquement les commandes associées au reboot (ce qui à le mérite de ne pas activer de flashage comme pour la solution SED).
Note
Il y a quand meme un truc qui me dérange et qui me gratouille... sans que je puisse sentir de quoi il s'agit.
Priorité du routage VPN / OLSR.
(Note pour Ouin2 et Drien suite à la réunion du 04/12/2006)
Solution proposée
Se recentrer sur nos bases et la specs initiale de l'introduction du VPN.
Raison
Le VPN doit être une mesure d'exception parmis tout le routage OLSR et ne doit pas être activé systématiquement dans la configuration par défaut.
Implémentation
Prevoir une variable ISOLATED_NODE={YES,NO} qui d'un coup de SED ajoute ou retire l'interface tap du fichier de configuration d'OLSR durant le process de boot. (n.d.g. : penser à lire d'abord le fichier pour le pas aller ecrire à chaque fois dans la flash des que le node reboote.) Prevoir aussi une variable WIRED_NODE={YES,NO} pour activer ou non l'interface tap (et donc avoir un VPN en lancement conditionnel). Cette variable WIRED_NODE à NO doit inhiber tout effet de la variable ISOLATED_NODE si cette derniere est à YES. le VPN par contre peut permetre d'avoir une liaison de debug et fournir une information de keep-alive par simple connection au serveur VPN de TSF. Sans l'activation de la variable ISOLATED_NODE, le noeud reste accessible via son adresse sur le VPN.
Voir plus loin, la note d'organisation sur les plantages d'OLSR quand à l'oragnisation du système.
corrolaire à ce qui vient d'être dit au dessus
(Note pour Ouin2 et Drien suite à la réunion du 04/12/2006)
Solution proposée
Il va falloir mettre en place l'affectation d'adresse fixe sur le VPN en fonction de l'authentification de celui qui se connecte.
Raison
Cela va vite être le Bronx sans avoir d'adresses fixes...
Implémentation
A faire. Voir doc OpenVPN.
Proposition de reglage pour ntp
(Note pour Ouin2 et Drien suite à la réunion du 04/12/2006)
Solution proposée
Utiliser les relais selectionnés par OLSR comme serveurs sources. Attention au changement de relais en live via OLSR.
Raison
Il faut trouver le bon serveur pour se synchroniser.
Implementation
A voir.
Proposition de reglage pour ntp
(Note pour Ouin2 et Drien suite à la réunion du 04/12/2006)
Solution proposée
Voir si OLSR ou un plugin associé pour la declaration de service permet d'annoncer le n° de strate des serveurs ntpd du voisinage et donc de selectionner le ou les serveurs de strates les plus faibles. Afin de donner la priorité au noeud voisin disposant d'un GPS (strate 1) ou d'un DCF-77 (strate 1) et inhiber les synchros externes si le noeud local est déjà équipe d'un ntp strate 1.
Raison
Il faut trouver le bon serveur pour se synchroniser.
Implementation
Concernant l'inhibition et la déclaration d'un serveur ntp local de strate 1, prévoir une variable TIME_STRATUM1={YES,NO} qui permetre de modifier au boot si cela n'est pas déja fait le fichier de configuration du ntp daemon ntp pour garder une synchro locale sur le GPS ou le DCF-77 local et ne pas se synchroniser ailleurs. Cette variable pourra ensuite faire l'objet d'une publication de service comme serveur préférentiel pour les autres membres du réseau.
Pour le reste de l'implémentation : à voir.
Paliatif à la RAZ de l'heure et de la date d'un node OpenWRT
(Note pour Grompf suite à la réunion du 04/12/2006)
Solution proposée
Voir si il est possible d'ajouter une horloge RTC avec un quartz horloger correct.
Rappel de moi pour moi : les montres sont stables car à température constante (37°) ; voir si un thermostatage du quartz est raisonable.
Raison
Il n'y a pas de RTC à board, la synchro initiale se base sur un WRT vierge.
Implementation
A voir.
Sécurité (re)flashage et paramétrages
(Note pour Ouin2 et Drien suite à la réunion du 04/12/2006)
Solution proposée
Voir si avant reflashage il ne serait pas interessant de récuperer la configuration actuelle d'un WRT pour la stocker quelque part.
Raison
Il y a visiblement un hic quelque part avec les paramètres initiaux d'un WRT TSF.
Implémentation
A voir.
Plantage systématique de certaines versions d'OLSR
(Note pour Ouin2, Drien, & Grompf suite à la réunion du 04/12/2006)
Solution proposée
- Prévoir une surveillance du daemon OLSR a formaliser proprement.
- Modifier les fichiers de lancements d'OLSR et du VPN.
Raison
Apparament certaines versions sur WRT (MIPS) plantent relativement reguleierement dans des conditions a priori identiques mains encore non identifiées.
Il semble aussi que OLSR plante si une interface listée dans les interfaces utilisées par OLSR bagotte entre les états up et down (exemple : ifconfig tap up / ifconfig tap down). (source : liste de developement d'OLSR).
Implementation
Utiliser deux fichiers de configuration differents pour OLSR (avec ou sans VPN). Lancer d'abord OLSR sans liaison VPN puis lancer le VPN en fonction de la variable WIRED_NODE={YES,NO} pour laisser ou non le daemon VPN piloter les relances et les reconfigurations d'OLSR en fonction de la variable ISOLATED_NODE={YES,NO}. L'usage d'un jeu de deux fichiers de configuration pour OLSR devrait etre suffisant afin de ne pas réecrire dans la flash a tout bout de champ.
Matériel manquant sur le WRT
(Note pour Grompf suite à la réunion du 04/12/2006)
Solution proposée
Prévoir un module externe pour WRT présentant les fonctions suivantes : WTDG, Alim, Ports RS232, RTC, Protection JTAG, Temperature, LCD, Bus local.
Raison
Ca manque...
Implementation
A voir.