Le Net du Kermeur

Cette année à Saint Bresson dans le Gard du 1er au 4 Mai, à l’initiative de Montpelliers Wireless et de la commune de Saint Bresson.

• Le vendredi matin les cartes Routerboard, avec la complicité d’Eric d’Ambassade Sud Est (département de l’Ain) : les possibilités d’extensions radio et de choix du firmware (RouterOS, Openwrt).
• Le samedi matin un bref exposé sur les possibilités trop souvent méconnues de la commande Unix screen, permettant entre autres de manipuler les liens Wifi sans prendre trop de risques.

La galerie photos de ces rencontres.

Depuis quelques jours les liaisons sont perturbées sans raison apparente, il semble que l’Ap Routerboard soit en cause, après 5 semaines d’uptime. En effet impossible de la redémarrer à distance par un /system reboot.

Relance par coupure électrique.

Le Net du Kermeur était présent aux RBLL (Rencontres Bretonnes du Logiciel Libre) à Saint-Brieuc ce week-end du 19-20 Avril 2008.

Il y présentait, le samedi en fin d’après-midi, l’apport des logiciels libres dans les réseaux Wifi ruraux, autant dire toute l’infrastructure réseau.
L’accent a été mis sur les points qui ont facilité l’émergence de ce type de réseaux, en particulier les firmwares à base Linux (DD-WRT, OpenWRT, Freifunk, etc …)
Quelques photos dûes au président de Finix :

L’abonné sur Wrt147 n’a plus d’accès internet depuis deux jours (le 10 à 17H00 d’après les courbes de trafic de Cacti).
Carte réseau du micro de l’abonné HS, le routeur est ok.

Une mauvaise surprise, le portable Apple Ibook G4 qui nous sert en maintenance depuis maintenant bientôt trois ans, n’a pas voulu démarrer à cette occasion. Disque dur HS.

Depuis la bascule de samedi.
Les renvois de ports avaient bien été faits mais pas la mise à jour des règles de sécurité (onglet Firewall, Rules des passerelles M0n0wall et pfSense).
Rétablies ce matin, soit quatre jours de coupure.

Le routeur Wrt191 à Kergorre coupé depuis la mise en service de la nouvelle AP au Kermeur.
Relancé en passant le wl0_gmode de 0 à 1.

L’anomalie provient en fait de la borne sous RouterOS : lorsque l’on règle le rate-set à configured, les clients ne peuvent communiquer en mode 11b, même si les rates 11b sont dans la liste; il faut mettre rate-set=default.

Du lundi 24 à 19H45 au mardi 25 à 9H30 suite à une mauvaise manipulation de l’injection POE.
Quatre abonnés impactés.
A noter qu’ils auraient tout de même été coupés de 1H à 6H du matin (délestage de l’alimentation solaire).

Ce lundi de Pâques à 7H du matin.
Intervention sur place, le routeur reçoit bien le signal de l’AP mais n’émet pas,  relance par simple modification du wl0_gmode de 0 à 1; pas bien compris le pourquoi, émetteur 11b HS ?
Rétablissement à 12H00, 10 abonnés concernés.

Après 17 mois de bons et loyaux services, l’AP Routerboard RB532 (architecture Mips) sous Openwrt est déposée pour mise à jour du soft.

Elle laisse la place à une Routerboard RB333 (architecture PowerPC) sous RouterOS, équipée de deux cartes radios mini-pci.

Le coupleur des antennes à fentes est supprimé, chaque antenne a sa propre radio; ceci pour assurer un trafic plus fluide; les paramètres radio de 25 abonnés ont du être modifiés en conséquence.
Le bloc alimentation, d’un ancien micro portable, est conservé (18,1V mesuré par la commande /system health print du RouterOS).
Début de la bascule à 10H00, rétablissement du réseau vers 18H00 après une belle pagaille due à des erreurs de paramétrage des leases Dhcp.

Les premières mesures relevées dans Cacti, montre une répartition correcte de la charge de trafic entre les deux canaux.

D’autre part, les relevés de mesures RSSI alimentant Cacti, se font maintenant en SNMP (au lieu de SSH sous Openwrt).

Coupures par intermittence de la passerelle principale, en pfSense, de 5H du matin à 10H30.
Passage en secours sur la passerelle M0n0wall puis rétablissement de la passerelle principale à 12H00.

Le meilleur indicateur de ce dysfonctionnement reste le graphique du suivi des logs des connexions, où il apparaît clairement qu’aucune donnée ne parvenait plus du pfSense.

Mise en place d’un script de bascule auto sur l’AP principale, en cas de coupure d’une des passerelles.

Une analyse de la table des connexions (par pftop) montre que celle-ci est encombrée par des connexions Peer2Peer, et que les coupures ont pour origine plus que probable une saturation de cette table (soit plus de 10000 connexions, paramètre par défaut).

Règlé le paramètre ‘Firewall Optimization Options’ du pfSense sur agressive pour enrayer le phénomène.