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 
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
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 „Gefällt mir“
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 …
Ich versuche zur Zeit, ffho-autoupdater-wifi-fallback mit Gluon v2015.1 bzw. OpenWRT BB zum mitspielen zu bewegen. Das ist nicht trivial Erst einmal wird die wpa_supplicant-fallback.conf mit „disable_vht=1“ erzeugt, über die wpa_supplicant dann ins Essen bricht. Patcht man das (an völlig anderer Stelle) raus, meckert wpa_supplicant zwar nicht mehr, eine IP vom anderen Netz (in meinem Falle ein Freifunk-Netz auf einem anderen Kanal als unserem) kommt aber dennoch selbst in 5 Minuten nicht an, wodurch es dann auch keine Verbindung zum Autoupdater gibt. Irgendwer kluge Ideen?
schau dir mal das script von mir an, das klappt soweit auf einem 841v10 … solltest du aber unbedingt testen … da das erzeugen neuerer if nicht zwingend eine gute idee ist.
(beide Skripte tu das gleiche, in dem ffho mittels lua, mit mir bash-busybox shellscript)
Naja, warum das Rad neu erfinden, ffho-* tut ja, also, woanders. Hier aber:
Tue May 17 08:28:16 2016 local0.info autoupdater-wifi-fallback: going to fallback mode Tue May 17 08:28:16 2016 local0.info autoupdater-wifi-fallback: connectivity check failed Tue May 17 08:28:17 2016 local0.info autoupdater-wifi-fallback: connect to radio0 guetersloh.freifunk.net 16:CE:21:37:17:8A Tue May 17 08:28:17 2016 local0.info autoupdater-wifi-fallback: Permanently changed /lib/netifd/hostapd.sh Tue May 17 08:28:18 2016 kern.info kernel: [12181.440000] device client0 left promiscuous mode Tue May 17 08:28:18 2016 kern.info kernel: [12181.440000] br-client: port 3(client0) entered disabled state Tue May 17 08:28:18 2016 daemon.notice netifd: Network device 'client0' link is down Tue May 17 08:28:18 2016 kern.info kernel: [12181.500000] batman_adv: bat0: Interface deactivated: mesh0 Tue May 17 08:28:18 2016 daemon.notice netifd: Network device 'mesh0' link is down Tue May 17 08:28:18 2016 daemon.notice netifd: Interface 'mesh_radio0' has link connectivity loss Tue May 17 08:28:18 2016 kern.info kernel: [12181.550000] batman_adv: bat0: Removing interface: mesh0 Tue May 17 08:28:18 2016 daemon.notice netifd: Interface 'mesh_radio0' is disabled Tue May 17 08:28:18 2016 daemon.notice netifd: mesh_radio0 (16181): ./batadv.sh: eval: line 1: can't create /sys/class/net/mesh0/batman_adv/mesh_iface: nonexistent directory Tue May 17 08:28:19 2016 kern.info kernel: [12182.260000] IPv6: ADDRCONF(NETDEV_UP): fallback: link is not ready Tue May 17 08:28:19 2016 daemon.notice netifd: Interface 'fallback' is enabled Tue May 17 08:28:20 2016 daemon.info fastd[1174]: resolving host `gw02.4830.org' for peer ... […]
Das Intrface ist da, sieht aber ziemlich karpott aus:
root@17089-FW-Test-801e:~# ifconfig fallback
fallback Link encap:Ethernet HWaddr EA:97:00:A4:80:1E
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@17089-FW-Test-801e:~# iwinfo
fallback ESSID: unknown
Access Point: 00:00:00:00:00:00
Mode: Client Channel: unknown (unknown)
Tx-Power: 20 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0
Ich würde ja sagen, daß aufsetzen eines Client-Interfaces ist gescheitert — aber warum? Klappt es bei Dir denn mit dem Starten eines Client-interfaces auf einem anderen Kanal als dem, auf dem das FF-Netz lief? (Ich spiele hier mit einem Müritz-FW-Knoten im FFGT-Umfeld. Wenn es auf unterschiedlichen Kanälen tut, sollte es auch auf den gleichen tun.)
ich habe die Probleme auch, bisher hat nur geholfen, das connect feature wieder in iw reinzupatchen.
das iw connect „feature“ ist obsolete … man kann auch von „Hand“ in die network und wireless zeug eintragen und dann die if neu starten … das geht mit uci recht komfortabel … ich find gut das iw kleiner wird/ist.
Das problem ist also als solches keines - nur wenn dein jeweiliges skript das nicht berücksichtigt!
BB hat ja iw connect noch, daran liegt es also eher nicht. Zudem nutzt das Package genau nicht iw connect sondern uci. Und via uci sollte es entsprechend unter BB als auch CC tun, nur tut’s bei mir unter BB nicht.
is zwar schon sehr lange her …
ich beobachte auf den schwachen 841’er kisten, das man ersten das client0 if deactivieren sollte solange man ein weiteres auf macht, evtl sogar ibss0 - und das es scheint man bräuchte wpa-supplicant-mini … dann gehts bei mir - ansonsten bekommt er - wenn er ohne baldigen absturz das neue IF hochnimmt schlicht keine Verbindung.
@kb-light hat die gesamten ffho packages mittlerweile auch auf github hochgeladen.
Den ffho-autoupdater findet ihr unter https://github.com/FreifunkHochstift/ffho-packages/tree/master/ffho/ffho-autoupdater-wifi-fallback
dort können nun auch Issues und Pull requests eingereicht werden, um so die Zusammenarbeit mit anderen deutlich einfacher zu machen.
5 „Gefällt mir“
Auch wenn ich mich als Newbie oute: Wie baue ich den erforderlichen Patch ein?
1 „Gefällt mir“
Das würde mich auch interressieren, Ich hab das so versucht:
Eine Datei im site folder mit dem Namen modules erstellt (oder bearbeitet):
GLUON_SITE_FEEDS='ffho' # neu erstellen oder weiteres Kürzel hier ergänzen
#ffho-luci-autoupdater-wifi-fallback
PACKAGES_FFHO_REPO=https://git.c3pb.de/freifunk-pb/ffho-packages
PACKAGES_FFHO_COMMIT=45ed1bc77e9aa612a9daafc0e070df1401babf8c
PACKAGES_FFHO_BRANCH=master
dann in der site.mk das gluon-luci-autoupdater Paket ausgetauscht durch:
ffho-luci-autoupdater-wifi-fallback
Und dieses Paket ergänzen:
ffho-autoupdater-wifi-fallback
Dann die gluon 2016.2.x Firmware bauen mit dem iw Patch anwenden:
cd gluon
git checkout v2016.2.x
git checkout -b v2016.2.x-patched
wget --no-check-certificate https://git.c3pb.de/freifunk-pb/site-ffho/raw/stable/patches/0001-openwrt-patch-iw.patch
git am 0001-openwrt-patch-iw.patch
make GLUON_TARGET=ar71xx-generic update
make GLUON_TARGET=ar71xx-generic clean
make GLUON_TARGET=ar71xx-generic V=sIst es korrekt, wenn ich davon ausgehe, dass das in einem „mehrstufigen“ Mesh nur sicher funktioniert, wenn man gleichzeitig auch einen „Offline-SSID-changer“ einsetzt?
(Szenario was ohne einen solchen passiert mit zwei nah beeinander stehen Wifimesh-Knoten und einem (funktechnisch) entfernten VPN-Knoten, der als erste von den Dreien geupdated wurde: Wird sich hier jedeR selbst ausmalen können.)
1 „Gefällt mir“
zur erläuterung:
Das Scenario sind drei Router, wo nur ein router einen Uplink hat. Ausserdem haben die beiden nur-meshenden router eine sehr schwache Verbindung zum Uplink.
Wenn nun der Router mit Uplink zuerst geupdatet ist dann sehen sich die anderen beiden router ja noch gegenseitig und versuchen sich ev. dann immer in das netz des anderen (auch ohne upllink) einzuloggen um damit nach einem update zu suchen … natürlich vergeblich
(ein SSID-Changer würde dagegen wirken)
1 „Gefällt mir“