Fork von "ffho-autoupdater-wifi-fallback" gesucht

Hallo zusammen,

Freifunk Hochstift hat ja ein Wifi-Fallback script, welches beim Verlust von Konnektivität ab und zu mal schaut, ob der Knoten vielleicht einfach ein mesh-zerstörendes Firmwareupdate verpasst hat, indem er sich einfach per Client mit einem offenen WLAN verbindet und schaut ob er so ins Internet kommt.

Beim Originalscript verbindet er sich ja einfach mit einer *.freifunk.net SSID, aber ich bin mir sicher, dass jemand zumindest das umgepatcht hat (auf alle offenen WLANs) und auch sonst Änderungen vorgenommen hatte (speicherte wohl zuviel auf dem flash oder so?). Hab diesen Fork aber leider nicht mehr gefunden…

Original: ffho/ffho-autoupdater-wifi-fallback · master · Freifunk Hochstift / ffho-packages · GitLab

Kann mir jemand weiterhelfen?

Gruß
David

2 Likes

Das ist bereits behoben,

siehe Forgot one uci:commit (a8d93b73) · Commits · Freifunk Hochstift / ffho-packages · GitLab

Das schaut sehr gut aus, ich würde das aber gerne in unser git übernehmen um kleine Anpassungen vorzunehmen.

Könntet ihr daher bitte eine Lizenz hinzufügen?

3 Likes

Lizenz liefern wir noch global für das Repo nach. Du kannst das Git aber einfach forken. Solltest du funktionale Änderungen haben würden wir uns über Diffs oder Mergerequests freuen.

2 Likes

eine frage die mir beim drüber kucken kam …
was bedeutet dies

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

konkret , warum 2 ? ich dachte das sei 0 aus, 1 an
(und die Anführungszeichen sind da obsolet, verwirrend)

os.execute("iw dev fallback connect -w " .. wifiNetwork)

wenn ich das von Hand (shell) mache, dann klappt das nicht, weder mit -w (was das sein soll??) noch ohne benutze. ist das getestet?
(auch wenn ich vorher die uci set wireless ..bla.disabled=1 ; uci commit ; wifi setze)

