adsc-Firmware-Overview

Di Mai 7 11:34:51 CEST 2019

Hallo Christian,

es kann auch nicht funktionieren, denn ich schreibe in eine Variable $firstbootscript, die aber nie mit dem Datei-Namen befüllt wird.

https://github.com/adrianschmutzler/fff-firmware/blob/mainline/src/packages/fff/fff-network/files/etc/uci-defaults/25-migrate-network

Man müsste wohl nur in Zeile 23

firstbootscript=/etc/firstbootfff

ergänzen.

Sieht wohl so aus, als müsste ich heute ein bisschen nachsitzen…

Also vll. noch mit dem Flashen warten, dann kann man das nochmal in nicht kaputt testen.

Vielen Dank für die Hinweise.

Grüße

Adrian

From: Christian Dresel [mailto:fff at chrisi01.de] 
Sent: Dienstag, 7. Mai 2019 11:29
To: mail at adrianschmutzler.de
Cc: franken-dev at freifunk.net
Subject: Re: adsc-Firmware-Overview

Hi Adrian

On 07.05.19 11:03, mail at adrianschmutzler.de <mailto:mail at adrianschmutzler.de>  wrote:

	Hallo Christian,

	PoE Passthrough:

	Wenn du das PoE passthrough in /etc/config/system aktivierst, ist es auch nicht updatesicher. Das war schon immer so.

	Wenn du es update-sicher willst, gibt es

	uci set fff.poe_passthrough.active=1

	Das setzt dann per uci-defaults dein poe_passthrough:

	https://github.com/adrianschmutzler/fff-firmware/blob/mainline/src/packages/fff/fff-config/files/etc/uci-defaults/98-configure-fff#L25

	Nachträglich musst du natürlich beides setzen, hierfür gibt es ein Skript:

	https://github.com/adrianschmutzler/fff-firmware/blob/mainline/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/permanent_poe_passthrough.sh

	Also zum (permanenten) Einschalten:

	usr/lib/fff-support/permanent_poe_passthrough.sh

	Und zum Abschalten:

	usr/lib/fff-support/disable_poe_passthrough.sh

	Ist alles auch in der off. FW so ;-)

	Falls du vorher die fff-config doch bereits verwendet hattest, bitte nochmal rückmelden.

	Zwecks Ports:

	Ich habe das migration Skript nur hingeklotzt und nicht getestet (stand auch im Patch). Muss nochmal kucken, vll. ist das für die CPE doch irgendwie kaputt.

	Eigentlich sollte die alte Portkonfiguration automatisch in die neue /etc/firstbootfff übertragen und dann auch gleich angewandt werden.

es scheint auch One Port Geräte zu betreffen:

root at UFBOst-Outdoor:~# batctl if
w2mesh: active
root at UFBOst-Outdoor:~# bridge link show
2: eth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-mesh state forwarding priority 32 cost 19 
12: bat0 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-mesh state forwarding priority 32 cost 100 
14: w2ap state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br-mesh state forwarding priority 32 cost 100 
root at UFBOst-Outdoor:~# 

war vorher Batman und ist jetzt Client

Gruß

Christian

	Vielen Dank für die Rückmeldung

	Adrian

	From: Christian Dresel [mailto:fff at chrisi01.de] 
	Sent: Dienstag, 7. Mai 2019 10:35
	To: Adrian Schmutzler <mail at adrianschmutzler.de> <mailto:mail at adrianschmutzler.de> ; franken-dev at freifunk.net <mailto:franken-dev at freifunk.net> 
	Subject: Re: adsc-Firmware-Overview

	hi

	ich hab natürlich gleich mal mit einen "recht komplizierten" Device angefangen und möchte mal 2 Warnungen aussprechen (ich denke das ist gewolltes verhalten oder war schon immer so, kommt hier aber nicht wirklich rüber):

	Geflasht wurde eine CPE210 v1 die an beiden Ports Batman Devices hat. Nach den flashen war der erste Port WAN (den 2. weiß ich gerade nicht), musste man anpassen (obwohl Einstellungen behalten angewählt war). Ebenfalls war PoE Passthrough im Einsatz, auch dies wurde durch das Update deaktiviert und musste ich per Hand wieder einschalten.

	Wer also ein (ähnliches) Setup hat und darauf angewiesen ist Vorsicht!

	Umstellen geht aber recht gut, man geht per SSH auf den Freifunkrouter vor der CPE, macht ping6 ff02::1%eth0.3 (also das BatmanInterface, in diesen Fall durch 4900er eben eth0.3) und connectet dann auf die Antwort per SSH. Umstellen per "setcpev1 BATMAN BATMAN" ging dann einwandfrei und sieht jetzt alles gut aus. Ich denke die ganzen set* für Ports setzen sollte man noch ordentlich dokumentieren.

	PoE Passthrough lies sich dann auch wieder problemlos per /etc/config/system anschalten und läuft einwandfrei.

	Ansonsten werde ich jetzt mal nach und nach weiter updaten und beobachten. Wenn mir noch was auffällt melde ich mich wieder

	Gruß

	Christian

	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/20190507/7c330ae1/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : openpgp-digital-signature.asc
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/20190507/7c330ae1/attachment.sig>