Autoupdater Wifi-Fallback

erfolgreich im Einsatz seit v2016.2.x, inzwischen v2017.1.8
erfordert aber einen Gluon-OpenWrt-Patch für das „iw connect“ Feature, der ggf. bei neueren Releases jeweils immer wieder neu angepasst werden muss - also kein triviales Package.

Es geht uns um eine einmalige Geschichte die wir hoffentlich nicht noch einmal wiederholen müssen :wink: .

Habt ihr dazu nähere Infos irgendwo?

was genau fehlt? Doku bei Freifunk Hochstift lesen :wink:

Ahso. Mir war nicht bewusst, dass du nun von Hochstift bist (nachdem ich den Thread verschoben habe).

Nutzt ihr auch den SSID-Changer produktiv? Hierbei etwas zu beachten?

nein, ich bin nicht von Hochstift, aber mehr als das was in deren README steht hatten wir auch nicht zur Verfügung.

ja, nutzen wir, aber wie jemand schon schrieb, es gibt mehrere Varianten die sich stark unterscheiden.
Jedoch ist keine davon so kompliziert wie der fallback autoupdater

Sorry für’s aufwärmen, aber irgendwie suche ich mir den Wolf.

Gluon 2018.2, ffho-autoupdater-wifi-fallback. Es tut im Grunde, aber nur für v4, was bzgl. des Autoupdaters genau gar nicht hilft :frowning:

