Software Migrationsstrategien (batman-adv, MTU, 11s etc)

Technik
31

Gibt es da eigentlich mittlerweile ein fertiges Paket für die Autoupdater-Verbindung-als-Client-Fallback-Lösung?

32

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“
33

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“
34

Funktioniert das zuverlässig?

35

Was ist für dich die Definition von zuverlässig? Ich habe es bei 2-3 Geräten getestet, dann deployed.

36

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?

37

Mich würde interessieren, ob damit mal ein Meshnetz mit zwei oder drei Stufen in zufälliger Reihenfolge umgezogen wurde.

38

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“
39

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“
41

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.

42

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“.)

43

ok, dann ist nun klar was du willst (oder für jemand anderen erläuterst) und in dem Fall kann ich dir tatsächlich nicht helfen.
Weiterer möglicher zukünftiger Fall ohne Parallelbetrieb: Umstieg von batman-adv auf babel/l3roamd

44

Okay, also scheinbar wurde der noch nicht in der Praxis getestet, das ist ja auch nicht schlimm.

Eine weitere brennende Frage ist auch, ob er unter „normalen Umständen“ genauso zuverlässig funktioniert, wie der klassische Autoupdater. Wäre nichts ärgerlicher, als einen kaputten Autoupdater rauszuschieben.

45

Ich habe es mit dem hier referenzierten versucht und war nicht erfolgreich. Die Konoten blieben nachhaltig offline und haben es auch mit „hochgesetzter Cron“ irgendwie nicht hinbekommen, sich in der benachbarten Freifunk-SSID einzuloggen und eine FW zu ziehen.
Eventuell gibt es noch weitere Randbedingungen, damit das funktioniert. Geht das dann evtl. „nur“ per IPv4?

Vermutlich habe ich aber auch von einem falschen Paket/CommitID gebaut.

1 „Gefällt mir“
46

Wir machen das ja gerade bei 1200 Knoten. Also Wechsel von BATMAN 14 auf compat 15 sowie auf 11s.

Wenn das durch ist kann ich ja mal einen kleinen Erfahrungsbericht schreiben.

4 „Gefällt mir“
47

[quote=„adorfer, post:32, topic:10740“]
Weshalb wir dann Wohl oder Übel auf „Parallelbetrieb“ für eine Woche gegangen sind.[/quote]

»Parallelbetrieb« ist aus meiner Sicht keine Option: für den Schwenk nach 802.11s als auch batman_adv v15+ ›irgendwann‹ brauchen wir sowieso eine autarke Lösung für unser Netz, und ›ffho-autoupdater-wifi-fallback‹ klingt für mich nach dem richtigen Ansatz: wenn Mesh $länger nicht verfügbar, guck’ mal, ob die Karavane vielleicht weitergezogen ist.

[quote=„adorfer, post:45, topic:10740“]
Eventuell gibt es noch weitere Randbedingungen, damit das funktioniert. Geht das dann evtl. „nur“ per IPv4?[/quote]

Hmm, ›ffho-autoupdater-wifi-fallback‹ setzt schein’s auf dhcpv6 statt RA?

uci:section('network', 'interface', 'fallback6',
  {
    ifname = '@fallback',
    proto = 'dhcpv6',
    peerdns = 1,
    sourcefilter = 0,
  }
)

Oder tut RA immer? Werde aus der OpenWRT-Doku diesbezüglich nicht schlau :frowning: Anyway, unsere FW-Server stehen im öffentlichen v4- und v6-Netz, insofern sollte das in jedem Falle tun.

Hmm, hat PRIORITY=0 nicht einen sehr ähnlichen Effekt?

The priority defines the maximum number of days that may pass between releasing an update and installation of the images. The update probability will start at 0 after the release time mentioned in the manifest and then slowly rise to 1 up to the point when the number of days given by the priority has passed.

[quote=„Tarnatos, post:46, topic:10740“]
Wenn das durch ist kann ich ja mal einen kleinen Erfahrungsbericht schreiben.[/quote]

Das wäre nett; mit welcher ETA rechnet Ihr, sprich, wann sollte das durchlitten sein?

48

Was dazu schreiben kann ich nächste Woche.

Fertig werden wir denke ich so in 3 Wochen sein. Wobei man leider nie alle bekommt.

49

naja, dann wartet ihr halt noch 20 Erfahrungsberichte ab, wenn ihr Leuten wie mir oder @hexa von ffda nicht glaubt, dass es bei uns schon vor einer Weile funktioniert hat ¯_(ツ)_/¯

EDIT: ihr müsst es ja nicht einmal glauben, einfach selbst testen mit einem Knoten.

ziemlich sicher, bei mir hat mein Testknoten es einwandfrei gemacht, und einige Monate später das ganze Netz.

2 „Gefällt mir“
50

1.

Der Umstieg 2017 in Freifunk Nord von batman compat 14 auf 15 (und gleichzeitig eine höhere MTU) hat gut geklappt:

  • neue Gateways eingerichtet mit neuem Batman 15
  • die neue Firmware hatte dann nur die neuen Gateways eingetragen
  • Ein git Repository eingerichtet, in dem wir die Knoten, die schon updaten dürfen eingetragen haben. Der Apache hat sich daher dann die immer aktuellen Regeln geholt.

Es war recht aufwändig, da wir die Knoten einzeln freigeschaltet haben indem wie auf der Karte geschaut haben, welche nicht „abgehängt“ werden und dann die IP6 des Knoten in der apache regel per git eingetragen haben. Aber war noch machbar bei ~1000 Knoten. Denke der Aufwand dafür eine automatisierung zu schreiben ist größer.

1 „Gefällt mir“
51

… Allerdings hat @sargon diese Zeit inzwischen für Kiel doch investiert (aus Wissenschaftlicher Neugier):

2.

In Kiel sind wir kurz vor dem Umsetzen des Umstiegs auf Batman 15 mit MIAU, der über eine bestehende Mesh Verbindung die Firmware an Nachbarknoten ausliefern kann auch, wenn keine Batman verbindung mehr möglich ist:

In unserem Blog haben wir das ausführlich beschrieben:

https://freifunk.in-kiel.de/blog/2019/04/13/BATMAN-migration.html

(Auf 11s umgestiegen sind wir vor einem Jahr schon in Kiel; ganz einfach mit einem kurzen parallellbetrieb)

2 „Gefällt mir“