Workaround 841N LOAD/Neustart-Problem


#72

Ich möchte auch nochmal einfach meinen Hinweis von vor einiger Zeit wiederholen.


#73

Lässt sich die vorläufige Änderung nicht eventuell via cron-Skript relativ einfach umsetzen?

a) Skript wird im overlay im micron.d platziert / Ausführung 1-mal pro Stunde/Tag
b) Skript prüft, ob sinnvoller Zeitpunkt+Zustand zum Patchen erreicht ist
c) Skript führt sich aus
d) Skript deaktiviert sich dauerhaft (z. B. per Konfigeintrag)

Das wäre doch “wie von Hand ausgeführt” und zwei zusätzliche Dateien im overlay (job-Datei + Shell-Skript) sollten doch machbar sein.

Punkt b) könnte man so gestallten, dass z. B. Router auf dem “experimental” Branch das Skript nicht ausführen, etc. Oder wenn bestimmte Konfigurationen manuell geändert wurden.


#74

Mit dem haveged ist es vielleicht etwas knifflig. Aber einfach mal eine Firmware machen, die die ganzen sysctls drin hat, sollte doch trivial sein. Schaden wird es sicherlich nicht, und wenn es keine Verbesserung gibt, muss man aus der Experimental ja keine stable machen.

Könnte man nicht den haveged eine Stunde nach dem Booten stoppen (und nicht disablen)? Das wäre trivial zu machen, und ich sehe im Moment wenig, was dadurch kaputt gehen könnte.


#75

Spricht etwas dagegen, die neuen sysctl-Werte auf allen Systemen zu benutzen, oder sollte man das nur machen, wenn man 32MB RAM hat? Wenn es auch bei viel RAM nicht schadet, könnte man die sysctls global eintragen, und im rc.local eine kleine Abfrage reinbauen, ob das RAM nur 32MB groß ist und dann nach einem sleep 3600 den haveged stoppen.


#76

Irgendwie ist es vermutlich noch nicht ganz klar geworden, vermutlich habe ich es noch nicht richtig rüber bringen können.

Solche Änderungen sehen von außen vielleicht trivial aus, sind aber alles andere als einfach einzubauen. Guck mal in den Gluon Source und such da nach einem einfachen zentralen Eintrag für die sysctl.conf. Den werdet ihr allerdings nicht finden, da die Werte an vielen verschiedenen Stellen in passenden Pakete gesetzt werden. Dann musst drauf achten, das haveged sauber beendet wird und das auch nur wenn es sinn macht. Es musst darauf geachtet werden, keine existierenden Werte zu überschreiben und ihr wollt eigentlich auch keine redundanten Einträge. Ihr müsst sogar schon darüber nachdenken, wie die Einträge zu entfernen sind, wenn man das vielleicht nicht mehr will.

Daher nochmals meine Aussage die ich bereits genannt hatte und die Bitte nicht immer wieder “ist doch trivial, mach mal” zu sagen. Wenn jemand dieses Feature direkt in der Firmware haben will, müssen sich diese Personen beteiligen und ein sauberes Gluon/OpenWRT Paket dafür bauen, dass diesen Workaaround sauber umsetzt inkl. Deinstallationsscripten. Dann gucken wir uns das an und testen es. Wenn es sauber läuft, kommt es wie andere Software in den Experimental Branch und so weiter.

Freifunk ist kein Wunschkonzert, wir arbeiten gemeinsam an Problemen. Wenn jemand ein Feature unbedingt will, für das andere Gerade keine Zeit haben oder andere Gründe es nicht zu bauen, muss man es selbst machen.

Genau das ist auch ein Punkt der nicht so einfach ist, da einige Werte negative Einflüsse auf die größeren Router haben könnten.


#77

Gibt es eine kurze Schritt-für-Schritt-Anleitung um eine Firmware für FFRN zu bauen? Oder muss man da oft Hand anlegen? Ich würde das gerne mal ausprobieren… Im trivialsten Fall müsste ich nur 2 zusätzliche Dateien ins Image reinbekommen, das müsste doch irgendwie möglich sein, zur not mit einem extra Paket dafür.

Im Prinzip geht es wahrscheinlich so, oder?


Firmware für TP-Link TL-WA801ND v5
#78

Wir haben ein Github Repository, da steht eigentlich alles drin was du brauchst:

Und hier noch ein Beispiel für ein Paket:

Und die Gluon Doku: https://gluon.readthedocs.io/en/v2016.1.5/

Einfach kurz suchen :P

Im trivialsten Fall ja, der findend dann nur leider seinen Weg nicht in unsere Firmware. Daher achte doch bitte auf die Punkte die ich oben genannt habe wenn du es versuchen willst.

[Edit]
Tipp von @NurticVibe und mir: Ein Script das nach dem Boot läuft und checkt ob es im Config Mode ist und der RAM < 32MB und dann die Commands absetzt. Das wäre schön rein und wieder raus zu nehmen und nicht wirklich ein großer Aufwand.
[/Edit]


#79

Genau das habe ich ja gemacht (außer dass ich nicht auf Config-Mode abfrage). Und aktuell versuche ich dieses Script in die Firmware reinzubauen.

Rausnehmen sollte dann trivial sein, wenn man es nicht in die nächste Firmware reinbaut, ist es wieder draußen. Ich würde nichts permanent in der sysctl.conf speichern, und auch den haveged nur stoppen (und nicht disablen).


#80

Wenn du das Paket gebaut hast in die Liste der site.mk rein und dann das entsprechende Repository als Feed dazu:

Beispiel: https://github.com/freifunk-darmstadt/site-ffda/blob/master/modules

