adsc-Firmware-Overview

freifunk at beibecks.de freifunk at beibecks.de
Mo Mai 6 19:28:23 CEST 2019


Hallo,


danke für die Antworten.

Am 06.05.2019 um 19:05 schrieb Adrian Schmutzler:
>
> Hallo,
>
> 2) upgrade
>
> ja, korrekt, allerdings /etc/adscup.sh
>
> Bei Update der GW-Firmware ist zu beachten, dass nach dem Update 
> configuregateway nicht automatisch ausgeführt wird. Das war aber 
> bisher auch so. Dadurch ist das GW nach dem Update aber erstmal nur 
> erreichbar, wenn du direkten Zugriff per Kabel hast oder über die IP 
> am WAN-Port.
>
> Hier suche ich noch nach einer guten Lösung.
>
Das gilt ja aber nur für dieses Update, oder auch für die Kommenden?
>
> 3) sectorfile
>
> Die Umsetzung sollte der Beschreibung im Wiki entsprechen. Allerdings 
> würde ich von der Verwendung eher abraten, da das mehr Schaden als 
> Nutzen bringt, wenn man nicht ganz genau weiß, was man tut.
>
Ja, aber gut das für Einzellösungen im Hinterkopf zu haben.
>
> 4) Meinst du:
>
> https://github.com/adrianschmutzler/fff-firmware
>
Ja, danke
>
> ?
>
> Grüße
>
> Adrian
>
Grüße,
Sebastian
>
> *From:*SebaBe [mailto:freifunk at beibecks.de]
> *Sent:* Montag, 6. Mai 2019 16:07
> *To:* Adrian Schmutzler <mail at adrianschmutzler.de>; 
> franken-dev at freifunk.net
> *Subject:* Re: adsc-Firmware-Overview
>
> Hi Adrian,
>
> danke für die Zusammenfassung.
>
> Ich hab da direkt mal noch Frgen dazu:
>
> 1) firstboot, was genau macht das?
>
> 2) upgrade
>
> sysupgrade.sh -> offzielle FW
> adsc.up -> deine FFF-FW / GW-FW abhängig vom installierten Branch
>
> korrekt?
>
> Wenn ich es richtig gelesen habe, kann ich also sowohl v2 und 
> dezentral vollautomatisiert updaten ohne nacharbeiten?
>
> 2) nodewatcher -> gibts da eine Doku dazu?
>
> 3) Sectorfile
>
> - ist die Umsetzung identisch zum Wiki?
> https://wiki.freifunk-franken.de/w/KeyXchangeV2#Sectorfile
>
> 4) kannst du mir bitte nochmal den Link geben wo ich den Code online 
> lesen kann?
> Müsste ja vermutlich in Github liegen oder?
>
> Danke,
> Sebastian
>
> On 06.05.19 14:16, Adrian Schmutzler wrote:
>
>     Hallo zusammen,
>
>     aus aktuellem Anlass möchte ich in dieser Mail für Interessierte
>     einen Überblick über die Unterschiede meiner aktuellen FW zum
>     offiziellen Stand geben.
>
>     Wen dies nicht interessiert, der darf diese Mail gerne ignorieren.
>
>     Die FW liegt hier:
>
>     https://github.com/adrianschmutzler/fff-firmware
>
>     Die folgenden Punkte sollen grob und abschnittsweise die
>     Unterschiede wiedergeben, sodass der Leser einen Überblick
>     bekommt. Ich gehe kaum auf technische Details ein und lasse
>     diverse kleinere Unterschiede weg:
>
>     1. Netzwerk-Setup
>
>     Meine aktuelle FW nutzt das „neue“ Netzwerk-Setup, dass zu 95 %
>     bereits auf der Liste diskutiert wurde. Im Gegensatz zur aktuellen
>     FW wird dabei die gesamte Config beim First-Boot geschrieben, es
>     gibt kein boot-Skript o.ä. mehr. Möchte jemand seine Config vom
>     Standard weg ändern, muss er dies ebenfalls per Skript machen
>     (siehe dazu /etc/firstbootfff).
>
>     Im Zuge dieser Umstellung werden alle network.* Dateien entfernt,
>     das Setup erfolgt über uci-default Skripte. Auch network.mode und
>     network.config entfallen komplett.
>
>     Auch die Benennung der Blöcke in /etc/config/network wurde
>     geändert; diese enthalten nun nicht mehr den Namen des eth,
>     sondern heißen einfach vlan1, vlan2 etc. So kann man die
>     VLAN-Ports ändern, ohne das eth zu kennen.
>
>     2. Wireless-Setup
>
>     Ebenfalls überarbeitet wurde das Setup des Wifi. Auch hier
>     entspricht dies konzeptionell den bereits im Patchwork
>     befindlichen Patches:
>
>     Bisher wurden bei jeder Rekonfiguration (z.B. neues Hoodfile) alle
>     Interfaces komplett gelöscht und dann neu in die config
>     geschrieben. Der neue Ansatz schreibt hingegen die config einmal
>     am Anfang und aktualisiert dann nur noch die relevanten options in
>     der config. An- und abschalten von Interfaces erfolgt über die
>     option disabled.
>
>     In der Praxis ist das mehr eine organisatorische als eine
>     funktionale Änderung, aber ich erachte die neue Lösung als
>     wesentlich angenehmer zu lesen und zu warten. Wie beim Netzwerk
>     wird hier alles per uci-defaults während des First-Boot erstellt.
>
>     Als Konsequenz gibt es keine unterschiedlichen Interfaces für ibss
>     und 802.11s mehr, beides heißt wXmesh.
>
>     3. /etc/firstbootfff
>
>     Nach der Abschaffung der Netzwerk-Config Dateien wurde eine
>     Möglichkeit benötigt, update-feste Änderungen der
>     Port-Konfiguration zu definieren. Anstelle hier wieder ein
>     spezifisches Config-File anzulegen, existiert nun die Datei
>     /etc/firstbootfff, die beim firstboot ausgeführt wird. Dort kann
>     man beliebige Befehle eintragen. Eine Änderung der
>     Portkonfiguration kann so z.B. durch uci set
>     network.vlan1.ports=‘0t 1‘ etc. erzielt werden. Für one-port
>     Devices können dort Funktionen gesourct werden. Uci commit nicht
>     vergessen. (Bestehende Einstellungen sollten (!) automatisch
>     migriert werden.)
>
>     Weiterhin bietet das Skript die Möglichkeit, auch beliebige andere
>     FirstBoot Befehle auszuführen. So lege ich hier z.B. für mein
>     Gateway die babeld redistribute Filter für public IPv6 an.
>
>     Achtung: Das Skript läuft während der uci-defaults. Es werden also
>     nur configs gesetzt, alles andere ist noch aus. Also keine
>     /etc/init.d/dings restart oder reload_config hier reintun.
>
>     4. GW-Firmware
>
>     Ich habe aus den Patches der off. Liste und meinen Änderungen eine
>     neue GW-Firmware zusammengebaut. Diese entspricht im funktionalen
>     Umfang der „alten“ Variante, d.h. mit Batman usw. Da Fabian sich
>     (wenn ich das richtig verstanden habe) ohnehin in eine Richtung
>     ohne Batman entwickeln wollte, treten wir so auch weniger in
>     unmittelbare „Konkurrenz“.
>
>     Hierzu keine weiteren Details an dieser Stelle, lediglich der
>     Hinweis, dass ab jetzt auch /etc/hoodfile verwendet wird und das
>     Hoodfile von der alten Location automatisch migriert wird.
>
>     Ich möchte hier auch explizit Tims und Fabians Arbeit
>     diesbezüglich würdigen, schließlich ist die GW-Firmware ihr
>     Projekt und ich habe sie nur oberflächlich angepasst.
>
>     5. sysupgrade
>
>     Ich habe beim Umbauen entdeckt, dass beim sysupgrade eine Reihe
>     von config-Files kopiert wurde, ohne dass dies zunächst erkennbar
>     war. Ich habe nun die /sbin/sysupgrade so angepasst, dass
>     tatsächlich nur das kopiert wird, was in /etc/sysupgrade.conf
>     steht. Hierbei gilt grundsätzlich: Solche Änderungen gelten
>     grundsätzlich immer erst für das übernächste Update, da ja immer
>     die alte sysupgrade/sysupgrade.conf bestimmt, was übernommen wird.
>
>     6. Update-Skript
>
>     Meine Firmware besitzt ein eigenes Update-Skript: /etc/adscup.sh
>
>     Dort kann per optionalem Parameter auch die Version ausgewählt
>     werden: /etc/adscup.sh adsc14
>
>     Das normale Update-Skript sollte auch funktionsfähig sein und die
>     jeweilige neueste off. Firmware holen. Eigentlich sollte ein
>     Cross-Update in beide Richtungen funktionieren.
>
>     Funktional unterscheidet sich mein Skript dadurch, dass das
>     eigentlich Update-Skript erst vom Server heruntergeladen wird.
>
>     7. OpenWrt
>
>     Meine FW (auch GW) nutzt openwrt-18.06 wie auch die off. Firmware.
>     Lediglich der Stand innerhalb des Trees ist etwas neuer.
>
>     Darüber hinaus biete ich parallel experimentelle Versionen auf
>     Basis des Masters an, sowohl für ar71xx (adsc14) als auch für das
>     neue ath79 target (adsc15). Der Freifunk-Teil der FW unterscheidet
>     sich dabei nicht (bis auf nötige Anpassungen, z.B. neueres
>     Batman), wer möchte kann also mit dem neuen Zeug experimentieren.
>
>     Als Konsequenz aus diesem Mehrfach-Support wurde u.a.
>     fff-boardname angepasst, sodass es mit allen targets umgehen kann.
>
>     Ich verwende die Subtargets wie von OpenWrt vorgesehen. Es gibt
>     also ein bsp ar71xx (=generic) und ein bsp ar71xx-tiny.
>
>     Tiny devices bauen nur in mainline, danach ist wohl der Kernel zu
>     groß. Der wdr4900 ist ab Kernel 4.14 kaputt (baut aber!).
>
>     8. 5 GHz/ath10k
>
>     In der neuesten Firmware verwendet alle Geräte den stock-ath10k
>     Treiber und die entsprechende Firmware. Auch wenn in openwrt-18.06
>     802.11s noch mit CT funktioniert, gibt es auf manchen Geräten
>     Probleme und eigentlich ist der Betrieb von AP und mesh-point hier
>     wohl auch nicht vorgesehen. Spätestens mit dem aktuellen
>     openwrt-master geht das dann wohl auch ganz kaputt, daher gleich
>     der Wechsel. (Leider spackt der C60v2 immer noch ein bisschen rum …)
>
>     9. One-Port/Two-Port
>
>     Alle One-Port devices sind default CLIENT (wie in der off. FW).
>     Alle Two-Port devices sind default 1=WAN, 2=BATMAN.
>
>     10. Nodewatcher
>
>     Zusätzlich: simple-tc-Status.
>
>     Bei der loadavg wird der 5 min-Wert angezeigt, bei der off.
>     Firmware der 15-min Wert.
>
>     Babel neighbors werden angezeigt.
>
>     11. fff-wififix
>
>     Da das 2.4 GHz radio gelegentlich einfach ausfällt, repariert die
>     Package das alle 6 Stunden, wenn bestimmte Bedingungen erfüllt sind.
>
>     (Das Intervall ist deshalb nicht häufiger, da beim „Reparieren“
>     ein Speicherleck auftritt)
>
>     12. fff-macnock
>
>     Da bei bestimmten Geräten das Log zugespammt wurde, habe ich
>     standardmäßig das Logging deaktiviert. Wer dies wieder möchte,
>     kann es einfach im /etc/init.d/macnock ändern.
>
>     13. Spezifische Wireless-config
>
>     Meine Firmware enthält Optionen, um einzelne radios oder auch nur
>     z.B. w2ap abzuschalten. Dies ist entweder in /etc/config/fff
>     möglich oder direkt im WebUI (letzteres nur für die radios).
>
>     14. Build-Varianten
>
>     Wie die Varianten „node“ und „layer3“ in der off. FW existieren
>     bei mir drei Varianten „adsc“, „jubtl“ und „gw“. Diese selektieren
>     entsprechend bestimmte Packages, sodass alle Packages parallel in
>     der FW entwickelt werden können. So wird z.B. der public-Key mit
>     der Packages fff-jubtl nur installiert, wenn auch die Variante
>     „jubtl“ ausgewählt wurde.
>
>     15. sector file
>
>     Meine Firmware kann nach wie vor mit dem sector File umgehen.
>     Diese Funktion ist aber nach wie vor nur für sehr spezielle
>     Einzelfälle geeignet.
>
>     Für Details einfach fragen oder im Code nachkucken.
>
>     Beste Grüße
>
>     Adrian
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://{'listname': 'franken-dev-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-dev-freifunk.net/attachments/20190506/e23bacbb/attachment.html>


Mehr Informationen über die Mailingliste franken-dev