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

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 …

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 Likes

Auch wenn ich mich als Newbie oute: Wie baue ich den erforderlichen Patch ein?

1 Like

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