adsc-Firmware-Overview

Mo Mai 6 14:16:02 CEST 2019

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/4a2deea3/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://{'listname': 'franken-dev-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-dev-freifunk.net/attachments/20190506/4a2deea3/attachment.sig>