Nö. Zu spät. Ist schon überall drauf … Da hilft nur noch die Flucht nach vorn … Aber wie? Mesh off-on, wenn kein Gatway in Sicht?
1 „Gefällt mir“
Was die Komplexität der Änderungen von respondd angeht: Hier, läuft. Und das Problem, das ich noch habe, sollte auch mit der alten Variante bestanden haben. Ich begrüße es sogar, dass das Teil in C geschrieben wurde.
bzgl. Tunneldigger: kann ich nichts zu sagen. Aber dann muss man das halt fixen, ist imho kein Argument weiterhin veraltete Software zu verwenden. Wenn es bei uns Berichte/Szenarien gibt, unter denen es Probleme gibt, kann ich mich gerne da mal reinfuchsen.
Ich sehe da kein Problem drin. Die Pakete haben wir angepasst und die Sache der detailierteren Statuspage haben wir ausführlich besprochen und veröffentlicht. Ich sehe eher ein Problem in der aktivierung beider Meshprotokolle (ibss und mesh) gleichzeitig, da dadurch die load doch etwas nach oben geht. Die 841er scheinen sich darüber nichtso sehr zu freuen. 
Habe deswegen auf einem 841er in Ennigerloh das ibss abgeschaltet.
Ansonsten ist die no Gateway-Firmware prinzipiell vorhanden, wurde aber nicht ausgerollt, da einige Bedenken wegen der Syntax “kein-Internet” hatten. Siehe in diesem Branch.
Ich empfehle auch das ibss abzustellen. Die Frage ist, wie stabil 802.11s jetzt ist, wenn min. zwei Knoten die Verbindung nicht aufgebaut bekommen.
In Summe sind meine praktischen Erfahrungen mit 2016.1 und 802.11s gut. Bleibt eigentlich nur das mir bisher nicht erklärliche Phänomen, dass die Meshlinks manchmal “einschlafen”. Laut 11s-Interface sind sie dann inaktiv und die TQ wird mit < 10 % angegeben. Ich habe auch keine Ahnung, wie ich das sinnvoll diagnostizieren könnte, da laut iw mesh0 station dump alles in Ordnung ist.
Vgl. auch hier https://forum.freifunk.net/t/ieee-802-11s-und-das-hybrid-wireless-mesh-protocol/6907/10?u=jotzt
Bzgl. ds weiteren debuggings:
Ich habe ja an einem Skript für erweiterte Knotenstatistiken gearbeitet. Beispielhaft findet ihr die Daten hier. Dort werden auch einige Daten zu batman- und wifi-Nachbarn erfasst. Damit könnte man herausfinden, ob es eine zeitliche Regelmäßigkeit gibt oder das Problem beispielsweise auftritt, wenn die TQ unter einen bestimmten Wert sinkt…
Leider klappt der erforderliche Firmware-Bau derzeit nicht ohne Weiteres. Wenn ihr mir sagt, wo eure aktuelle site-Config liegt, baue ich euch aber gerne die passende Firmware. Außerdem müsste @void noch das graphite fixen, damit die Daten nicht innerhalb kurzer Zeit verschwinden.
1 „Gefällt mir“
Falls Bedarf besteht, kann ich mein Mini-Mesh mit 4 Knoten zum Testen anbieten. Die verbinden sich bisher allerdings problemlos mit 802.11s. Kann da gerne eine spezielle Debug-Version oder wasauchimmer aufspielen, ohne dass es sehr schlimm wäre, wenn da mal etwas nicht so gut funktioniert.
Ich werde einen “Debug”-Modus in mein Script einbauen. In den ich dann auch einfach die Knoten-ID eintragen kann und dann die Statistiken gespeichert werden, so brauchen wir nicht auf eine angepasste Firmware warten. Also wer Interesse hat, schreibt mir einfach die IDs seiner Knoten. 
2 „Gefällt mir“
Das sind meine Knoten
e894f678cb08
e894f629db96
60e327c6ca7c
60e327c716fc
Habe Interesse beim Debugging zu helfen und auch allgemein an Statistik. Leider sind die Knoten nur mäßig frequentiert… Mike
Ich denke, ich sollte jetzt mal so langsam das ibss-mesh abstellen. Was denkt ihr? Im ersten lauf würde ich es nur abstellen und in zukünftigen Versionen einfach nicht mehr ein-kompilieren.
2 „Gefällt mir“
Wenn ich es richtig sehe, gibt es noch (Mesh-)Probleme mit 802.11s, die noch nicht geklärt wurden? Kann das denn evtl. am Parallelbetrieb liegen? Dann sollten wir vielleicht vorm großen Abschalten testweise ibss bei den “Problem-Meshes” abschalten? Vielleicht ist das Problem dann schon gelöst? Grundsätzlich finde ich Abschneiden von alten Zöpfen eine gute Sache. Bei mir läuft 802.11s “rock solid” (ohne ibss).
Ich lade gerade 2016.1.1 nach http://images.freifunk-muensterland.net/experimental/ hoch. Darin wird ibss abgeschaltet. Die Software schalte den Updater dann in den experimental Zweig, Via Update kann ich die dann später wieder in den stable Zweig schieben. Mit Bitte um Tests durch andere …
Wenn da noch kein passendes Image ist, dann, weil der Upload noch nicht ganz durch ist, oder unterbrochen wurde.
Ach ja: Konten ist dann im Betrieb immer unter folgende Adresse erreichbar.
ip4 = '169.254.14.1'
ip6 = 'fd3f:6aa4:7338::1'
1 „Gefällt mir“
Irgendjemand noch Erfahrungen mit dem Image gesammelt? Ich würde das dann gern mal ins stable schieben… Kann sein, dass das in Sendenhorst schon von Vorteil wäre …
So geht es am einfachsten;
uci set autoupdater.settings.branch='experimental'
autoupdater
1 „Gefällt mir“
Ich kann das (leider erst) später heute Abend testen.
Soll ich dann ibss vorher wieder anstellen, damit das Abschalten auch getestet wird?
Och, ich leg einfach los 
…
2 „Gefällt mir“
Sieht gut aus, habe die ersten Kisten aktualisiert. Gibt es noch weitere Änderungen außer der Abschaltung des IBSS?
Nicht von meiner Seite. Ist halt auch ein Upgrade von 2016.1 auf 2016.1.1 drin.
Upgrade ist durch. Vor allem wo viel los war (Sendenhorst), sind die Links jetzt deutlich grüner!
Bitte noch um Mithilfe:
Bitte auf http://karte.freifunk-muensterland.org/map14/ gehen, dort statistiken und dann 2016.1-1 wählen. Da sind noch ein paar, und ich würde mich interessieren, warum die den Update nicht ziehen.
Ups. Zwei davon waren meine und der autoupdater war einfach deaktiviert. Ist jetzt gefixt…
Telgte ist jetzt stable bis auf nzh1, @paulinsche magst du da mal gucken, ich komme mit meinem Schlüssel nicht drauf…