Re: Firmware: 17.01.6, Unterstützung neuer Router: Doku und Stolpersteine

[michael at fritscher.net]

Hi,

ich werde die Commits mal überfliegen. Ich wäre jetzt davon ausgegangen, 
das im 17.01.6 nicht allzuviel ist, was nicht eh auch im 18.06 ist.
Auf dem Carambola funktioniert es problemlos - mesh über WLAN, 
WAN-Uplink, LAN+WLAN Client, Monitoring.
Beim applien unserer Patches kam nur bzgl. eines Patches die Meldung, 
dass der schon drinne ist, ansonsten lief das durch. Ist also 
überschaubar.

openwrt-packages hab ich mit hochgezogen, die routing hab ich übersehen 
(das steht direkt unten im buildscript, nicht wie die anderen beiden 
Repos oben). Wenn ich mir 
https://git.openwrt.org/?p=feed/routing.git;a=shortlog;h=refs/heads/lede-17.01 
so anschaue wurde da in batman-adv bissle was gemacht, aber letzte 
Änderung war im Juni, weswegen ich davon ausgehe, dass das alles auch in 
18.06 ist?

Viele Grüße,
Michael
Am 2018-09-08 13:32, schrieb mail at adrianschmutzler.de:
> Hallo,
> 
> im Prinzip musst du alle Commits vom aktuellen Stand (der Snapshot,
> den wir verwenden) bis 17.01.6 mal durchblättern, ob sich was
> verändert hat, dass unsere Implementierung kaputt macht. Oder du
> ziehst einfach hoch und schaust mal, was kaputt geht.
> 
> Zum Hochziehen musst du im buildscript die CommitID austauschen und
> ggf. OpenWRT-Patches rebasen.
> Zudem musst du überlegen, ob du die openwrt-packages und
> openwrt-routing auch mit hochziehen willst. Da ist dann im Prinzip das
> gleiche Vorgehen nötig, nur das dort viel weniger relevante Commits
> gemacht werden und das Durchschauen sehr viel schneller ghet.
> 
> Oder du nimmst gleich eines des OpenWRT 18.06 builds (eine Patchserie
> aus dem Patchwork), zumindest meines funktioniert sicher
> out-of-the-box und da habe ich alles durchgesehen.
> 
> Grüße
> 
> Adrian
> 
>> -----Original Message-----
>> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf
>> Of michael at fritscher.net
>> Sent: Samstag, 8. September 2018 12:12
>> To: franken-dev at freifunk.net
>> Subject: Firmware: 17.01.6, Unterstützung neuer Router: Doku und
>> Stolpersteine
>> 
>> Moin,
>> 
>> die von uns verwendete Version von OpenWRT (17.01.3) baut nicht mehr
>> unter Ubuntu 18.04 oder aktuellem Arch.
>> 17.01.6
>> (https://github.com/openwrt/openwrt/commit/184fe11483b9595f31a02835
>> 6f8cc18fb18536e3
>> und
>> https://github.com/openwrt/packages/commit/40da7ecf21ffe1f3523ffa430c
>> 406e1db58ce3d4,
>> changelog https://openwrt.org/releases/17.01/changelog-17.01.6) ist 
>> wieder
>> baubar.
>> 
>> Was muss da außer dem anpassen der beiden Hashes und das raushauen
>> eines von uns eingebauten Patches, der in 17.01.6 bereits enthalten 
>> ist,
>> gemacht werden?
>> Das Kompilat funktioniert zumindest auf einem Carambola anstandslos 
>> (ich
>> habe lokal leider keine offiziell unterstützte HW).
>> 
>> Damit komme ich schon zum nächsten Thema: Bauen für ein neues Target. 
>> In
>> der README.md steht nur, wie ein bereits bestehendes Target um ein 
>> neues
>> Modell erweitert wird, nicht aber wie für ein weiteres Target gebaut 
>> werden
>> kann.
>> 
>> Das ist insbesondere deswegen schade, weil es recht einfach ist - wenn 
>> man
>> ein paar Stolpersteine kennt.
>> 
>> <Anleitung mit Kommentaren zu Stolpersteinen>
>> Voraussetzungen:
>>    * Der Router muss bereits von OpenWRT unterstützt werden und ist
>> installiert. Am besten die Version, die die Firmware einsetzt (derzeit
>> 17.01)
>>    * per ifconfig sich sämtliche fe80er Adressen holen
>>    * Rechner mit Linux
>> 
>> Sehr empfohlen:
>>    * Zugriff auf die serielle Konsole - ansonsten ist die Gefahr groß 
>> sich
>> auszusperren. Der Zugriff ist meist auf der OpenWRT Seite für das
>> entsprechende Gerät beschrieben.
>> 
>> Schritte:
>>    * kopiere eine der bsp-Dateien nach bsp/board_<machine-name> -
>> letzteres sollte eine Bezeichnung für den Routertyp sein (an die
>> bestehenden orientieren)
>>    * erzeuge ein leeres Verzeichnis bsp/<machine-name> (Anmerkung: Das
>> Buildscript steigt sonst aus, und aus der Fehlermeldung wird der Grund 
>> nicht
>> wirklich deutlich)
>>    * erzeuge _KEIN_ manuelles bsp/<maschine-name>/.config, kopiere 
>> auch
>> _KEINS_ hin (Anmerkung: die Fehlermeldungen vom buildscript verleiten
>> einem dazu - und das schlimme: Es funktioniert dann sogar, nur ist die 
>> .config
>> dann _viel_ zu groß und ist supporttechnisch eine Katastrophe))
>>    * wähle das bsp mit buildscript selectbsp 
>> bsp/board_<machine-name>aus
>>    * buildscript prepare
>>    * buildscript config openwrt
>>       * Da dann Target, Subtarget und Target Profile anpassen
>>       * Ansonsten muss erstmal nichts getan werden (Die Freifunk 
>> Software
>> und die wichtigsten Kernelmodule für das entsprechende Target werden
>> automatisch ausgewählt, Ergänzungen z.B. bzgl. Kernelmodule bitte erst 
>> in
>> der 2. Iteration)
>>       * Save
>>       * Die Abfrage vom buildscript bzgl. Speichern mit y abnicken
>>       * schauen wie der chipset und subtarget in der bsp/<machine-
>> name/.config genannt wurde (Beispiel:
>> CONFIG_TARGET_ramips_rt305x_ - ramips ist da das chipset und rt305x 
>> das
>> subtarget) und in der .bsp Datei anpassen.
>>    * firmware/src/packages/fff/fff-network/<chipset> von (derzeit am
>> besten) mpc85xx kopieren. (Anmerkung: Fehlermeldung ist da nicht 
>> einfach
>> zu interpretieren)
>>    * die network.irgendwas nach network.<board_name> kopieren.
>> <board_name> bekommt man am einfachsten heraus, wenn man bereits ein
>> Openwrt/LEDE auf dem Router hat und ein uci get board.model.name
>> eingibt. Ansonsten erstmal "raten".
>>    * diese anpassen (Das wissen von /etc/network.config von einer
>> bestehenden Installation oder die OpenWRT Seite für den Router kann 
>> dabei
>> helfen)
>>    * Und das ganze mit buildscript build bauen (Dauert so 20...60
>> Minuten)
>>    * Vermutlich krachts am Ende mit einer Fehlermeldung, dass die 
>> firmware
>> nicht kopiert werden konnte. Dann schauen, wie die zu kopierende Datei
>> heißt (Tipp: Im Umfeld der Datei, die er kopieren wollte, umschauen) 
>> und
>> dann die .bsp Datei anpassen.
>>    * Nochmal bauen (geht schnell)
>>    * Aufs Gerät flashen (z.B. mit scp kopieren, per ssh einloggen und
>> sysupgrade -n machen)
>>    * Hoffen *g* Und nicht gleich die Krise bekommen - beim ersten 
>> Start muss
>> der Flash initialisiert werden, was schonmal ein paar Minuten dauern 
>> kann.
>> Für Ungeduldige: auf die serielle Konsole schauen.
>>    * Versuchen aufs Gerät zu kommen - z.B. mittels den fe80er 
>> Adressen,
>> fe80::1, fdff::1. Oder versuchen die Adresse per ping -6 
>> ff02::1%<iface> zu
>> bekommen. Wenn alles nichts hilft: Serielle Konsole.
>>    * Anmelden, schauen ob /etc/network.config von /etc/network.<board-
>> name> übernommen wurde (ansonsten passt der board-name nicht)
>>    * network.config solange anpassen, bis man mit der Port-Config 
>> zufrieden
>> ist
>>    * Diese Änderungen in die
>> firmware/src/packages/fff/fff-network/<chipset>/network.<board-name>
>> rückkoppeln, neu bauen und flashen
>>    * Solange machen, bis alles funktioniert
>>    * Hinweis: /etc/config/network und wireless nach Möglichkeit 
>> erstmal
>> _nicht_ ändern.
>>    * Fertig :-)
>> </Anleitung>
>> 
>> Ich behaupte mal dreist, dass wenn man die 3 Stolpersteine kennt bzw.
>> überwunden hat man es mit "normalen" Debugtaktiken gut schaffen kann.
>> Ich habe es auf diese Weise vor einigen Jahren ohne jede Hilfe und
>> Vorkenntnissen bzgl. dem Buildsystem für den Carambola hinbekommen.
>> 
>> Ich fände es schön, wenn wir die bsps sammeln würden. Damit uns das
>> supporttechnisch nicht um die Ohren fliegt würde ich vorschlagen, dass 
>> die
>> Varianten, die wir nicht offiziell supporten wollen (Betrifft v.a.
>> alle Geräte, die die FW-Entwickler nicht haben und es keinen 
>> Maintainer gibt,
>> der sich bereit erklärt regelmäßig zu testen) in einem CONTRIB Ordner
>> landen und nicht via buildall gebaut werden. Man kann sie auch in 
>> einem
>> eigenen Repo sammeln. Die Verwaltung von letzterem könnte ich auch
>> übernehmen.
>> 
>> Viele Grüße,
>> Michael Fritscher