Batman v14 zu v15 upgrade - gluon package

@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!)

2 „Gefällt mir“

@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)

1 „Gefällt mir“

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.

1 „Gefällt mir“

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.

udhcpc -B -b -i update

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

2 Router:
Uplink mit FW2
Mesh-Router mit FW1

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

@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 :slight_smile: 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)

1 „Gefällt mir“

V6 autoconfig funktionierte bei mir überhaupt nicht. Ich habe auch manuell alle erdenklichen Einträge auf 1 gesetzt, aber es wollte einfach nicht.

mhm, genau … das war tricky - ich frag nochmal den menschen mit dem wir das gemacht hatten, kann sein das ich schlich was vergessen hab

os.execute("echo \"2\" > /proc/sys/net/ipv6/conf/fallback/accept_ra")

aus dem ffho script
Wieso jetzt ne 2 und in „“… KA

na die klammern sind bei echo optional - die 2 keine ahnung, kommt mir komisch
aber funktioniert das? und wenn ja … dann würd ich gern mal wissen warum … bzw. die hintergrundinfos dazu

Du meinst Anführungszeichen? Stimmt. Die gehen auf dem Weg verloren.
Aber es ist eine 2…

Für den Fall, dass dort mehrere reine Meschknoten stehen, sollte er einfach alle SSIDs und explizit alle BSSIDs durchprobieren. Dann erwischt er irgendwann den richtigen.

Mit wpa_supplicant kann man sich explizit mit einer BSSID verbinden.

ich hab gerade erfolglos versucht
[edit : in der aktuellen Version fuktioniert das, sieh git und weiter unten, das problem hier , gluon/openwrt kennt kein iw connect ]

    ffssid=freiburg.freifunk.net
    iw phy0 interface add update type managed
    ifconfig update up
    iw update connect $ffssid

ans laufen zu bringen, geht garnicht, auch wenn die anderen wireless mittels uci set wireless.foooooo.disabled=1 ; uci commit ; wifi abgeschaltet werden.
Entweder ich übersehe gerade etwas, oder es hat sic etwas in den 2 Monaten geändert, oder ich hab das damals wirklich NUR im Config mode ausprobiert, wo das ging. das ist deswegen so wichtig weil die Zeilen das Kernstück des scriptes sind.
Das angemerkte luci skript : Files · master · Freifunk Hochstift / ffho-packages · GitLab macht im Grunde das gleiche. (daher kommt auch das noch unerklärte echo „2“ > foo (s.o.)

(die korrektur zu dem batctl ist übrigends bei mir entsprechend so geworden
gwl=$(batctl gwl -H -n |grep gateways | wc -l) ; if [ $gwl != 0 ]; then exit 11; fi ; sleep 30 )

edit: zu echo 2 kam der Hinweis von @yayachiken „2 bedeutet, dass auf jeden Fall RA akzeptiert werden sollen. Sonst hängt das von den forwarding-Settings ab, siehe auch: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt (Strg+F accept_ra)“

1 „Gefällt mir“

Dazu direkt ein Verbesserungsvorschlag:

Wenn man von der High-Level Description „Name muss genannt werden (BY), und geänderte Versionen sollen die selbe Lizenz haben, der Originalautor muss weiter genannt werden (SA)“ ausgeht, dann sollte man lieber eine GPL-Lizenz für Code nehmen.

CC-BY-SA ist mit so ziemlich allen Copyleft-Open-Source-Lizenzen inkompatibel. Dementsprechend erlaubt die GPL da für Entwickler mehr. Wenn also wirklich nur auf das „BY-SA“ geschaut wird und nicht irgendwelche der versteckten Klauseln im Lizenzvolltext für euch relevant sind, dann ist die GPL ein vollwertiger Ersatz.

2 „Gefällt mir“

das skript schent nun zu laufen. gerne darf das getestet werden …
näheres hier aus der beschreibung zum endspurt

Ich fände es immernoch praktisch, wenn man das nutzen könnte, ohne es forken zu müssen.
Also Konfiguration entweder über ein kaskadiertes Git oder über die Site.Conf.

Das würde nämlich erleichtern, aktuelle Versionen zu benutzen zukünftig, ohne jedes Mal manuell mergen zu müssen.

2 „Gefällt mir“

@Adorfer … du bist immernoch eingeladen das mit zu entwickeln … und im groben ist das soweit ja schon geschehen …
es funktioniert sogar…

und wie heute auf der #ffwcw festgestellt funktinierte das vermutlich damals mit iw connect foo auch, nur das mit neuestem Gluon und damit neuerem OpenWrt auch iw in der Version 4.3 benutzt wird … und das hat einfach mal die connect funktion nicht mehr mit drin … das dürfte dann in Zukunft eventuell andere Skripte ebenfalls bricken - eben jene die auf iw connect aufbauen

diesem Umstand war zu verdanken das das skript grob lief als ich das initial mal hoch geladen hatte, bei einem späteren härteren Test garnicht mehr laufen wollte.

1 „Gefällt mir“

Ein Beitrag wurde in ein neues Thema verschoben: Weit entfernte Knoten