Davon ab wäre das Nutzen der gluon-state-check-Infrastruktur eine gute Idee, um unnötige Abfragen in’s Netz zu vermeiden.
@fmaurer hatte die Idee schon vor ein paar Wochen:
… in Gluon v2020? Erzähle gerne mehr!
Damit brichst du im Falle des Transition-Modes sämtliche Verbindungsversuche für Clients die das pointer-IE im unsecured beacon sehen. Beide Netze zeigen auf sich gegenseitig, daher musst du zwar nur die SSID des unsecured netzes anpassen, aber ebenso den pointer im OWE beacon.
Ist das auch relevant hierbei?
owe_transition_mode = false,
(Da die Berichte eher in Richtung »nice try, but at times badly implemented« gingen, haben wir den disabled.)
1 „Gefällt mir“
Nein
1 „Gefällt mir“
Ah ne. Ich sprach von supporteten Releases, sorry.
Aber das Paket ist relativ gut isoliert, ein Backport des einen Commits, der die Infrastruktur schafft ist vmtl. trivial.
Wenn sich jemand an das Paket setzt, sagt gerne Bescheid, beim Backport helfe ich gerne.
Wir präparieren halt das „letzte 841-Update“ (basierend auf v2021.2.x), und das soll halt »once and for all« alles drin haben. Für 841er ist OWE kein Thema, aber es fallen ja auch ein paar andere Geräte mit v2022.1.x (erstmal) raus.
Auch erschließt sich mir nicht, wie has_default_gw6 dem SSID-Changer helfen soll — ich kann doch auch ein Gluon-Netz ohne IPv6-Default-GW haben? tecff-ssid-changer nutzt post-v2021 /var/gluon/state/has_default_gw4, was in dem verlinkten Commit gar nicht drin ist — und für ein v6-only-Mesh auch wieder nicht zielführend wäre. Finally: muß man die ›gluon-state-check-Infrastruktur‹ irgendwie aktivieren? Ich finde jedenfalls nix in meinen v2022.1.x-Images?
einfach das paket gluon-state-check einbinden (feature eben dann state-check ohne gluon prefix), oder ein anderes, das darauf depended. Ich glaube es gibt auch (core-)Pakete die es nutzen, sofern es da ist, aber nicht dependen. Gefährliches Halbwissen ohne nachzulesen.
1 „Gefällt mir“
Die Idee von gluon-state-check ist nicht, dass ihr die vorhandenen states nutzen sollt oder müsst.
Es ist vielmehr ein sauberer Weg, wie ‚teure‘ Messergebnisse zum Beipiel massenhafte Pings in ein Ergbnis aufbereitet, dass dann auch andere Pakete nutzen können.
Der Ansatz ist wie sonst auch, ein erfolgreicher Ping führt zum Ergbnis „ist online“.
Aber statt das Ergbnis nur für das eine Paket zu nutzen, könnte man einen state „could_ping_google“ anlegen. Den können dann andere Pakete auch nutzen.
Die bestehenden states has_default_gw6 und has_neighbours können abhängig vom Aufbau der Infrastruktur einer Community helfen, pings zu vermeiden.
Vielleich pingt der Router nur alle 5 Minuten mal, wenn er noch Defaultrouten und Meshnachbarn hat.
Es geht mehr darum, dass nicht einfach wahllos alle Knoten im Minutentakt irgendwas im Internet pingen. Wenn’s schlecht läuft, wirft das einen unguten Eindruck auf’s gesammte Projekt.
PS: Die ganze Debatte ist natürlich alt und aufgeladen; aber hier ist der Entwurf, der das Konzept beleuchtet: gluon-online-status concept · Issue #2228 · freifunk-gluon/gluon · GitHub
und wer mehr lesen will, hier der PR, in dem wir viele Aspekte schonmal beleuchtet haben: gluon-state: implement ipv6 default route check by AiyionPrime · Pull Request #2245 · freifunk-gluon/gluon · GitHub
Afaik nutzen die hier diskutierten „offline/online-Checker“ NICHT (TCP-)pings, sondern die hop benalty bis zum nächsten Batman-gateway (oder dessen Abwesenheit).
Diese Info hat der lokalte Batman-switch sowieso, die Abfrage verursacht also KEINE zusätzliche Last (Broadcast, whatever) im Netz.
2 „Gefällt mir“
Das wusste ich nicht; ich kenne nur Ping-basierte aus Schauergeschichten in PRs 
siehe da oben, das Posting von rubo77 von 2018: Kein Ping, nur batctl.
Will sagen: Ihr diskutiert hier seit 11 Postings Dinge, die NICHTS mit dem zu tun haben, was Rubo vor 5 Jahren vorgeschlagen hat.
Wenn ihr Probleme mit anderen Implementationen habt, dann macht bitte einen neuen Thread auf, aber hijacked nicht diesen hier. Sieht sonst nach Strawmanning aus.
1 „Gefällt mir“
FTR, die Version kommt nicht mit unterschiedlichen SSIDs auf den Bänderm klar. Also muß doch ich einen von beiden selbst aufbohren. *sigh*
Der SSID-Changer hat es nun ins Community-Packages-Repository geschafft:
- OWE wird berücksichtigt
- Mesh protokoll unabhängig durch has_default_gw4 aus gluon-state-check (TQ_LIMIT_ENABLED klappt nur mit batman)
- soll-wlan namen jeweils aus uci für 2.4GHz, 5GHz und OWE
- benötigt gluon-version v2022.1.x oder größer (wegen gluon-state-check package)
v6 only mesh Netze sind somit als einziges der bisher genannten requirements nicht unterstützt, und bei Zeiten könnte man das nochmal in lua refactoren.
Falls da jemand Lösungen für machen möchte, kann das gerne dann auch direkt im community-packages repository passieren.
Das führt somit diesen Thread hoffentlich ans Ende
2 „Gefällt mir“
Du rufst in Zeile 209 in
die /lib/gluon/eulenfunk-hotfix/check_hostapd.sh auf.
Ist die mit Gluon 2022 kompatibel?
Verstehe ich es richtig, dass die Hostapd-Deadlocks auch mit Gluon2022 noch auftreten in Szenarien wie „SSID-Wechsel während laufendem DFS-WAIT“.
Im wesentlichen hab ich die bestehenden versionen zusammengeführt/angepasst und lauffähig gemacht.
Der ssid-changer so funktioniert, ob man einige workarounds mittlerweile weglassen kann hab ich nicht getestet.
Ich weiß ja nicht für welche Geräte und Edge-Cases die angelegt wurden und wollte die eulenfunk funktionalität nicht rausschmeißen, weil sie ja sonst auch nicht stört… Wie das eben so ist mit legacy - ich habe das check_hostapd.sh aber nicht getestet.
Da hilft es natürlich total, wenn die Originals da drüber gucken:
Eventuell kann man Zeile 206-210 auch komplett weg lassen - ich kannte den Hintergrund bis grade auch gar nicht
Dazu müsste man die Zeilen mal lokal löschen und in einem „SSID-Wechsel während laufendem DFS-WAIT“-Szenario austesten - war das denn dann reproduzierbar mit den deadlocks oder ein klassischer „Manchmal“-Fehler?
O.k. „lauffähig gemacht“ im Sinne von „smoketest OK“, „functional tests: skipped“?
Welches Regressiontesting gab es denn für das Package?
Siehe weiter oben im Thread! Eine Racecondition, die in einer größeren Domain irgendwann auffällt, dass einige Knoten (mit wackeligem Uplink) keine 5GHz-Airtime (und keinen Kanal) reporten… weil das 5G nimmer läuft… bis zum weekly reboot.
Mein Verständnis war, dass das mit wem Wechsel von Wifistack von Openwrt19 auf 21(?) nicht mehr auftreten sollte. Mangels eigener Gluon22-Tests kann ich dazu aber inhaltlich wenig sagen.
Das würde ich dann aber mal als „bold claim“ einordnen.
Lauffähig im Sinne von „funktioniert in meinen Szenarien (uplink weg, uplink da, mesh weg, mesh da) auf meiner FB7520 und o2-6431“.
Wenn du einen Testkatalog parat hast und das auf deinem device-fuhrpark probieren würdest, würde ich mich freuen.
Ich habe hier nicht geclaimed, dass das bugfree software ist, dass es jetzt ein für alle mal keine Änderungen benötigt und auf allen versionen läuft.
Es gibt jetzt ein Paket an zentral auffindbarer Stelle in einem Repository welches community übergreifend genutzt wird, welches aktuell bestehende Forks vereint und ich würde mich freuen wenn Änderungen/Features/Bugfixes auch den Weg dort hin finden werden.
Wenn man das Thema hier als „gluon-ssid-changer forks mergen“ bzw „was Rubo vor 5 Jahren vorgeschlagen hat“ sieht, dann ist das nun (erneut - nach wiederkehrendem wildwuchs) passiert und soweit upstream gebracht wie es eben sinnvoll ist.
Meinetwegen kann man hier aber auch die Weiterentwicklung diskutieren
es ist das community repo. jeder ist selbst tester.