adsc-Firmware-Overview

Mo Mai 6 16:06:33 CEST 2019

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/f719b509/attachment.html>