adsc-Firmware-Overview
Christian Dresel
fff at chrisi01.de
So Mai 12 13:26:11 CEST 2019
Hi
danke :)
Ich hab noch etwas auffälliges, mein OutdoorWest
https://monitoring.freifunk-franken.de/mac/98ded0889ae0 klont sich im
Monitoring.
Zudem ist mir hier ein hoher loadavg aufgefallenm (weit über 1). Ich hab
mir top angeguckt und unter %VSZ ist mir beim Programm
/usr/sbin/rssileds über 50% aufgefallen.
Da es hier anscheinend nur um die LEDs geht, hab ich das einfach mal
abgeschossen und schon war der load wieder niedrig.
Hatten wir da nicht schon mal was mit den LEDs und Last? Ob das klonen
und load zusammen hängt, kann ich nicht sagen ich kanns mir aber
durchaus vorstellen.
Gruß
Christian
On 07.05.19 11:34, mail at adrianschmutzler.de wrote:
>
> 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/20190512/8b73dd2e/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/20190512/8b73dd2e/attachment.sig>
Mehr Informationen über die Mailingliste franken-dev