| Message ID | 1499246927-1663-1-git-send-email-freifunk@adrianschmutzler.de |
|---|---|
| State | Superseded |
| Headers | show |
diff --git a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_passthrough.sh b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_passthrough.sh old mode 100644 new mode 100755 index cb3508f..7351666 --- a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_passthrough.sh +++ b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_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
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@adrianschmutzler.de>: >Signed-off-by: Adrian Schmutzler <freifunk@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_activate_poe_passthrough.sh > >diff --git >a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_passthrough.sh >b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_passthrough.sh >old mode 100644 >new mode 100755 >index cb3508f..7351666 >--- >a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_passthrough.sh >+++ >b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_poe_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
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@adrianschmutzler.de>: > >Signed-off-by: Adrian Schmutzler <freifunk@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_activate_poe > >_passthrough.sh > > > >diff --git > >a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_p > >oe_passthrough.sh > >b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_ > >poe_passthrough.sh old mode 100644 > >new mode 100755 > >index cb3508f..7351666 > >--- > >a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_p > >oe_passthrough.sh +++ > >b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activate_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
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. 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 Grüße Adrian -----Original Message----- From: Tobias Klaus [mailto:tk+ff@meskal.net] Sent: Mittwoch, 5. Juli 2017 13:00 To: franken-dev@freifunk.net; Tim Niemeyer <tim@tn-x.org> Cc: Adrian Schmutzler <freifunk@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@adrianschmutzler.de>: > >Signed-off-by: Adrian Schmutzler <freifunk@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
Hallo, ich versteh hier nicht ganz, worauf du hinaus willst ... Grüße Adrian -----Original Message----- From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Tim Niemeyer Sent: Mittwoch, 5. Juli 2017 12:26 To: Adrian Schmutzler <freifunk@adrianschmutzler.de>; franken-dev@freifunk.net Subject: Re: [PATCH] fff-support: Update PoE passthrough code for CPE 210 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@adrianschmutzler.de>: >Signed-off-by: Adrian Schmutzler <freifunk@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_activate >_poe_passthrough.sh > >diff --git >a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activa >te_poe_passthrough.sh >b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activa >te_poe_passthrough.sh >old mode 100644 >new mode 100755 >index cb3508f..7351666 >--- >a/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activa >te_poe_passthrough.sh >+++ >b/src/packages/fff/fff-support/ar71xx/usr/lib/fff-support/cpe210_activa >te_poe_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 -- franken-dev mailing list franken-dev@freifunk.net http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
Hi Am 5. Juli 2017 13:36:57 MESZ schrieb Adrian Schmutzler <mail@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@meskal.net] >Sent: Mittwoch, 5. Juli 2017 13:00 >To: franken-dev@freifunk.net; Tim Niemeyer <tim@tn-x.org> >Cc: Adrian Schmutzler <freifunk@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@adrianschmutzler.de>: >> >Signed-off-by: Adrian Schmutzler <freifunk@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
Hallo, 1. also im Moment überlebt es ein Update ja nicht. Mir ist allerdings nicht so wirklich klar, warum. 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. 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? Grüße Adrian -----Original Message----- From: Tim Niemeyer [mailto:tim@tn-x.org] Sent: Mittwoch, 5. Juli 2017 13:53 To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net; 'Tobias Klaus' <tk+ff@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@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@meskal.net] >Sent: Mittwoch, 5. Juli 2017 13:00 >To: franken-dev@freifunk.net; Tim Niemeyer <tim@tn-x.org> >Cc: Adrian Schmutzler <freifunk@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@adrianschmutzler.de>: >> >Signed-off-by: Adrian Schmutzler <freifunk@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
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@tn-x.org] > Sent: Mittwoch, 5. Juli 2017 13:53 > To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net; 'Tobias Klaus' <tk+ff@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@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@meskal.net] > >Sent: Mittwoch, 5. Juli 2017 13:00 > >To: franken-dev@freifunk.net; Tim Niemeyer <tim@tn-x.org> > >Cc: Adrian Schmutzler <freifunk@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@adrianschmutzler.de>: > >> >Signed-off-by: Adrian Schmutzler <freifunk@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 >
Signed-off-by: Adrian Schmutzler <freifunk@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_activate_poe_passthrough.sh