Es hat vor 2 Monaten im Config mode mal geklappt(etwas ähnliches, aber im Moment bekomme ich das nicht mehr zum laufen)
konkret versuche ich

        iw phy0 interface add update type managed
        ifconfig update up
        iw update connect $ffssid```

ich beziehe mich konkret auf https://git.c3pb.de/freifunk-pb/ffho-packages/blob/master/ffho/ffho-autoupdater-wifi-fallback/files/usr/sbin/autoupdater-wifi-fallback

Hab zwar nix damit zu tun, aber die Frage kann ich beantworten:

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)

Bei iw hilft die Helppage:

dev <devname> connect [-w] <SSID> [<freq in MHz>] [<bssid>] [key 0:abcde d:1:6162636465]
	Join the network with the given SSID (and frequency, BSSID).
	With -w, wait for the connect to finish or fail.

Schade, das ganze baut weitgehend auf einem eigenen Autoupdater auf, ich würde aber gerne den von Gluon behalten.

ne, tut es nicht, es benutzt ja eben genau diesen … unter speziellen bedingungen wird versucht sich als client in das netz einzuloggen und ein autoupdate -f zu fahren …
in der Hinsicht unterscheidet sich das lua script von ffho nicht von meinem v14v15updater shell script, nur das meines noch buggy ist

Ich wollte sobald der mehrkern bug behoben ist auf batman2016 umsteigen… funktioniert das ding hier schon stabil? hat das wer im einsatz? oder ist das noch alles experimentell?

Ich glaub da arbeitet niemand mehr dran. Die Entwickler konzentrieren sich auf die neue Batman-Version und von den Freifunkern ist niemand tief genug drin.

Grüße
Matthias

Jup da werden wir wohl eher auf Babel umsteigen, als das der Batman SMP Bug behoben wird :smiley:
Glaub die wissen selber nicht das den fehler auslöst…

Ich finde den Bug überhaupt nicht mehr relevant. Seit L2TP braucht man auch auf den Gateways keine CPU-Leistung mehr. Also baut man einfach eine VM, die nur einen Kern bekommt und es läuft und läuft und läuft.

Sie hatten ja ein paar Patches eingereicht, aber laut @Lars besteht das Problem weiterhin.

Grüße
Matthias

Wo siehst du denn das? Ich sehe nur:

local function run_autoupdater()
  -- TODO:should be called with -f !
  os.execute("/usr/sbin/autoupdater -f")
end

Sieht doch ganz „normal“ aus?

Irgendwie tut die E-Mail-Benachrichtigung nicht :frowning: Aktuell ist das script in der veröffentlichen Version nicht funktionsfähig zusammen mit dem aktuellen gluon. Da wurde wohl (ob von OpenWRT oder Gluon weiss ich gerade nicht) bei iw die connect-funktion raus gepacht. kb-light ist aber bereits an einem Fix dran.

Der gluon Autoupdater wurde weiterentwickelt.

@oscar : ich wollte nochmal auf das script / package von mir hinweisen, das zumindest an den 841ern zu funktionieren scheint (aber gerne gerne testen und mir bescheid geben) denn das mit dem fehlenden iw connect hat mir auch große Probleme gemacht
hier der part meiner lösung :

...
        foomac="something"
        ffssid="someotherthing"
        iw phy0 interface add update type managed
        ifconfig update hw ether $foomac
        ifconfig update up
	# install new if in /etc/config/wireless
	uci set wireless.update_radio0=wifi-iface
	uci set wireless.update_radio0.ifname=update
	uci set wireless.update_radio0.network=update
	uci set wireless.update_radio0.disabled=0
	uci set wireless.update_radio0.device=radio0
	uci set wireless.update_radio0.mode=sta
	uci set wireless.update_radio0.macaddr=$foomac
	uci set wireless.update_radio0.ssid=$ffssid
	uci commit
	# restart wifi and get ip 
	wifi; sleep 2;
        # nachtrag [edit]
        echo 2 >> /proc/sys/net/ipv6/conf/update/accept_ra
	udhcpc -B -b -i update

https://raw.githubusercontent.com/viisauksena/gluon-v14tov15-helper/master/files/lib/gluon/v14tov15-helper/v14tov15-helper

Ich hab gerade mal versucht deine Lösung auf einem meiner APs ausprobiert, leider ohne erfolg.
Kann es sein, dass man dazu wpa_supplicant oder ähnliches in seinem Image haben muss?

ja, kann sein.
ich suche auch gerade noch einen bug in den cpe210 - v2016.1.4 der damit zusammen hängen könnte - wir haben zwischendurch mal OHNE wpa-supplicant-mini gebaut.

wpa-supplicant-mini wird bei uns oft mit eingebaut

edit: hab das in der Makefile mal als dependency eingefügt, fehlendes wpa-supplicant-mini führt sogar dazu das der AP zumindest bei den cpe210 kaputt geht und sich keiner mehr assoziieren kann, das fällt nur schwer auf wenn man eh mehrere router vor ort hat (841 bspw.) - im logread kann man das sehr schön sehen, sollte mit wpa-supplicant-mini gefixt sein

1 Like

hmm ok das mit dem wpa-supplicant-mini ist sehr schade, ich denke wir sollten versuchen das connect feature von iw wieder in gluon/lede/openwrt zu bekommen.
Ich hatte da vor eine paar Tagen schon mal ein pullrequest bei gluon gestellt:

ja, es ist nicht nur das,
wenn man das dritte IF aufmacht bei den cpe210 dan scheinen die anderen „willkürlich“ weg zu brechen … teilweise die AP connectivity verloren gehen …etc.
logread und dmesg liefern da einige hinweise - ich habe diese Tage nur keine Zeit das zu prüfen …
ich kann nur mit Sicherheit sagen, das die cpe210 mit dem v1415 script leicht verrückt spielen,
fastd-uplink scheint zu gehen - mesh-vpn auch …

werde das nächste Woche mal genauer bei einem Testsetup ausprobieren …