In das Original-Repo habe ich es nicht gepusht, die Änderungen kannst du in unserem eigenen Repo sehen: GitHub - freifunklippe/packages
Das reicht immer noch nicht. Wenn ich die /lib/gluon/aptimeclock/aptimeclock.sh manuell ausführe, kommt folgende Ausgabe:
sh: 0550: unknown operand
uci: Entry not found
Die zweite Zeile dürfte andeuten, dass es auf meine 1043v4 kein Client.Radio.1 gibt. Aber was soll die erste Zeile bedeuten? Leider ist logread nichts genaueres zu sehen.
Das Leerzeichen in der Shebang hat auch keine Auswirkung, egal ob da oder nicht.
Cool, noch einer der das bestätigen kann das nichts passiert 
Wir sind leider zum gleichen Ergebnis gekommen.
Hat noch einer einen Tipp wonach man gucken könnte?
Mal ins blaue geraten:
Sind denn die uci Einträge die mit get abgefragt bzw. Mit set gesetzt werden vorhanden ?
Edit: gerade getestet:
uci set jjj=q
uci: Entry not found
root@Freifunk-Lippe-LEDE-Test:~# uci get wireless.client_radio0.disabled
0
root@Freifunk-Lippe-LEDE-Test:~# uci get wireless.radio0.client_clock_on
0550
root@Freifunk-Lippe-LEDE-Test:~# uci get wireless.radio0.client_clock_off
1800
Die Einträge sind vorhanden, trotzdem kommt diese Ausgabe:
sh: 0550: unknown operand
uci: Entry not found
Was bedeutet uci set jjj=q ?
Sehr wahrscheinlich habe ich den Fehler gefunden, muss nur noch neu bauen.
Im Script steht folgender Code:
CurrentTime=$(date +%k%M)
Dies funktioniert in der in LEDE verwendeten BusyBox-Shell nicht mehr. Da wurde scheinbar etwas an der Syntax verändert.
Wenn man die Zeile abändert in:
CurrentTime=$(date +%H%M)
läuft die aptimeclock.sh ohne Fehler durch. Das gleiche Problem besteht in der vpnlimittimeclock.sh
Man kann das sehr schön testen, wenn man per SSH auf dem Knoten eingeloggt ist und
date +%H%M
eingibt. Dann sollte die aktuelle Uhrzeit im Format HHMM angezeigt werden.
Durch diesen Befehl wird die Variable $CurrentTime gefüllt. Wenn diese leer bleibt, bricht das Script ab und der Schaltvorgang findet nicht statt.
2 „Gefällt mir“
Pull-Requests welcome
Pull-Requests sind erstellt.
Danke, ich habe gemerged.
Danke!
Könntet ihr euch bitte einmal das Script vpnlimittimeclock ansehen? Das funktioniert immer noch nicht. Startet man die vpnlimittimeclock.sh manuell, dann läuft diese auch ohne Abbruch durch.
Dummerweise wird die Bandbreitenbegrenzung nicht eingeschaltet, auch wird in die /etc/config/simple-tc nichts vom Script hineingeschrieben.
Das vpn-limit funktioniert leider „so“ nicht, ist leider bekannt.
Ich finde leider trotz einigem Suchen den Thread nicht wieder.
Das geht wohl nur, wenn man massiv mehr an den network-Interfaces tut.
Was heißt „so“ nicht? Funktioniert es denn irgendwie anders?
in irgendeinem Thread hatte mal jemand eine Lösung gefunden „ohme Flash schreiben, ohne reboot“…
Oder war’s im Gluon-IRC, oder in einem gluon-github-issue?
Wer’s findet, bitte hier Bescheid geben.
Der hier?
Dummerweise gibt es gluon-simple-tc nicht als Befehl auf dem Knoten.
Schaut doch Mal, was es gibt mit
uci show | grep simple
Und habt ihr mit dem Script auch fastd neu gestartet nach der Änderung?
simple-tc.mesh_vpn=interface
simple-tc.mesh_vpn.enabled='0'
simple-tc.mesh_vpn.ifname='mesh-vpn'
simple-tc.mesh_vpn.limit_ingress='6000'
simple-tc.mesh_vpn.limit_egress='1000'
bekomme ich unter einem frischen 2017.1.4 als ausgabe
Zumindest das sollte auf „1“ stehen während der Zeiten wo das eingeschaltet ist.
In den GitHub - eulenfunk/packages gibt es im Branch v2018.1.x kein gluon-aptimeclock Modul mehr. Habt Ihr da jetzt eine andere Lösung für?
Dein. Das Verfahren war nicht zuverlässig. PRs welcome.
(Vermutlich bräuchte man mehr Teile vom WPA_suplicant für. Wäre als etwas für Geräte mit dem Footprint „8MB flash aufwärts“)