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.
Auch wenn ich mich als Newbie oute: Wie baue ich den erforderlichen Patch ein?
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=s
Ist 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.)
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)
Das alternative Paket GitHub - viisauksena/gluon-v14tov15-helper: gluon-v14tov15-helper, das genau das selbe macht benutzt wpa-supplicant-mini
statt iw
, das ist aber angeblich etwas größer
Alternativ müsste das Paket systematisch alle Freifunk-SSIDs durchprobieren. (oder zumindest mit hinreichendem Zufall würfeln)
Also nicht nur die stärkste Station, die immer nur der ebenfalls uplinklose Router in der gleichen Wohnung.
Ein SSID-Changer sollte nicht nötig sein.
kb-light (IRC) dazu:
nehmen wir mal an 1 knoten (A) mit neuer firmware (und uplink) und 2 mit alter firmware ohne upling (B,C). wenn wir dann auch sicht von C schauen, gibt es 2 SSIDs, die von A und die von B. er verbindet sich also mit B, versucht nen update, das schlägt fehl, also probiert er die nächste BSSID (die SSIDs können ruhig gleich heißen, er ferbindet sich immer gezielt mit einem bestimmten Knoten).somit gibt es da keine probleme.
rubo77:
Ah ok, das heisst die bssid von jedem knoten ist einmalig?
KKkb-light (IRC):
die BSSID kommt von der mac, (des interfaces oder so) die sollte einmalig sein, wenn man die nicht geändert hat Von jedem Gerät. Die setzt sich aus der MAC des Gerätes zusammen.
Und das problem mit den offloadern haben wir serverseitig gelöst, indem die x86&x64 firmware ienfach in dem manifest nicht drin stand und dann nach 1-2h (nach der 4 Uhr update stunde) das manifest durch ein vollständiges ersetzt wurde
wieso austauschen? der normale autoupdater soll ja bleiben.
Ist halt so.
Der neue ersetzt den bisherigen.
(Ist wohl eine erweiterte Kopie)
ffho-luci-autoupdater-wifi-fallback
ersetzt gluon-luci-autoupdater
, das ist die LuCI-Komponente im Config-Mode. gluon-autoupdater
bleibt, zusätzlich kommt ffho-autoupdater-wifi-fallback
.
Ok, bitte Mal schauen, ob das jetzt korrekt ist: Fork von "ffho-autoupdater-wifi-fallback" gesucht - #31 von rubo77
achso - ich hatte das „luci“ ausgeblendet - das luci-Pendant zum fallback habe ich bei uns nicht benutzt.