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…
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.
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
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.
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.
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.
Irgendwie tut die E-Mail-Benachrichtigung nicht 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.
@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
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 https://github.com/viisauksena/gluon-v14tov15-helper/commit/42f459e31ca850df4a92f6d958ee768befb6082b
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: https://github.com/freifunk-gluon/gluon/pull/760
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 …
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.