Thu Sep 10 22:24:05 2020 local0.info autoupdater-wifi-fallback: going to fallback mode
Thu Sep 10 22:24:05 2020 local0.info autoupdater-wifi-fallback: connectivity check failed
Thu Sep 10 22:24:05 2020 kern.info kernel: [325660.056992] IPv6: ADDRCONF(NETDEV_UP): tmp.mesh0: link is not ready
Thu Sep 10 22:24:07 2020 local0.info autoupdater-wifi-fallback: connect to radio0 KreisGT.freifunk.net 56:92:C9:3E:87:60
Thu Sep 10 22:24:07 2020 daemon.notice netifd: Interface 'mesh_radio0' is disabled
Thu Sep 10 22:24:07 2020 daemon.notice netifd: Interface 'mesh_radio0' has link connectivity loss
Thu Sep 10 22:24:07 2020 kern.info kernel: [325661.886811] device client0 left promiscuous mode
Thu Sep 10 22:24:07 2020 kern.info kernel: [325661.891966] br-client: port 4(client0) entered disabled state
Thu Sep 10 22:24:07 2020 kern.info kernel: [325662.287675] batman_adv: bat0: Interface deactivated: mesh0
Thu Sep 10 22:24:07 2020 kern.info kernel: [325662.293484] batman_adv: bat0: Removing interface: mesh0
Thu Sep 10 22:24:07 2020 daemon.notice netifd: Interface 'mesh_radio0' is now down
Thu Sep 10 22:24:08 2020 daemon.notice hostapd: client0: interface state ENABLED->DISABLED
Thu Sep 10 22:24:08 2020 daemon.notice hostapd: client0: AP-DISABLED
Thu Sep 10 22:24:08 2020 daemon.notice hostapd: client0: CTRL-EVENT-TERMINATING
Thu Sep 10 22:24:08 2020 daemon.notice hostapd: nl80211: deinit ifname=client0 disabled_11b_rates=0
Thu Sep 10 22:24:08 2020 daemon.notice hostapd: nl80211: Failed to remove interface client0 from bridge br-client: Invalid argument
Thu Sep 10 22:24:09 2020 user.notice mac80211: Failed command: iw phy phy0 set antenna all all
Thu Sep 10 22:24:09 2020 kern.info kernel: [325664.288566] IPv6: ADDRCONF(NETDEV_UP): fallback: link is not ready
Thu Sep 10 22:24:10 2020 kern.info kernel: [325664.490909] fallback: authenticate with 56:92:c9:3e:87:60
Thu Sep 10 22:24:10 2020 kern.info kernel: [325664.514553] fallback: send auth to 56:92:c9:3e:87:60 (try 1/3)
Thu Sep 10 22:24:10 2020 kern.info kernel: [325664.523681] fallback: authenticated
Thu Sep 10 22:24:10 2020 kern.info kernel: [325664.542801] fallback: associate with 56:92:c9:3e:87:60 (try 1/3)
Thu Sep 10 22:24:10 2020 kern.info kernel: [325664.556471] fallback: RX AssocResp from 56:92:c9:3e:87:60 (capab=0x421 status=0 aid=1)
Thu Sep 10 22:24:10 2020 kern.info kernel: [325664.565242] fallback: associated
Thu Sep 10 22:24:10 2020 kern.info kernel: [325664.569424] IPv6: ADDRCONF(NETDEV_CHANGE): fallback: link becomes ready
Thu Sep 10 22:24:10 2020 daemon.notice netifd: radio0 (16216): fallback (phy #0): unknown event 46
Thu Sep 10 22:24:10 2020 daemon.notice netifd: radio0 (16216): cat: can't open '/var/run/wpa_supplicant-fallback.pid': No such file or directory
Thu Sep 10 22:24:10 2020 daemon.notice netifd: radio0 (16216): WARNING (wireless_add_process): executable path /usr/sbin/wpa_supplicant does not match process  path ()
Thu Sep 10 22:24:10 2020 daemon.notice netifd: radio0 (16216): Command failed: Invalid argument
Thu Sep 10 22:24:10 2020 daemon.notice netifd: Network device 'fallback' link is up
Thu Sep 10 22:24:10 2020 daemon.notice netifd: Interface 'fallback' is enabled
Thu Sep 10 22:24:10 2020 daemon.notice netifd: Interface 'fallback' has link connectivity
Thu Sep 10 22:24:10 2020 daemon.notice netifd: Interface 'fallback' is setting up now
Thu Sep 10 22:24:10 2020 daemon.notice netifd: fallback (16359): udhcpc: started, v1.28.4
Thu Sep 10 22:24:10 2020 daemon.notice netifd: fallback (16359): udhcpc: sending discover
Thu Sep 10 22:24:11 2020 daemon.notice netifd: fallback (16359): udhcpc: sending select for 10.255.6.192
Thu Sep 10 22:24:11 2020 daemon.notice netifd: fallback (16359): udhcpc: lease of 10.255.6.192 obtained, lease time 600
Thu Sep 10 22:24:11 2020 daemon.notice netifd: Interface 'fallback6' is enabled
Thu Sep 10 22:24:11 2020 daemon.notice netifd: Network alias 'fallback' link is up
Thu Sep 10 22:24:11 2020 daemon.notice netifd: Interface 'fallback6' has link connectivity
Thu Sep 10 22:24:11 2020 daemon.notice netifd: Interface 'fallback6' is setting up now
Thu Sep 10 22:24:11 2020 daemon.notice netifd: Interface 'fallback' is now up
Thu Sep 10 22:24:11 2020 daemon.info dnsmasq[708]: reading /tmp/resolv.conf.auto
Thu Sep 10 22:24:11 2020 daemon.info dnsmasq[708]: using local addresses only for domain lan
Thu Sep 10 22:24:11 2020 daemon.info dnsmasq[708]: using nameserver 10.255.0.61#53
Thu Sep 10 22:24:11 2020 daemon.info dnsmasq[708]: using nameserver 192.251.226.23#53
Thu Sep 10 22:24:11 2020 daemon.info dnsmasq[708]: using nameserver 1.1.1.1#53
Thu Sep 10 22:24:33 2020 local0.info autoupdater-wifi-fallback: execute the autoupdater
Thu Sep 10 22:29:11 2020 daemon.notice netifd: fallback (16359): udhcpc: sending renew to 10.255.0.61
Thu Sep 10 22:29:12 2020 daemon.notice netifd: fallback (16359): udhcpc: lease of 10.255.6.192 obtained, lease time 600
Thu Sep 10 22:29:33 2020 local0.info autoupdater-wifi-fallback: connect to radio0 KreisGT.freifunk.net 24:A4:3C:B2:11:D9
Thu Sep 10 22:29:34 2020 daemon.notice netifd: Interface 'fallback' has link connectivity loss
Thu Sep 10 22:29:34 2020 daemon.notice netifd: fallback (16359): udhcpc: received SIGTERM
Thu Sep 10 22:29:34 2020 daemon.notice netifd: Interface 'fallback' is now down
Thu Sep 10 22:29:34 2020 daemon.warn dnsmasq[708]: no servers found in /tmp/resolv.conf.auto, will retry
Thu Sep 10 22:29:34 2020 daemon.notice netifd: Interface 'fallback6' is now down
Thu Sep 10 22:29:34 2020 daemon.notice netifd: Interface 'fallback6' is disabled
Thu Sep 10 22:29:34 2020 daemon.notice netifd: Network alias '' link is down
Thu Sep 10 22:29:34 2020 daemon.notice netifd: Interface 'fallback6' has link connectivity loss
Thu Sep 10 22:29:34 2020 kern.info kernel: [325988.828654] fallback: deauthenticating from 56:92:c9:3e:87:60 by local choice (Reason: 3=DEAUTH_LEAVING)
Thu Sep 10 22:29:36 2020 user.notice mac80211: Failed command: iw phy phy0 set antenna all all
Thu Sep 10 22:29:36 2020 kern.info kernel: [325990.226683] IPv6: ADDRCONF(NETDEV_UP): fallback: link is not ready
Thu Sep 10 22:29:37 2020 kern.info kernel: [325991.498035] fallback: authenticate with 24:a4:3c:b2:11:d9
Thu Sep 10 22:29:37 2020 kern.info kernel: [325991.521558] fallback: send auth to 24:a4:3c:b2:11:d9 (try 1/3)
Thu Sep 10 22:29:37 2020 kern.info kernel: [325991.530691] fallback: authenticated
Thu Sep 10 22:29:37 2020 kern.info kernel: [325991.539114] fallback: associate with 24:a4:3c:b2:11:d9 (try 1/3)
Thu Sep 10 22:29:37 2020 kern.info kernel: [325991.550138] fallback: RX AssocResp from 24:a4:3c:b2:11:d9 (capab=0x21 status=0 aid=3)
Thu Sep 10 22:29:37 2020 kern.info kernel: [325991.558770] fallback: associated
Thu Sep 10 22:29:37 2020 kern.info kernel: [325991.566984] IPv6: ADDRCONF(NETDEV_CHANGE): fallback: link becomes ready
Thu Sep 10 22:29:37 2020 daemon.notice netifd: radio0 (16747): fallback (phy #0): unknown event 46
Thu Sep 10 22:29:37 2020 daemon.notice netifd: radio0 (16747): cat: can't open '/var/run/wpa_supplicant-fallback.pid': No such file or directory
Thu Sep 10 22:29:37 2020 daemon.notice netifd: radio0 (16747): WARNING (wireless_add_process): executable path /usr/sbin/wpa_supplicant does not match process  path ()
Thu Sep 10 22:29:37 2020 daemon.notice netifd: radio0 (16747): Command failed: Invalid argument
Thu Sep 10 22:29:37 2020 daemon.notice netifd: Network device 'fallback' link is up
Thu Sep 10 22:29:37 2020 daemon.notice netifd: Interface 'fallback' has link connectivity
Thu Sep 10 22:29:37 2020 daemon.notice netifd: Interface 'fallback' is setting up now
Thu Sep 10 22:29:37 2020 daemon.notice netifd: fallback (16861): udhcpc: started, v1.28.4
Thu Sep 10 22:29:37 2020 daemon.notice netifd: fallback (16861): udhcpc: sending discover
Thu Sep 10 22:29:38 2020 daemon.notice netifd: fallback (16861): udhcpc: sending select for 10.255.6.192
Thu Sep 10 22:29:38 2020 daemon.notice netifd: fallback (16861): udhcpc: lease of 10.255.6.192 obtained, lease time 574
Thu Sep 10 22:29:38 2020 daemon.notice netifd: Interface 'fallback6' is enabled
Thu Sep 10 22:29:38 2020 daemon.notice netifd: Network alias 'fallback' link is up
Thu Sep 10 22:29:38 2020 daemon.notice netifd: Interface 'fallback6' has link connectivity
Thu Sep 10 22:29:38 2020 daemon.notice netifd: Interface 'fallback6' is setting up now
Thu Sep 10 22:29:38 2020 daemon.notice netifd: Interface 'fallback' is now up
Thu Sep 10 22:29:38 2020 daemon.info dnsmasq[708]: reading /tmp/resolv.conf.auto
Thu Sep 10 22:29:38 2020 daemon.info dnsmasq[708]: using local addresses only for domain lan
Thu Sep 10 22:29:38 2020 daemon.info dnsmasq[708]: using nameserver 10.255.0.61#53
Thu Sep 10 22:29:38 2020 daemon.info dnsmasq[708]: using nameserver 192.251.226.23#53
Thu Sep 10 22:29:38 2020 daemon.info dnsmasq[708]: using nameserver 1.1.1.1#53
Thu Sep 10 22:29:38 2020 daemon.err odhcp6c[16913]: Failed to send RS (Address not available)
Thu Sep 10 22:29:59 2020 local0.info autoupdater-wifi-fallback: execute the autoupdater

Wie gesagt, v4 tut, aber nix von v6 zu sehen:

root@33332-FWTest-a0f3c1058b90:~# ip addr show
[…]
1234: fallback: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 5e:71:cf:f9:41:83 brd ff:ff:ff:ff:ff:ff
    inet 10.255.6.192/20 brd 10.255.15.255 scope global fallback
       valid_lft forever preferred_lft forever
    inet6 fe80::5c71:cfff:fef9:4183/64 scope link 
       valid_lft forever preferred_lft forever
root@33332-FWTest-a0f3c1058b90:~# cat /proc/sys/net/ipv6/conf/fallback/accept_ra
2

Ich hab’ auch schon ebtables mal deaktiviert, hat auch nix geändert :frowning: Any hint appreciated.

Was spricht dagegen den Autoupdater auch auf v4 reagieren zu lassen?

Alles.

(Mesh-only-Knoten können dann wahlweise das Manifest oder das Image nicht ziehen und brechen ins Essen. Zudem klappte es so auch im NAT64-Netz noch immer nicht.)

1 Like

Stelle ich die Frage mal anders: welche Community setzt ffho-autoupdater-wifi-fallback oder tecff-autoupdater-wifi-fallback (oder eine andere Version) denn mit Gluon v2018.2 oder später noch ein — und funktioniert es da?

(Der iw connect-Patch ist bei uns drin, v4 zieht sich der Knoten ja auch.)

Wir setzen es auch in 2020.2 ein :).

1 Like

Interessant, mit Eurer stable kommt auch keine v6-IP an. Merkwürdig. Dann probier’ ich das wohl mal andersrum.

in meinem tecff-autoupdater-wifi-fallback (fork von ffho) fand ich letzte Woche ein Locking Problem und stieß dann auch auf ähnliche Probleme wie du, als Beifang quasi. Vielleicht hat es mit dem Gluon Commit 01336f70ecc7ad1c0b4a3260a8b64ad8002540a6 zu tun?

Anyway, ich teste gerade Fixes die aktuell gut/fertig aussehen, danach werde ich mal auf unsere alten Firmwares zurückgehen um herauszufinden, seit wann es nicht mehr geht :frowning:

Es könnte sein, dass meine Changes/Fixes alle auch mit älteren Gluon-Versionen bis hinab zu v2018.2.x funktionieren, ich werde das aber nicht testen, da kein Bedarf in meiner Community vorhanden ist, wir nutzen v2020.1.x/v2020.2.x

Der iw Patch ist übrigens nicht mehr notwendig seit Gluon v2018.2.x weil das „iw“ aus OpenWrt 18.06.x und 19.07.x den „connect“ Teil nicht mehr missen lässt.

1 Like

Mein Held :wink: Ich hätte morgen sonst in die Runde gefragt, wer denn in den letzen 2 Jahren mal die Funktion des Packages überprüft hat …

tecff-autoupdater-wifi-fallback hatte ich ja vorher drin … Anyway, wenn Du weißt, woran’s liegt, guck ich mal anhand Deiner Commits, wie ich das für 2018 fluffig mache.

ich weiß nicht mehr wann ich zuletzt getestet habe, hole das diese Woche aber noch nach, denn es wäre ja schon wichtig zu wissen, seit wann es nicht mehr geht. Entsprechend bespielte Knoten haben dann ja diese Funktionalität nicht.

Ich meinte nicht meine Changes im Vergleich zu ffho, sondern meine Changes der letzten paar Tage! Die ich aber bisher nur auf einem Single-Band-Testgerät geprüft habe und auch bei uns noch nicht ausgerollt habe, erst zum Wochenende oder so dann auf experimental.

Ich weiß nicht ob bei dir das selbe Problem vorliegt, da ich nicht mit Gluon v2018.2.x getestet habe bisher. Das werde ich aber noch tun wie ich schon schrieb und auch was die Kompatibilität angeht äußerte ich mich ja schon vorsichtig optimistisch.

Ack; IIRC waren die diffs der beiden Trees auch minimal :wink:

Just FTR, mit deaktivierten ebtables auf dem Fallback-Mode-Knoten funktioniert’s auch nicht. Und da Telefone/Laptops v6 bekommen, kann’s eigentlich doch nur auf Seiten des WiFi-Fallback-Knotens liegen?

Zu 2018.2: Das soll unsere letzte 4/32-Version sein, und da hätte ich gerne den WiFi-Fallback-Mode funktional. (In unserer 2016.2.postrelease-stable tat er noch.)

warum 2018.2 ? bei uns laufen auch spätere Releases noch gut auf 4/32, und wenn es euch darum geht auf OpenWrt 18.06.x zu bleiben könntet ihr auch Gluon v2019.1.x benutzen, was wir bis Ende 2020 noch „supporten“ soweit möglich.

so, habe nun herausgefunden, dass das Problem mit „es geht nur IPv4“ bei uns auch bestand, jedoch für uns kein Problem war, da unsere Autoupdater-Server per dual-Stack erreichbar sind. Nebenbei haben wir aber auch einen IPv6-only Eintrag, siehe https://github.com/tecff/site-ffa/blob/stable/site.conf#L145-L147
In der aktuellsten Version unseres tecff-autoupdater-wifi-fallback (v5, commit 546f8585d575648d7e54febcebd2865307c7d03d ) ist dies aber behoben, IPv6 geht damit auch.

Das eigentliche Problem warum ich aufmerksam wurde war aber beim Locking und bestand seit commit 9d309cdf19b4280c3a0ea3bc7c150a2392317d39 (2018…) und ist nun auch gelöst.

Details siehe Commit-History.
https://github.com/tecff/gluon-packages/commits/v2020.2.x/tecff-autoupdater-wifi-fallback

Ich gehe weiterhin davon aus, dass man die Changes auch für ältere Gluon-Versionen bis v2018.2.x benutzen kann, wenn mir jemand das bestätigt durch Test, cherry-picke ich die Commits in unsere älteren Branches des tecff/gluon-packages Repo.

1 Like

Das haben wir um 2016 sein gelassen, da dann durch mesh-only Knoten mal kein Manifest, mal kein Image gezogen werden konnte und Updates mehr so zufällig wurden.

hm, nie gehabt dieses Problem… vielleicht weil wir zusätzlich die IPv6-only IP drinstehen haben.

Ich bau’ das bei uns gerade mal durch, wird im Erfolgsfalle 'n gutes Stündchen dauern, sind leider nur 24 betagte Cores, und werde das spätetens morgen Nachmittag testen.

Die übliche lange Geschichte voller Mißverständnisse :wink: Sprich: Eigene Packages, die u. a. eine grundlegend andere Config-Mode-Philosphie umsetzen (Konfiguration über WAN als dhclient) und ein Geokoordinaten-zentriertes, geführtes Setup (erst Koordinaten angeben, damit Mesh vom Server bestimmt werden kann; dann syntaktisch richtige Mailadresse mit einer existierenden Mail-Domain angeben (ohne MX nix los), dann erst kann der Wizard beendet werden). Das ist alles nicht so ganz einfach, wenn man a) der OpenWrt-Entwicklung nicht folgt und b) von LuCI und Lua auf den Niveau eines 4-Wochen-VHS-Kurs-Besuchers Ahnung hat. 2018.2 ist seit Monaten bei uns in allem außer stable, scheint auch in der 841-Liga zu tun (wo 2017 IIRC ja eher so bääh war), und zu 2019.x scheint es kein wirkliches Manko zu haben.

Oder, ganz kurz: Stable ist 2016.2; wir wollen (müssen) ASAP auf was Neueres und dabei von fastd auf L2TP (WG dann als Trial) und von Compat 14 auf 15 (batman-adv 2013 auf 2018+). Bei einer 2018er Basis haben wir ein gutes Gefühl. Wegen der doppelten Änderung, und weil wir das nicht über den Firmwareserver steuern wollen, ist das fragliche Paket zwingend in funktional notwendig. Heißt, es wird erst ein Upgrade auf 2018.2 geben, und dann ein Update mit Domainsplit, Compat-Level-Upgrade und anderer VPN-Technik kurz hintendran.

Danach steht dann 2020.2 auf dem Plan, mit, als Ziel, weiterer Reduktion der Eingriffe in den Gluon-Basis-Code.