Für das ffm-MultiMTU benötigst Du keine Migration, das kannst Du „einfach so“ in die Firmware nehmen sobald die Server dafür eingerichtet sind.
1 „Gefällt mir“
auch gluon wird ibss in Zukunft rauswerfen, insofern sollte man irgendwann eben mal auf 11s wechseln.
der WR841N v13 beispielsweise wird auch garantiert kein 11s können, Chipsatz-seitig.
(ja, off-topic teils)
Quelle?
Da wäre es schlicht hilfreich, würde Gluon hierbei unterstützen. Schwenke ich den einzigen Uplink in einem Mesh von AdHoc nach 802.11s, sind auf einen Schlag alle vermaschten Knoten offline. Kurzum: sollte »auch gluon wird ibss in Zukunft rauswerfen« zutreffen, würde ich schon erwarten, daß derlei mit Gluon-Bordmitteln gelöst wird — »Legacy« wird ja auch noch mitgeschleppt …
That said, und das gehört dann in einen neuen Thread: ist denn 802.11s auf Basis Gluon v2016.2 nun gleich stabil und nutzbar wie AdHoc? Initial klang das IIRC nicht so, weshalb hier zumindest noch keine s-Pläne vorliegen.
Ich gebe offen zu, dass wir das Problem von zwei solchen Meshes hatten, wo die Situation während der Umstellung wirklich „gefühlt offline“ für die die Clients an den Meshknoten war.
Da war’s aber eigentlich auch vorher schon grenzwertig stabil.
Will sagen: Man sollte die Zeit des Parallebetriebs möglichst gering halten, da es a) in großen Netze (Gesamtzahl der Batman-Knoten) und b) in hochgradig redundanten Wifimeshes im Besonderen wirklich schmerzhaft ist.
1-2 Wochen müssen reichen, auch auf die Gefahr hin, dabei Knoten von Urlaubenden zu verlieren.
(Thema darf gern von einem Moderator in eines neues Topic abgetrennt werden, da es weder Hardware, noch den C25 im Speziellen betrifft, sondern eher Gluon.)
Siehe auch
es gibt keine Quelle, das wurde im IRC so erwähnt
Eine Unterstützung wird vielleicht kommen - ist aber von einigen communities schon selbst gemacht worden, es haben ja schon einige große gewechselt.
Wir z.b. haben einfach 2 Tage Parallel-Mesh-Betrieb gemacht, die sonderlocke „autoupdater-wifi-fallback“ ist dann nur noch für mesh knoten ,die während der 2 Tage durchgehend offline waren. Diese Sonderlocke muss man aber frühzeitig ausrollen, sprich Wochen/Monate VOR der Umstellung.
Wer ein Freifunk-Netz betreibt sollte sich schon stetig aktiv selbst informieren - selbst wenn man nur im Forum lesen sollte, dann wüsste man vieles schon.
Alles stabil, wird schon von einigen communities seit Monaten genutzt.
@anon68922371 vielleicht kannst du die letzten Beiträge hier ja in den Thread „Software Migrationsstrategien“ schieben?
1 „Gefällt mir“
On 18.05.2017 10:19, rotanid wrote:
Eine Unterstützung wird vielleicht kommen […] Wir z.b. haben einfach 2 Tage Parallel-Mesh-Betrieb gemacht, […]
Von parallel wurde immer wieder abgeraten, unklar nur, ob die kolportierten Stabilitätsprobleme damals von AdHoc+802.11s oder eher den Treibern in Chaos Calmer generell kamen. Nicht ohne Grund wechselten anfangs Communities von auf Gluon v2016.1-basierenden Firmwares wieder auf ältere zurück und einige größere (wie z. B. Hamburg) erst jetzt auf Gluon 2016.2.
Wer ein Freifunk-Netz betreibt sollte sich schon stetig aktiv selbst informieren […]
Ich bin sehr dankbar für die, die auf jeden neuen Zug beherzt aufspringen, anders kann es keinen Fortschritt geben. Wir haben dafür nicht die Resourcen und so wiegt jedes negative Feedback doppelt schwer bei der Bewertung der Risiken, an grundlegenden Parametern zu drehen.
Weder noch.
Das Problem ist die damit quadratisch anwachsende Größe der Routingtabelle im Batman und allen daraus resultierenden Effekten.
Plus einem beständiger Flappen der Routen vom belasteten Link zum vermeintlich unbelasteteren.
Wo der Sweetspot zwischen Leidensfähigkeit und „No Router left behind“ liegt, also wieviel Tage Parallelbetrieb: Entscheidung der Community.
1 „Gefällt mir“
kann mich adorfer nur anschließen: umso länger man wartet, umso größer das Netz, desto schmerzhafter wird der Parallelbetrieb - und desto kürzer wird man ihn halten wollen.
2 „Gefällt mir“
Ich halte von Parallelbetrieb nicht viel; sofern der AU-Fallback der Paderborner funktioniert, ist ersterer auch nicht notwendig und löst letzterer mehr, als ein Parallelbetrieb brächte.
Gibt es da eigentlich mittlerweile ein fertiges Paket für die Autoupdater-Verbindung-als-Client-Fallback-Lösung?
Ich bin noch auf der Suche nach einem Paket und einer nachvollziehbaren Dokumentation, wo dieser Fallback wirklich genutzt wurde (und funktioniert hat bei mindestens den üblichen „Wifimesh-Only“-Modellen. Auf die Probleme bei den Dualband-Exoten will ich also hier gar nicht anspielen. Nur damit ich nicht falsch verstanden werde.)
Mag aber sein, dass ich schlicht immer nur von den falschen Paketen gebaut habe und die Versuche daher hier im letzten Jahr allesamt kläglich selbst auf „strunznormalen 841ern“ gescheitert sind.
Weshalb wir dann Wohl oder Übel auf „Parallelbetrieb“ für eine Woche gegangen sind.
1 „Gefällt mir“
wir haben den fallback im Dezember eingebaut in einer 2016.1.6 Firmware und dann Anfang Februar mit einer 2016.2.3 Firmware umgestellt auf 11s
Der Fallback hat bisher noch den Nachteil, dass er einen OpenWRT-Patch (und somit gluon-Patch) benötigt.
Vielleicht wird das aber irgendwann upstream kommen - wenn’s jemand macht…
1 „Gefällt mir“
Funktioniert das zuverlässig?
Was ist für dich die Definition von zuverlässig? Ich habe es bei 2-3 Geräten getestet, dann deployed.
Mich würde jetzt eher die Definition von „das“ interessieren.
Parallelbetrieb? Den habe ich bei lokalen Meshes mit >5 Wifilinks pro Node als unzuverlässig erlebt.
Die UserExperience war sehr, sehr mau und das zweite Update auf „11s-only“ nach einer Woche war dem geschuldet. Eigentlich wollten wir das länger tun.
Oder meinst Du mit „das“ den (welches der vielen Pakete) Wifi-Client-Fallback-Hack?
Mich würde interessieren, ob damit mal ein Meshnetz mit zwei oder drei Stufen in zufälliger Reihenfolge umgezogen wurde.
ja, sowohl Darmstadt als auch wir und einige andere haben die Migration so gemacht, ohne Reihenfolge-Planung sondern mit Parallelbetrieb. Wir eben zusätzlich noch mit wifi-client-fallback für die Knoten die während der Umstellung offline sind.
Die Umstellung muss man wie schon gesagt gut und rechtzeitig planen, z.B. mit der vorherigen Ausspielung (Wochen, besser Monate vorher) einer FW die den fallback integriert hat. Dann signiert man das Manifest der Parallelbetrieb-FW mit einem Datum das deutlich vor dem Tag liegt, an dem man es zur Verfügung stellt, damit innerhalb weniger Stunden alle Nodes im Parallel-Betrieb sind sodass man dann in der darauffolgenden Nacht, mit einem ebenfalls schon vorher vorbereiteten und mit frühem Datum versehenen Manifest, das 11s-only update ausspielen kann.
Also zum letzten Mal, viele haben es schon gemacht, Planung ist das halbe Leben, Magie ist keine dabei, Probleme gab es auch keine.
2 „Gefällt mir“
Diese Antwort lese ich aber als „Nein“, gemäß der Frage von MPW.
Sofern seine Frage sich auf „via wififallback“ bezogen haben sollte. Oder ging es etwa doch mit seiner Frage um den Parallelbetrieb?
Und falls doch „ohne Prallelbetrieb“: Welches war denn das Paket, das genutzt wurde (Bitte Link mit Commit-ID).
1 „Gefällt mir“
Wieso liest du das als „Nein“? Falls du die Frage nach Umzug in zufälliger Reihenfolge meinst: eindeutig JA.
Komplett ohne Parallel-Betrieb halte ich für wenig sinnvoll, da es da doch zu längeren Ausfällen an manchen Standorten kommen. Ich kann aus unserer Erfahrung absolut die Vorgehensweise empfehlen, die man in meinem letzten Beitrag hier nachlesen kann.
Ob es „wenig sinnvoll“ ist: Das musst Du @MPW fragen. Spätestens bei einem Batman-adv-Wechsel (steht ja auch noch in einigen Communites an) gibt’s schlicht keine Möglichkeit von Parallelbetrieb. (siehe auch Topic dieses Threads)
MPW fragte: „Hat es jemand schonmal erfolgreich gemacht ohne Parallelbetrieb, nur mit dem Wificlient-Fallback und mehrstufigem Wifimesh“.
Und darauf konnte zumindest bislang niemand „Ja“ antworten.
(Wobei es mich freuen würdenn es trotzdem jemand täte).
(„Hat hier schonmal jemand an seinem Auto vorn Sommerreifen und hinten Winterreifen gefahren“ - „Ja, wir haben allerdings vorn und hinten gleich Winterreifen draufgetan, Sommerreifen war nur das Ersatzrad“.)