WIFI-Mesh Probleme - Firmware?


#1

Hallo zusammen,
ich habe zwei Nodes so konfiguriert, dass sie im WIFI-Netz meshen. Einer (WR1043N) soll dabei die VPN-Verbindung zum Gateway aufbauen. Der andere (WR841N) wirft am LAN dann Freifunk aus für kabelgebundene Devices.
Nach ein paar Tagen fiel ziemlich genau gegen Mitternacht der erste “entfernte” Node WR841N aus. Er verbindete sich nicht mehr ins Mesh des VPN Nodes. Der jedoch funktionierte augenscheinlich tadellos.
Ich habe an einen Hardwareausfall gedacht und einen weiteren Node (CPE 210) aus der Kiste geholt und ihn für WIFI-Mesh konfiguriert. Auch dieser ist mir gestern nacht fast genau gegen 0 Uhr ausgefallen.

WR1043N(VPN-Node): https://karte.freifunk-muensterland.de/map/#!n:ac84c62957d2
WR841N (1. Ausfall): https://karte.freifunk-muensterland.de/map/#!n:e894f6cda9a6
CPE 210 (2. Ausfall) heute nacht: https://karte.freifunk-muensterland.de/map/#!n:18d6c7e5d0dc
Alles gleiche (aktuelle) Firmware, alle gleiche Domain.

Restart aller Nodes half erstmal nicht. Die Verbindung zum 1043er (und damit zum FF-Netz) kommt auch nach langer Wartezeit nicht zustande.
Doch nachdem ich den 841er ebenfalls per VPN angeschlossen habe, fällt auf dass sich dieser mit dem CPE nun eine Wolke teilt und der 1043 derjenige ist, der von diesem Mesh nichts (mehr) wissen will.

Habt ihr eine Idee woher diese kuriosität kommen kann? Evtl. ein Firmwareproblem oder eine art Blacklist auf dem 1043er? Auffällig ist ja der Ausfall stets gegen Mitternacht - ohne Last BTW. Im Log des 1043er ist auch nichts auffälliges zu finden.
Ich lasse die Konstellation 841+CPE erstmal laufen und warte ab, ob diese beiden sich auch verlieren…
Danke und Gruß
Heerde


Heimnetz mit Freifunk-Uplink
#2

Hallo @heerde,

mir ist aufgefallen das die Knoten sich nicht in der gleichen Domäne befinden. Das liegt daran, das unser Node-Hierarchie-System den 841er und die CPE in eine andere Domäne geschoben hat. Ich werde sie wieder in die Domäne wie den 1043er zeihen.
Am besten ist, wenn du die Location auf den Knoten einstellst. Dann wird das Script auch nicht mehr meckern und den Knoten nicht umziehen. Genauere Details kann der @P4w erläutern.

Auszug aus dem File (/etc/nginx/sites-available/default.d/UmzugInDomaene03)

2a03:2260:115:3400:9ade:d0ff:fe30:1a66 0; #BW-Gluon-Dom01 -> im Exil wg. Netzstörungen
2a03:2260:115:200:ea94:f6ff:fe63:d02 1; #Banane-02
2a03:2260:115:200:ea94:f6ff:fe6d:cda 1; #Banane-03
#2a03:2260:115:100:223:cdff:fe20:bb26 1; #freifunk-fever
#2a03:2260:115:100:ea94:f6ff:fe4b:3afa 1; #freifunk-mschae
#2a03:2260:115:200:ee08:6bff:fef8:bda 1; #www.ev-jugendhilfe.de-65
2a03:2260:115:100:ea94:f6ff:fecd:a9a6 1; #heerde-freifunke894f6cda9a6
2a03:2260:115:100:1ad6:c7ff:fee5:d0dc 1; #heerde-beam

#3

Besten Dank @RobWei!
Dank deiner magischen Hände sind alle Knoten nun in derselben Wolke.
Ursprünglich waren die Knoten tatsächlich in unterschiedlichen Domänen. Ich dachte, mit einem FW-Update auf die gleiche Domäne wäre es getan, aber scheinbar hat da das regelmäßige Housekeeping zugeschlagen.
Ich werde die Koordinaten setzen und bedanke mich sehr für die Hilfe!
Gruß
Heerde