Bei dem Paket an sich kannst du dich an obigem Beispiel orientieren. Oder auch an diesem minimalen Beispiel: https://github.com/freifunk-darmstadt/ffda-packages/tree/master/gluon-purge-contact-info

Allgemeine Infos zu OpenWRT Paketen gibts hier: https://wiki.openwrt.org/doc/devel/packages


#81

So, nach einer langen Nacht habe ich nun endlich meine erste Gluon-Firmware gebaut. Eigentlich ganz einfach, wenn man es mal verstanden hat, leider kann man an hundert Stellen etwas falsch machen und bekommt dann eine Stunde später eine mehr oder weniger kryptische Fehlermeldung… Ich werde das demnächst mal genauer dokumentieren.

@leah: ich habe an den Versionsnummern nichts geändert, d.h. meine Firmware heißt jetzt “0.5.1-20160618”, was vielleicht etwas blöd ist. Welche Version soll ich reinmachen, und wie kompiliere ich explizit eine “experimental” Firmware?

Grundsätzlich funktionieren die Images, ich habe 2 OpenWRT-Knoten damit erfolgreich auf Freifunk geflashed. Die Einrichtung im Config-Mode hat geklappt, da lief der haveged, beim anschließenden Neustart wurde der haveged disabled und die sysctls (temporär) gesetzt. Ob meine Einschränkung auf Knoten mit < 40MB RAM funktioniert konnte ich mangels Hardware mit mehr RAM nicht testen, sollte aber klappen.

Wenn ich von meiner Firmware wieder auf eine offizielle gegangen bin, wurde der haveged scheinbar wieder enabled, so wie es sein sollte.

Wer schon Interesse zu testen hat, bitte kurze PN an mich. Wenn ben mir dann die Versionsinfo gibt, mache ich eine neue Version, die dann mehr Leute testen können.

Wer selber kompilieren will:

Ich hoffe, wir bekommen das Netz bald wieder stabil!


#82

Moin,

cool!

bitte nimm doch die 0.5.5 als Versionsnummer für die Tests.

make -j5 V=s GLUON_TARGET=ar71xx-generic GLUON_BRANCH=experimental

Ok, aber bitte nicht zu weit streuen. Der Code sieht aber gut aus. Für mich wäre noch interessant auf welcher Gluon Version die Firmware jetzt basiert? Wenn alles glatt läuft und sie auch für größere Geräte ohne Probleme funktioniert, kann ich eine bauen und sie dann im experimental branch per Update verteilen.


#83

Das mit dem Branch habe ich jetzt auch endlich gefunden und verstanden:

Ich habe eben einfach intuitiv 0.5.5 genommen, build läuft schon.

2016.1.5


#84

Ok, letzteres ist etwas suboptimal, da aktuell alles andere noch auf 2016.1.3 läuft und ich beide Updates eigentlich nicht Zeitgleich machen wollte. Gleichzeitig bin ich mir nicht so sicher ob ein Downgrade sauber verlaufen würde. Macht es dir was aus, die Firmware für die weiteren Tests nochmal auf Basis von 2016.1.3 zu bauen?
Der Commit ist dieser hier: https://github.com/freifunk-gluon/gluon/commit/b704308446bd1400cd4e6fc03b06a7fbe6cb9830


#85

Läuft.

Der Beitrag muss mindestens 20 Zeichen lang sein. Super.


#86

So, fertig gebaut, scheint auch zu laufen. Aber mir ist noch etwas aufgefallen: ich hatte gluon-announced aus der site.mk rausgeschmissen, damit es mit 2016.1.5 kompiliert, und habe es jetzt nicht wieder reingemacht, als ich es mit 2016.1.3 übersetzt habe. Ist das schlimm?

https://www.adwin-downloads.de/ffrn/images/

Das mit dem sysupgrade und einer URL ist übrigens mittlerweile ein ziemliches Glückspiel. Weiß einer warum? Wenn man erst mit wget das Image runterläd und dann sysupgrade mit der Datei aufruft, klappt es aber relativ gut.


#87

Es ist nicht wirklich optimal, da diese Paket genutzt wird um dir die Informationen anderer Knoten auf der Statusseite anzeigen zu lassen. Es würde also schon sinn machen es mit rein zu bauen.

Verstehe ich gerade nicht, was ist da ein Glücksspiel?


#88

Es hat bei mir einfach nicht funktioniert. Es sah auf der Konsole dann immer alles so aus, als wenn das Update sauber durchlaufen würde, und dann bootet der Knoten neu und hat wieder die alte Firmware drin.


#89

Ich muss zugeben, bis eben wusste ich nicht mal das man da ne URL angeben kann.


#90

Also mit gluon-announced lässt sich das nicht bauen. Das scheint seit 2016.1 in gluon-respondd drin zu sein. Insofern sine meine Images vielleicht sogar OK:

http://gluon.readthedocs.io/en/v2016.1/releases/v2016.1.html

The packages gluon-announce and gluon-announced were merged into
the package gluon-respondd. If you had any of them (probably
gluon-announced) in your package list, you have to replace them.


#91

Wie hast Du denn dein letztes Image gebaut? Ist die site.mk auf Github aktuell?

Ich befürchte, mein Image basiert auf dem Stand von https://github.com/Freifunk-Rhein-Neckar/site-ffrn welcher nicht den aktuellen Stand der letzten experimental images wiederspiegelt. Daher sind auch die Farben im Webinterface anders. Funktionieren tun die Images jedoch scheinbar.

Ich kann die Images auch nochmal neu bauen, wenn du site-ffrn aktualisierst. Oder habe ich was falsch gemacht?