# Batman v14 zu v15 upgrade - gluon package **URL:** \ **Category:** Technik\ **Created:** [16. Februar 2016 um 21:22 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808 "2016-02-16T21:22:10Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [16. Februar 2016 um 21:22 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/1 "2016-02-16T21:22:10Z")
hier ein gluon Paket das hilft von V14 auf V15 … bzw 16 zu wechseln. vorraussetzung mind 2 Gatewayserver und fastd. Wir probieren das gerade aus und es sieht sehr sehr vielversprechend aus. Die Lösung hier ist, erst ein **normales** update einzuspielen mit dem Paket, so dass alle Knoten das Paket haben. Später dann ein **v16** update einspielen. Verliert ein Knoten der längere Zeit offline war, sozusagen das update verschlafen hat, nun die Möglichkeit sich mit Gateways zu verbinden. Oder handelt es sich um einen meshenden Knoten, dessen uplink nun v15 spricht … dann verhält sich der Knoten wie ein Client und wird sich mit dem FreifunkNetz (based on uci ssid) verbinden und ein autoupdate forcieren (vorausgesetzt das ist nicht abgestellt). Der Ansatz erfordert neben diesem Paket und dem kontrollierten umstellen auf den Supernodes von Batman V14 auf V15 keine weiteren Konfigurationen/Monitoring. In der Theorie sind Knoten, die sonst da sind, maximal 1 Stunde offline. also, vielversprechend in der Erpobungsphase: > **[GitHub - viisauksena/gluon-v14tov15-helper: gluon-v14tov15-helper](https://github.com/viisauksena/gluon-v14tov15-helper)** > > gluon-v14tov15-helper. Contribute to viisauksena/gluon-v14tov15-helper development by creating an account on GitHub. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [16. Februar 2016 um 21:37 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/2 "2016-02-16T21:37:29Z")
Was passiert denn, wenn da zwei Nodes noch unterschiedliche Verfahren nehmen und kurz nach dem connect „hintenherum“ (per Wifimesh) eine Verbindung bekommen? ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [16. Februar 2016 um 22:05 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/3 "2016-02-16T22:05:39Z")
kannst du die frage präziser stellen? - vermutlich korrekte Antwort, die holen sich als client „getarnt“ ein autoupdate, wenn die gatewaylist leer ist. und wenn die meinen die haben schon das aktuellste (manifest check) - dann passiert garnix, „tarninterface“ geht wieder down ---
**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\ **Post date:** [17. Februar 2016 um 00:14 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/4 "2016-02-17T00:14:53Z")
Richtig gute Sache. Im Prinzip schadet es nicht, das immer drin zu haben, oder? ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [17. Februar 2016 um 00:27 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/5 "2016-02-17T00:27:26Z")
> [@fuzzle](#): > > vermutlich korrekte Antwort, die holen sich als client „getarnt“ ein autoupdate sorry, hatte mich vom Namen irreführen lassen. Ich dachte, es gnge um speziell Batman14/Batman15. Aber das past ja genauso beim Update vom ibss auf 11s. Oder von fastd auf l2tp. Oder von fastd-MTU1420 auf MTU1364. 1. Wäre nicht sinnvoller, die Prüfung „ob autoupdate überhaupt gewünscht ist“ VOR dem joinen des anderen Freifunk-Netzes zu tun? 2. liegen die gluon-relvanten chronjobs nicht inzwischen unter „micron.d“? 3. warum denn einmal pro Stunde? Für den Fall, dass jemand wirklich einen Freifunknode (oder mehrere Nodes) als Insel betreiben möchte, halte ich das für „einmal die Stunde“ für zu häufig, deutlich zu häufig. Zumal dann ja die ganze Wolke faktisch einmal runtergeht. ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [17. Februar 2016 um 08:02 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/6 "2016-02-17T08:02:34Z")
@MPW : ja, so wie es im Moment ist, passiert im Fehlerfall eher garnix - als das etwas kaputt geht. (wenn es denn schief geht), das war einer der Gründe das so zu machen. @adorfer: ja danke … der autoupdater könnte tatsächlich am Anfang geprüft werden, guter Einwand. Wir waren uns nur nicht sicher ob wir nicht unabhängig vom update einfach die notwendigen Änderungen vornehmen. Quasi am Autoupdater vorbei. ```auto # in etwa so (frei aus der hand) batctl -v = v14 wget -O /tmp/batman.ko http://irgendwo/batv15 ecdsaverify /tmp/batman.ko batctl if > /tmp/batif rmmod batman rm /irgendwo/batman mv /tmp/batman.ko /irgendwo/batman modprobe batman batctl if add $(cat /tmp/batif) ``` und auch ja, soweit hatten wir garnicht gedacht, das das auch sehr sinnvoll bei anderen Migrationsprozessen ist. Man könnte das evtl sauberer schreiben und nochmal besser auf noch mehr Geräten testen und dann als [optionaler] Standart im gluon haben, @anon75826926 ? zu cron und micron [2] : funktioniert trotzdem prächtig … denke das sollte trotzdem angepasst werden , müsste dann auch für den ssid-changer so sein @MrMM (aber warum funktioniert das trotzdem? weil ich dort „zufällig“ eh cronjobs laufen hab? die ich über **crontab -e** initialisiert hatte?) und zum stündlichen Test [3] : eine **batctl gwl -H | wc -l** abfrage kostet ja wirklich nix - in dem Skript geht garnix down , niemals. Es wird ein **zusätzliches interface** auf phy0 mit dem **namen update** aufgemacht, das dann im **managed mode** sich auf die **ihm bekannte ssid** einzuloggen versucht [**als client**] um Internet zu haben und dann **Dinge** zu tun. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [17. Februar 2016 um 08:17 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/7 "2016-02-17T08:17:46Z")
> [@fuzzle](#): > > Es wird ein zusätzliches interface auf phy0 mit dem namen update aufgemacht Ich war davon ausgegangen, dass einige der AT9k es nicht sauber hinbekommen, drei Radio-Modi (IBSS, AP, Client) simulan zu fahren. Für den (hoffentlich ausnahmefall), eines solchen großen Netz-Upgrades bei dem dann zusätzlich ein Node irgendwie abgehängt wurde (was auch nicht systematisch passieren sollte), reicht es doch, wenn die Reissleine alle 24h fängt. (Selbst wenn es dann ggf. 2-3 Tage braucht, wenn es beim ersten Mal nicht gleich klappt wegen eines schwachen Mesh-Netzes.) ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [17. Februar 2016 um 08:26 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/8 "2016-02-17T08:26:20Z")
@adorfer , wir gehen ja gerade davon aus das wir meshende Knoten mit einem autoupdate regelmäßig abhängen. Da werden dann autoupdate spezifisch massenhaft uplinks plötzlich V15 sprechen. Die meshenden nodes dahinter aber nicht - ich sehe nicht warum die mehr als 60 Minuten offline sein sollten … genau genommen würde ich das fast noch öfter probieren! Es geht ja gerade bei dem Skript darum das ein Knoten der keine GW mehr sieht (was nicht gleich dem tatsächlichen benutzen ist!) - sich zumindest mal auf nem alternativen Weg ansieht ob er nicht ein autoupdate bekommen kann. Solange der GW sieht, wird der nie irgendwas machen [quote=„adorfer, post:7, topic:10808“] Ich war davon ausgegangen, dass einige der AT9k es nicht sauber hinbekommen, drei Radio-Modi (IBSS, AP, Client) simulan zu fahren. [/quote] kann ich jetzt nichts zu sagen, auf dem 710v1 und dem 841v10 ging es ganz gut. Wer das testet möge doch bitte hier bescheid geben ---
**Author:** ![CyrusFox](https://forum.freifunk.net/user_avatar/forum.freifunk.net/cyrusfox/32/56_2.png) [@CyrusFox](https://forum.freifunk.net/u/CyrusFox)\ **Post date:** [17. Februar 2016 um 12:09 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/9 "2016-02-17T12:09:07Z")
> … Oder von fastd auf l2tp. Also bei Fastd ↔ L2TP Wechsel braucht man sowas nicht 😉 Da gibts nur ein Migrationspaket was L2TP bzw Fastd einschaltet falls eines der beiden vor dem Update aktiv war. ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [17. Februar 2016 um 12:28 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/10 "2016-02-17T12:28:41Z")
@CyrusFox: ich vermute der zusatz von @adorfer @MPW geht eher in die Richtung: **vielleicht ist es gut ein Skript zu haben, das einen Notfallweg zu einem Update kennt, wenn - warum auch immer - das Netz inkompatibel zum schläfrigen knoten wird** (gründe wie Nachts auschalten, Urlaub, autoupdater laaaang nicht an, mesh 4. Reihe hinten Links, Baustelle zum sonst sichtbaren uplinkmesh, stecker versehentlich gezogen, sicherung unauffällig an der sonst nix hängt geflogen …) insofern sind dann fastd-keywechsel, fastd\<-\>l2tp, batman-vXX, fastdMTU, supernodewechsel, Gatewaywechsel und sogar kanalwechsel … alles Szenarien die passen. Solange die SSID noch stimmt, der autoupdater eingeschaltet ist und der updateserver noch an den Hinterlegten Adressen für die hinterlegten Keys ein Update liegen hat (das hoffentlich zu dem laufenden System passt) wird der Knoten sich selber „retten“/updaten können. (seitenhieb : und solange man keine Splashpage/captive portal hat!) ---
**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\ **Post date:** [27. März 2016 um 22:16 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/11 "2016-03-27T22:16:52Z")
@fuzzle Ich bin skeptisch, ob dieses Paket so funktioniert. Wurde es schonmal getestet oder sogar bei einem Umzug eingesetzt? Wieso CC-BY-SA als Lizenz? Ist doch vollkommen unpassend für Code… Ich ergänze: Wieso soll das Script nicht mit nur einem GW funktionieren? Oder wenn das fastd-Peer-Limit auf 1 eingestellt ist? Ich sehe nicht das Problem. Wieso IPv4 verwenden? Was wenn sich doch ein Uplink ins Script rein verirrt und dann versucht übers FF seinen Tunnel aufzubauen?! Sollte die IPv6 autoconfig nicht normal funktionieren? Manche Router (841nv9) können (glaube ich) nicht gleichzeitig AP, Client und Mesh. Die würden sich vom Netz abschneiden / bricken. ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [28. März 2016 um 13:17 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/12 "2016-03-28T13:17:35Z")
die ganzen einzelnen elemente funktionieren, weil das bei uns noch dauert haben wir das nicht eingesetzt bisher. und einen wesentlichen teil nicht getestet: den ob der sich 1. korrekt einloggt und dann auch korrekt ip, dns und route bekommt um sich das update zu ziehen, könnte sein da fehlt noch ein dhclient … ich denke wir werden das so benutzen ( nachdem wir uns versichert haben das das auch so funktioniert, wie gesagt and dns/ route könnte noch Nacharbeit nötig sein) ---
**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\ **Post date:** [28. März 2016 um 13:18 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/13 "2016-03-28T13:18:56Z")
Wie gesagt wieso IPv4? (Ich habe den Post nachträglich noch um einige Fragen ergänzt, die sind wohl nicht per Mail geschickt worden… Hier nochmal: Wieso soll das Script nicht mit nur einem GW funktionieren? Oder wenn das fastd-Peer-Limit auf 1 eingestellt ist? Ich sehe nicht das Problem. Wieso IPv4 verwenden? Was wenn sich doch ein Uplink ins Script rein verirrt und dann versucht übers FF seinen Tunnel aufzubauen?! Sollte die IPv6 autoconfig nicht normal funktionieren? Manche Router (841nv9) können (glaube ich) nicht gleichzeitig AP, Client und Mesh. Die würden sich vom Netz abschneiden / bricken. ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [28. März 2016 um 13:47 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/14 "2016-03-28T13:47:08Z")
ja, nachträgliche edits kommen (zum Glück) nicht als seperate Email. … daher jetzt nochmal, du beziehst die auf die README.md? die ist quasi veraltet. **zu den GW** : Das Skript war ursprünglich dafür gedacht valide in kurzer Zeit von Batman v14 zu v15 zu wechseln. Das bedeutet das einige Nodes noch auf v14 hängen und andere schon v15 benutzen… dazu braucht es im Netz eben mehrere fastd Instanzen mit unterschiedlichen batman … man kann auch darauf verzichten und hoffen das das alles in der Art funktioniert das alle innerhalb einer Stunde dann wechseln, das würd ich aber im kleinen Stil sicher testen, schlimmstenfalls hat man dann nämlich unterschiedliche batman Nodes die auf den gleichen Peer wollen. **Ipv4** : weis grad nicht genau wo das im script noch eine Rolle spielt **Ipv6** : autoconfig … das ist genau der part den wir bisher nicht getestet haben, irgendwas war dort, das wir nicht valide ins v6 Internet kamen (wo der Testupdate server stand) … weiteres genaues nachsehen , ob das stimmt, oder nur in unserem Netz (kurzzeitig) so schwierig ist, etc. pp. haben wir auf den Zeitpunkt verschoben wenn ein Einsatz näher rückt. **3 Netze** : dachte gerade der 841 wäre dazu in der Lage drei Dinge zu tun, solange das alles auf dem gleichen channel ist. - aber auch das ist nicht gut getestet. Ein „einfacher“ weg wäre natürlich zu sagen: wenn du eh kein Internet hast schalt dein **AP** oder dein **Mesh** aus … was ich aber umgehen wollt - aber sicherer wäre das vielleicht. das problem beim Testen ist ja das man den Router künstlich vom Freifunk Netz abklemmen wollte und gleichzeitig ins eigene Freifunk Netz als client einloggen will. Ein guter Test wäre vermutlich : in das skript noch ein paar **echo** … oder **wget** statements einzubauen um das besser debuggen zu können und dann eine **v15 version** zu bauen die quasi inkompatibel zum bisherigen Netz ist (und damit das Skript triggert), mit geringerer **release Nummer** / **autoupdater an** und dann zu sehen ob dieser sich selbst als client ein autoupdate holt. ---
**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\ **Post date:** [28. März 2016 um 14:25 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/15 "2016-03-28T14:25:21Z")
> [@fuzzle](#): > > Ipv4 : weis grad nicht genau wo das im script noch eine Rolle spielt ``` udhcpc -B -b -i update ``` Er holt sich eine IPv4. Falls fastd aktiviert ist könnte er dann versuchen übers FF fastd zu machen… > [@fuzzle](#): > > wir nicht valide ins v6 Internet kamen Mein Server ist intern. Mal prüfen inwiefern das funktioniert. > [@fuzzle](#): > > 3 Netze Ich habe die Erfahrung gemacht, dass das nicht geht, als ich mich an einem Wifi-Uplink-Setup versucht habe. Dumme Frage: Wie genau schaltet man denn den AP oder mesh aus? > [@fuzzle](#): > > Testen Tu ich gerade mit 2 FWs: Eine Version 1 mit ibss / adhoc und dem Script Eine Version 2 mit mesh / 802.11s 2 Router: Uplink mit FW2 Mesh-Router mit FW1 ---
**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\ **Post date:** [28. März 2016 um 15:29 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/16 "2016-03-28T15:29:25Z")
Was soll denn passieren wenn 2 Mesh-Router noch stehen?! Die werden beide kein Update ziehen weil es mehrere Netze mit der SSID gibt. Man müsste also in einen Fallback-Modus verfallen und das Client-Netz abschalten und diesen Zustand beibehalten, bis entweder GWs zu sehen sind oder das Update gezogen wurde… So würde das Script BTW nichts machen. Batctl gwl -H gibt zurürck „No batman gateways found“. Das muss man noch rausgreppen. Die Tests sind ein vollständiger **fail** ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [28. März 2016 um 15:49 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/17 "2016-03-28T15:49:50Z")
@PetaByteBoy : ich würde das sowieso nur in Kombi mit dem SSID-Changer skript verwenden, was bei fehlender Connection statt der normalen SSID halt **FF\_OFFLINE\_$nodename** rauslässt. Ansonsten wäre das ein echtes Problem. > [@PetaByteBoy](#): > > So würde das Script BTW nichts machen. Batctl gwl -H gibt zurürck „No batman gateways found“. Das muss man noch rausgreppen ja genau, so fiese Dinge meine ich 🙂 mit nicht darauf getestet. Danke für diesen Hinweis hab gerade kaum Zeit, das auch parallel zu testen, aber wenn der batctl Test durchläuft wäre ja nur die frage ob der folgende Block durchläuft ```auto # check if freifunk as we know it is nearby ffssid=$(uci get wireless.client_radio0.ssid) : ${ffssid:=freiburg.freifunk.net} # if for whatever reason frssid is NULL many=$(iwinfo phy0 scan |grep $ffssid | wc -l) # connect to freifunk and get dhcp lease if [$many != 0]; then iw phy0 interface add update type managed ifconfig update up iw update connect $ffssid udhcpc -B -b -i update fi ``` mit oder ohne udhcpc … soweit ich mich erinnere lief das von Hand durch und damit stünde dem autoupdater nichts entgegen (nur das wir damals v6 foo probleme hatten den updateserver ausserhalb des freifunk netzes zu erreichen) ---
**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\ **Post date:** [28. März 2016 um 15:56 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/18 "2016-03-28T15:56:38Z")
V6 autoconfig funktionierte bei mir überhaupt nicht. Ich habe auch manuell alle erdenklichen Einträge auf 1 gesetzt, aber es wollte einfach nicht. ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [28. März 2016 um 16:15 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/19 "2016-03-28T16:15:28Z")
mhm, genau … das war tricky - ich frag nochmal den menschen mit dem wir das gemacht hatten, kann sein das ich schlich was vergessen hab ---
**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\ **Post date:** [28. März 2016 um 17:15 UTC](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808/20 "2016-03-28T17:15:58Z")
``` os.execute("echo \"2\" > /proc/sys/net/ipv6/conf/fallback/accept_ra") ``` aus dem ffho script Wieso jetzt ne 2 und in „“… KA [Nächste Seite](https://forum.freifunk.net/t/batman-v14-zu-v15-upgrade-gluon-package/10808.md?page=2)