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.
Was passiert denn, wenn da zwei Nodes noch unterschiedliche Verfahren nehmen und kurz nach dem connect „hintenherum“ (per Wifimesh) eine Verbindung bekommen?
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
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.
Wäre nicht sinnvoller, die Prüfung „ob autoupdate überhaupt gewünscht ist“ VOR dem joinen des anderen Freifunk-Netzes zu tun?
liegen die gluon-relvanten chronjobs nicht inzwischen unter „micron.d“?
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.
@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.
# 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.
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.)
@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
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.
@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!)
@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.
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)
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.
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.
Er holt sich eine IPv4. Falls fastd aktiviert ist könnte er dann versuchen übers FF fastd zu machen…
Mein Server ist intern. Mal prüfen inwiefern das funktioniert.
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?
Tu ich gerade mit 2 FWs:
Eine Version 1 mit ibss / adhoc und dem Script
Eine Version 2 mit mesh / 802.11s
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.
@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.
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
# 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)
Da gibts nur ein Migrationspaket was L2TP bzw Fastd einschaltet falls eines der beiden vor dem Update aktiv war.
mit nicht darauf getestet. Danke für diesen Hinweis