[PATCH] fff-support: Update PoE passthrough code for CPE 210

So Jul 9 10:51:33 CEST 2017

Moin

Sry, dass ich unter der Woche nur recht knapp geantwortet hab. Heute
nochmal eine etwas ausführlichere Diskussion.

Am Mittwoch, den 05.07.2017, 14:13 +0200 schrieb Adrian Schmutzler:
> Hallo,
> 
> 1. also im Moment überlebt es ein Update ja nicht. Mir ist allerdings
> nicht so wirklich klar, warum.
Siehe unten: 05-config-system-migration ist Schuld.

> 2. Da in der neuen Firmware das direkte Bearbeiten
> der /sys/class/gpio/* Dateien nicht möglich ist (zumindest mir), ist
> die einzige mir bekannte Möglichkeit für den PoE Passthrough das
> Setzen der system.* Einträge. Vor dem Patch habe ich das halt von Hand
> in die Konsole eingegeben, das Skript fast das nur zusammen. Das heißt
> für mich, das Setzen des system.* Einträge lässt sich schlussendlich
> nicht vermeiden, wenn ich PoE-Passthrough will. Mit dem Skript habe
> ich jetzt halt nur eine Zeile statt fünf und ich muss nicht jedes Mal
> im Wiki nachschauen.
Ich bin nicht grundsätzlich dagegen so ein Script aufzunehmen. Ganz im
Gegenteil, meine Bauchschmerzen betreffen das Update und in diesem Fall
verquickt sich das Script mit dem Update-Prozess von LEDE/OpenWRT und
den haben wir bereits verpfuscht. Aber ich denke wir werden eine Lösung
finden. :)

> Quelle ist übrigens hier (nachdem die alte Methode nicht mehr funktioniert hat, hab ich das gegoogelt):
> https://wiki.freifunk.net/TP-Link_CPE210#PoE_Passthrough
> 
> Wenn jemand weiß, wie es anders geht, raus damit. Den Teil mit den
> verschiedenen Configs habe ich glaube ich nicht vollständig
> verstanden, aber würde das wirklich für den o.g. Fall helfen?
Das Problem ist nicht dein Script, sondern der Fakt, dass etwas in die
LEDE/OpenWRT Config geschrieben wird.

Wir haben bereits in der Vergangenheit den Fehler gemacht, dass wir z.B.
den Standort und andere Dinge in die /etc/config/system gepackt haben.
Solche Informationen sollen natürlich beim Update erhalten bleiben.
Daher wurde die ganze Datei /etc/config/system als "überlebenswürdig"
auserkoren. Das war ein grober Fehler, denn jetzt brauchen wir für diese
Datei ein Update-Pfad. Und zwar in jeder aktuellen Firmware einen Pfad
aus jeder älteren Firmware.
Ein Beispiel findest du z.B. hier:
src/packages/fff/fff-sysupgrade/files/etc/uci-defaults/05-config-system-migration
Das Script wurde nötig, weil die /etc/config/system neben unseren
Settings noch LEDE/OpenWRT-Default Settings enthält. Konkret ging es
damals um die LEDs. Wir benutzen ja die default config der LEDs, aber
die hatte sich für etliche Router-Modelle aber geändert, wodurch die
alten configs (die ein Update überlebt haben) nicht mehr funktionierten.

Das ist _im Moment_ noch ein überschaubares Problem, aber ich möchte
einfach vermeiden, dass es noch komplizierter wird. Von daher ist mMn
die einzig einfache und saubere Lösung, dass wir keine OpenWRT/Lede
Configs überleben lassen und stattdessen eigene Configs für unsere
Sachen pflegen. Dann brauchen wir nämlich nur ein Update-Script was die
Sachen aus unserer Config in die nicht überlebte LEDE/OpenWRT Config
überführt. Da wir die Kontrolle über die Config haben und wir diese
primitiv gestalten könnten, sinkt das Risiko das sich das Format über
mehrere Versionen grundlegend ändert beachtlich. Das wiederum senkt den
Test Aufwand.

Also schön, jetzt wo ich nochmal erklärt hab was von
der /etc/config/system Datei überlebt und was nicht, muss ich sagen,
sehe ich das Risiko, dass dein Patch die Sache komplizierter macht,
nicht mehr so stark. Ich frage mich aber, ob es von dir so gewollt ist,
dass die durch das Script gesetzten Einstellungen beim Update nicht
übernommen werden. Wenn das absichtlich so ist, würde ich begrüßen, dass
das Script eine entsprechende Warnung auf der Console ausgibt. Das hat
zwei Vorteile: a) Der aktivierende wird nochmal darauf hingewiesen. b)
Der Entwickler wundert sich nicht, dass das Setting nicht überlebt.

Wenn du möchtest, dass die Settings das Update überleben, sollten wir
uns eine zukunftssichere Strategie überlegen. Einfach die Settings (wie
auch den Standort) zu migrieren halte ich für keine sichere Lösung. Ich
könnte mir das z.B. so vorstellen:
Beim Aufruf des Scripts wird ein zusätzliches Setting in einer eigenen
Config-Datei angelegt. z.B. "uci -q set poe_passthrough.active = true".
Dann gibt es ein uci-defaults Script (mit einer niedrigeren Priorität
als das config-system-migration script), welches beim firstboot prüft ob
poe_passthrough == true ist, wenn ja ruft es das
cpe210_activate_poe_passthrough.sh auf. Damit haben wir den Luxus, dass
wir unabhängig davon sind ob der GPIO nun über /etc/config/system oder
über /sys/class/gpio oder durch ein gänzlich anderen Mechanismus
geschaltet wird. Denn nur eins ist wirklich klar, und das ist, dass es
heute unklar ist, was cpe210_activate_poe_passthrough.sh in Zukunft
machen muss. ;)

Tim

> Grüße
> 
> Adrian
> 
> 
> 
> -----Original Message-----
> From: Tim Niemeyer [mailto:tim at tn-x.org] 
> Sent: Mittwoch, 5. Juli 2017 13:53
> To: Adrian Schmutzler <mail at adrianschmutzler.de>; franken-dev at freifunk.net; 'Tobias Klaus' <tk+ff at meskal.net>
> Subject: RE: [PATCH] fff-support: Update PoE passthrough code for CPE 210
> 
> Hi
> 
> Am 5. Juli 2017 13:36:57 MESZ schrieb Adrian Schmutzler <mail at adrianschmutzler.de>:
> >Hallo,
> >
> >vielleicht zur Klarstellung:
> >1. Im Moment wird eine veraltete Version mitgeliefert, die, wenn man 
> >sie benutzt, _nicht_ funktioniert. Entsprechend sind die Möglichkeiten 
> >meines Erachtens: Updaten oder löschen.
> 
> Das könnte man fixen.
> 
> >2. Ich bin allerdings auch der Meinung, dass das Mitliefern eines 
> >solchen Skriptes keinen Schaden anrichtet. Ich würde sogar in die 
> >andere Richtung gehen und im Wiki auf das Vorhandensein hinweisen (im 
> >Moment ist das mE nicht der Fall und ich hab das Skript nur zufällig 
> >durch eine Textsuche im GitHub gefunden).
> >3. Im Gegensatz zu früher muss das Skript nun _nicht_ mehr in die 
> >rc.local eingebaut werden, sondern es reicht, wenn man es einmalig 
> >ausführt. Das ist allerdings nicht upgrade-sicher, siehe
> >https://mantis.freifunk-franken.de/view.php?id=53
> 
> Ich bleibe bei meinem Veto, weil du mit den Script Dinge in eine Datei schreibst die das update überleben wird.
> Dabei ist aber nicht gesichert, dass der Mechanismus nach dem Update noch geht. Das müsste man dann jeweils beim hochziehen von lede prüfen. Dann ggfs ein upgrade script schreiben und dabei die verschiedenen alten Versionen berücksichtigen. Das ist alles viel zu aufwändig.
> 
> Besser geht es so:
> Du machst eine eigene config. Die wird beim (ersten)booten von einem script gelesen und je nach dem ob an oder aus das passende setting in der system config (oder wo auch immer) gesetzt. Die system config darf das update nicht ueberleben. Wir haben dann die Kontrolle der config und webig Pflegearbeiten.
> 
> Tim
> 
> 
> >Grüße
> >
> >Adrian
> >
> >-----Original Message-----
> >From: Tobias Klaus [mailto:tk+ff at meskal.net]
> >Sent: Mittwoch, 5. Juli 2017 13:00
> >To: franken-dev at freifunk.net; Tim Niemeyer <tim at tn-x.org>
> >Cc: Adrian Schmutzler <freifunk at adrianschmutzler.de>
> >Subject: Re: [PATCH] fff-support: Update PoE passthrough code for CPE
> >210
> >
> >Hey,
> >
> >fff-support wird ja nie direkt ausgeführt, man muss es explizit selber 
> >in die rc.local_schlagmichtot einbauen und das wird explizit _nicht_ 
> >unterstützt und jeder der das tut ist _selber_ verantwortlich für das 
> >upgrade.
> >Ich sehe uns daher nicht in der Pflicht ein upgrade mitzuliefern.
> >
> >Anderseits wird aber wohl in der aktuellen Version ein kaputtes(nie 
> >automatisch ausgeführtes!) Skript mitgeliefert. Daher bin ich schon 
> >dafür das zu fixen. Falls es grundsätzliche Bedenken gibt solche
> >"Bequemlichkeits"- Skripte im Repo zu halten, wäre halt die Alternative 
> >sie zu löschen. Aber bis dahin finde ich den Patch als solchen gut.
> >
> >Grüße
> >Tobias
> >
> >
> >Am Mittwoch, 5. Juli 2017, 12:26:21 CEST schrieb Tim Niemeyer:
> >> Hi
> >> 
> >> Ich hab da Bauchweh. Die configs/settings von lese/openwrt waren nie
> >stabil.
> >> Wenn das Setting das Update über lebt muss das nicht heissen, dass es
> >
> >> danach noch geht. Dann muss man wieder ein upgrade script schreiben 
> >> und hat plötzlich tausend Sonderfälle.
> >> 
> >> Tim
> >> 
> >> Am 5. Juli 2017 11:28:47 MESZ schrieb Adrian Schmutzler
> ><freifunk at adrianschmutzler.de>:
> >> >Signed-off-by: Adrian Schmutzler <freifunk at adrianschmutzler.de>
> >> >---
> >> >.../ar71xx/usr/lib/fff-support/cpe210_activate_poe_passthrough.sh |
> >8
> >> >+++++---
> >> >
> >> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >> >
> >> >mode change 100644 => 100755
> >>
> >>src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activa
> >> >te_poe
> >> >_passthrough.sh
> >> >
> >> >diff --git
> >>
> >>a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_acti
> >> >vate_p
> >> >oe_passthrough.sh
> >>
> >>b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_acti
> >> >vate_
> >> >poe_passthrough.sh old mode 100644
> >> >new mode 100755
> >> >index cb3508f..7351666
> >> >---
> >>
> >>a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_acti
> >> >vate_p
> >> >oe_passthrough.sh +++
> >>
> >>b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_acti
> >> >vate_p
> >> >oe_passthrough.sh @@ -1,5 +1,7 @@
> >> >
> >> > if [ "$(cat /var/sysinfo/model)" = "TP-Link CPE210 v1.1" ] ; then
> >> >
> >> >-  echo 20 > /sys/class/gpio/export
> >> >-  echo out > /sys/class/gpio/gpio20/direction
> >> >-  echo 1 > /sys/class/gpio/gpio20/value
> >> >+    uci set system.gpio_switch_poe_passthrough=gpio_switch
> >> >+    uci set system.gpio_switch_poe_passthrough.name='PoE
> >Passthrough'
> >> >+    uci set system.gpio_switch_poe_passthrough.gpio_pin='20'
> >> >+    uci set system.gpio_switch_poe_passthrough.value='1'
> >> >+    uci commit system
> >> >
> >> > fi
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20170709/62e37a27/attachment.sig>