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

Ich versuche zur Zeit, ffho-autoupdater-wifi-fallback mit Gluon v2015.1 bzw. OpenWRT BB zum mitspielen zu bewegen. Das ist nicht trivial :frowning: 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=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.)

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“

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

1 „Gefällt mir“

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.