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