#4

Hallo,
@RobWei: Es war korrekt, dass die Router zum Umzug eingestellt waren. Habe ich persönlich gemacht. Der dritte hätte folgen sollen, hat dies aber nicht getan. Domäne 1 war die falsche Domäne, außer die Heerdestraße ist südlich der Promenade :slight_smile: . Domäne 3 ist korrekt, auch zum (zukünftigen) Meshen mit anderen Routern in der Gegend.

@heerde: Zum Nachvollziehen bitte eine kurze Info, wie die Router angeschlossen sind.
Ich habe verstanden, dass heerde-beam mit den beiden anderen per WLan meshed (aktuell über heerde-tripod =TP-LINK TL-WR1043N v5)
heerde-freifunke894f6cda9a6 (TP-Link TL-WR841N/ND v9) meshed auch über aktuell über heerde-tripod =TP-LINK TL-WR1043N v5.
Diese beiden AccessPoints müssen erst in Domäne 3 umgezogen werden. Das bedeuted einen Ausfall der beiden nach dem Umzug, dann rückt heerde-tripod =TP-LINK TL-WR1043N v5 in Domäne 3 nach und alle sind wieder online.
Bitte um kurzes Feedback, ob ich die Anschlußreihenfolge so korrekt wiedergegeben habe. Dann könnten wir das bereinigen.
Danke
P4w


#5

Die drei APs sind heute nachmittag erfolgreich in Domäne 3 gezogen.


#6

Hallo P4w,
danke für Deine Arbeit. Allerdings sind die 841n und CPE-Nodes nicht hinterher gekommen und waren wieder offline. Ich habe die Dom3 Firmware neu geflashed und nun ist alles OK.
Eine Frage noch: Wenn diese oder andere Knoten mal “umziehen”, also physikalisch in eine andere Domäne gebracht werden, was muss der Anwender dann tun? Wie mir scheint reicht das flashen der neuen Domäne nicht aus, denn es kann wie in meinem Fall passieren dass eure Scripte das wieder zurückdrehen - oder? Könnt ihr dazu mal einen Wiki-Eintrag machen?
Gruß
Heerde


#7

Doch das reicht in der Regel aus. In diesem Fall haben wir warscheinlich nur vergessen deine Knoten wieder aus der liste zu entfernen. In dem Fall das Router zum Umzug eingetragen sind hast du recht und der Knoten würde sich immer wieder die Umzugsfirmware ziehen. Das ist aber wie gesagt nicht der Regelfall da wir Umzüge eigentlich nur unter Aufsicht machen um Probleme auszuschließen.


#8

hallo @P4w, @corny456 und @RobWei,
die zwei Nodes heerde-beam und heerde-freifunke894f6cda9a6 haben gestern nacht wieder in die Domäne 1 zurückgewechselt.
Könnt ihr bitte checken, ob es noch irgendwelche Einträge in Listen gibt, die dies veranlassen - und die Knoten dort entfernen?
Um sicher zu gehen, dass alle Nodes erreichbar sind, habe ich sie per VPN angeschlossen.
BTW: Kann ich die Änderung der Domäne auch direkt per SSH ändern oder muss ich dazu stets eine Firmware flashen?
Danke und Gruß
Heerde


#9

Jo die hatte wohl keiner von uns aus der Liste gelöscht… :man_facepalming: ich hab sie aus der Liste für Dom01 rausgenommen und in Die für Dom03 eingetragen. Sie sollten sich also binnen der nächsten 1-2 Stunden wieder in Dom03 befinden. Sorry für den umstand…

Aktuell geht das nur durch flashen einer anderen Firmware. Aber auch das kann man per SSH machen…

cd /tmp
wget -O neuefirmware.bin http://firmware.ffmsl.de/[PFAD ZUR FIRMWARE]
sysupgrade neuefirmware.bin

Tagesordnung 16.01.2019
#10

Dieses Thema wurde automatisch 3 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.