Auch in Aachen steht die Umstellung auf 802.11s an, dafür testen wir derzeit den parallelen Betrieb von 802.11s und ibss Mesh Netz. Erste Test zeigen, dass dies auch auf 841ern stabil läuft. Es fehlen noch Test mit 841er die auch die VPN Tunnel herstellen.
Vorab werde ich daher noch eine beta und stable bauen die lediglich ibss fürs Mesh nutzt, auch damit ergeben sich neben denen in den Gluon enthaltenen etliche Änderungen in unserer site: https://github.com/ffac/site/commits/master
Dies sind insbesondere:
Neue URL für den openwrt mirror zum Pakete nachladen
Möglichkeit Module nachzuladen
Entfernen der Höhe aus dem Config Mode
Das Feld für die Kontaktinfo ist nun obligatorisch
Entfernen der 802.11b Datenraten
Entfernen der IPv4 Nextnode Adresse, aufgrund derSegmentierung war sie nutzlos
Vorraussichtlicher Ablauf:
experimental ibss (done)
beta ibss
. experimental ibss+80211s
stable ibss
. beta ibss+802.11s
stable ibss+802.11s
Sofern das ganze stabil läuft kann dann beispielsweise mit dem nächsten Gluon Update das ibss mesh entfernt werden.
Hinweis von der Seite:
Wenn ihr irgendwo „massiv wifivemeshte“ lokale Wolken haben solltet mit vergleichsweise wenigen Uplinks:
Dann können sich da Dinge aufschaukeln, so dass viele Clients gefühlt nur rund 50% der Zeit funktionsfähiges Netz haben. Die Anzahl der möglichen Routen „zum Gateway“ multipliziert sich mit Faktor 2^(wifihops). Und das führt leicht zu TQ-Hopping.
Traf in ffdus Wolken >20 Nodes und <20% VPN-Uplinks. Da Flippten im Batman potentiell an jedem Hop einer Kette die Route zwischen IBSS und 11s. Bei 1-2 Hops tragbar, bei 3-4 Hops und 2-3 möglichen Wegen vom Node zum Uplink: Katastrophe.
Langer Rede, kurzer Sinn: Man sollte die Zeit des Parallelbetriebs von vornherein möglichst kurz planen. Also das nächste Update gleich hinterherschieben wenn nicht zu erwarten ist, noch weitere einzusammeln. (d.h. nicht mit „11s-only“-fw nach nächte Feature-Release abwarten.)
Außerdem haben wir einige Anpassungen an unserer Site vorgenommen:
Entfernen der 802.11b Raten
Bereitstellung eines Build Skriptes in der Site
Bereitstellung der opkg modules zur Nachinstalltion
Entfernen der durch die Segmentierung nicht mehr sinnvollen IPv4 Next Node Adresse, nun gibt es nur noch die IPv6 Adresse: http://[fdac::ac]
Entfernen des Feldes für die Höhe, da es nicht näher definiert ist
Obligatorischer Eintrag im Kontakt Feld
Das Autoupdate wird erfolgen sobald wir aufgrund von Test sicher sein können dass alles Reibungslos funktioniert, daher ist es hilfreich wenn schon vorab manuell ein Umstieg getriggert wir. Dafür liegt auf einem der beiden Updateserver ein Manifest mit einer Signatur bereit. Einspielen per ssh:
uci set autoupdater.settings.branch='stable'
uci del autoupdater.stable.mirror
uci add_list autoupdater.stable.mirror='http://1.updates.freifunk-aachen.de/stable/sysupgrade'
uci set autoupdater.stable.good_signatures='1'
autoupdater -f
Das Verteilen der Stable Version der 2016.2.2 das letzte Nach begonnen wurde habe ich nun aufgrund der Instabilität des Autoupdaters gestoppt, eine Experimental auf Basis der 2016.2.3 ist bei mir getestet und wird nun per Autoupdate verteilt.
Alternativ vorgezogenes Autoupdate mit nur einer Signatur per ssh:
uci set autoupdater.settings.branch='beta'
uci del autoupdater.beta.mirror
uci add_list autoupdater.beta.mirror='http://1.updates.freifunk-aachen.de/beta/sysupgrade'
uci set autoupdater.beta.good_signatures='1'
autoupdater -f
Feedback ist sehr willkommen, da wir vor den Rosenmontagsumzügen auch das Stable Update durch haben möchten.
Die Beta ist mittlerweile weitgehend verteilt, die stable steht zur Verfügung und soll in einigen Tagen verteilt werden, daher gilt zum testen wieder:
uci set autoupdater.settings.branch='stable'
uci del autoupdater.stable.mirror
uci add_list autoupdater.stable.mirror='http://1.updates.freifunk-aachen.de/stable/sysupgrade'
uci set autoupdater.stable.good_signatures='1'
autoupdater -f
Da sich gezeigt hat, dass die 2016.2.3 aufgrund von zu häufigen Aufrufen von respondd unnötig viel systemlast verursacht steht nun das Update auf 2016.2.4 an. Der bereich mit erhöhter Load ist die Einsatzzeit von 2016.2.3 mit dem Update auf 2016.2.4 sinkt sie wieder auf den alten Stand ab:
Im Experimental ist diese Version bereits per autoupdate verteilt. Momentan steht sie zum manuellen Download oder zum update per Autoupdate mit reduzierte Zahl an Signaturen bereit:
uci set autoupdater.settings.branch='beta'
uci del autoupdater.beta.mirror
uci add_list autoupdater.beta.mirror='http://0.updates.freifunk-aachen.de/beta/sysupgrade'
uci set autoupdater.beta.good_signatures='1'
autoupdater -f
Die 110 Knoten die auf dem Beta Release waren benehmen sich ausgesprochen gut, sprich ein Großteil ist seit dem update durchgängig online, daher stellen wir nun manuell etliche Knoten auf die entsprechende stable um, wer sich beteiligen möchte ist herzlich eingeladen:
uci set autoupdater.settings.branch='stable'
uci del autoupdater.stable.mirror
uci add_list autoupdater.stable.mirror='http://0.updates.freifunk-aachen.de/stable/sysupgrade'
uci set autoupdater.stable.good_signatures='1'
autoupdater -f
Ich habe eine Mesh Verbindung zusammen mit meinem privaten Netz in zwei unterschiedlichen VLAN über eine Gigabit Powerline (dlan) Verbindung laufen. Im privaten VLAN hängt ein SatIP-Server daran, im Mesh-VLAN ein Knoten. In den letzten Monaten hatte ich beim streamen massive Probleme, teilweise bis hin zu total zerhackten Bildern. Ich konnte dieses Verhalten auf das Mesh-VLAN zurückführen. Wenn ich den dahinter liegenden Knoten deaktiviert habe, ging das Streamen.
Keine Ahnung was ihr gemacht habt, es läuft seit diesem Freifunk Update nun wieder exzellent. Keine Aussetzer mehr beim Fernsehbildstreamen. Kann das sein? Sonst habe ich nicht geändert im Netzwerk. Es schaut nach deutlich weniger Last oder besser verteilten Paketen aus. Auch ist der Internet Durchsatz via Freifunk deutlich schneller seit dem Update meiner drei Knoten plus Offloader (und Nachbars Knoten).
Ja genau. Alle Releases die vorher auf den Knoten waren, haben Störungen beim SatIP-Stream verursacht. Dieses Release jetzt nicht mehr. Nur auf meinem Outdoor Knoten (WBS 210) läuft die Experimental Version auf LEDE Basis, die du vor ein paar Wochen testweise für mich gebaut hast.
Die 802.11s Umstellung ist zunächst vertagt, da wir sie nicht ohne einen Fallback Autoupdater durchführen möchten. Andererseits ist es wirklich an der Zeit auf 2017.1.x umzusteigen, um dies zu ermöglichen verteilen wir nun zunächst die aktuellste 2016.2.x Version als Beta:
Diese Update soll auf lange Zeit verfügbar bleiben, damit auch Knoten die lange offline waren zunächst dieses Update laden um einen sicheren Übergang zu 2017.x zu erlauben. Daher haben wir die URL der Updateserver verändert. Bei dieser Gelegenheit haben wir auch gleich die Nutzung von drei unterschiedlichen Domains umgestellt. Diese Umstellung haben wir auch für die Supernodes umgesetzt.
Die erforderlichen drei Signaturen für Beta sind nun vorhanden, das Update wird also in den kommenden Nächten verteilt. Die Stable Version baue ich in den kommenden Tagen.
Nachdem die Beta weitgehend per Autopdate verteilt ist und uns keine Probleme aufgefallen sind folgt nun die baugleiche Stable, zunächst wieder mit reduzierter Zahl an Signaturen.
Vorab Installation wie üblich mittels:
uci set autoupdater.settings.branch='stable'
uci del autoupdater.stable.mirror
uci add_list autoupdater.stable.mirror='http://1.updates.freifunk-aachen.de/stable/sysupgrade'
uci set autoupdater.stable.good_signatures='1'
autoupdater -f