adsc-Firmware-Overview

Christian Dresel fff at chrisi01.de
Di Mai 7 11:06:38 CEST 2019


hi

On 07.05.19 11:03, 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.
>
ups... ich habs fest in die /etc/config/system gehackt ;) Brauchst also
nicht weiter drüber nachdenken

Gruß

Christian

>  
>
> 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.
>
>  
>
> 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>;
> 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/70d27735/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://{'listname': 'franken-dev-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-dev-freifunk.net/attachments/20190507/70d27735/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev