adsc-Firmware-Overview

Mo Mai 6 19:05:01 CEST 2019

Hallo,

1) firstboot

Bei jedem Boot-Vorgang werden die Skripte in /etc/rc.d durchgearbeitet, die dort wiederum aus /etc/init.d automatisch erstellt werden.

Im /etc/rc.d/S10boot werden dabei alle Skripte in /etc/uci-defaults ausgeführt UND DANACH GELÖSCHT.

D.h. alle Skripte in uci-defaults werden NUR beim allerersten Bootvorgang nach factory-Flash/sysupgrade/Reset ausgeführt, und das bevor irgendetwas anderes gestartet wird.

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.

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.

4) Meinst du:

https://github.com/adrianschmutzler/fff-firmware

?

Grüße

Adrian

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/c9aa95b4/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/c9aa95b4/attachment.sig>