Fleißig nutzen. Hier hängt leider regelmäßig ein 841er, über den die Wohnheimbewohner nebenan 10 bis 20 GB pro Tag rauschen lassen.
@PetaByteBoy @anon68922371 : da ist ein fataler Fehler in dem quickfix: quickfix should reboot if needed by rubo77 · Pull Request #25 · eulenfunk/packages · GitHub
Der reboot startete nur innerhalb der erstenhalben stunde anstatt nicht vor mindestens einer halben strunde!
alle, die diesen quickfix (aus dem Branch 2016.2) benutzt haben sollten updaten, sonst könnte der quickfix unter umständen ständig überlastete router rebooten innerhalb der ersten halben stunde. ausserdem fixt der bisher nichts mehr per reboot, wenn der router mal eine halbe stunde überstanden hat.
Leider am Thema des Threads vorbei. Der Thread geht um „2016.2.x“, nicht um den branch „2016.2“.
Mit „diesen“ meinst Du aber nicht den, um den es in diesem Thread geht.
Aus https://github.com/eulenfunk/packages/blob/v2016.2.x/gluon-quickfix/files/lib/gluon/quickfix/quickfix.sh ist das seit längerer Zeit raus.
(Ja, ein fork statt eines branches von „v2016.2“ nach „v2016.2.x“ wäre sicher besser, mir klar. Aber der „.x“ ist meiner, der kann verwendet werden und läuft auch in >200 Routern in mehreren Domains.)
ja, deshalb hatte ich ja auch @PetaByteBoy zitiert. ich hab meinen kommentar noch mal verdeutlicht, dass der Fehler nur in dem branch 2016.2 war.
in Nord haben wir den geforkt und den Fehler behoben: GitHub - Freifunk-Nord/eulenfunk-packages at v2016.2
Dort haben wir auch einen lede branch mit dem quickfix
Den einen vielleicht.
NEIGHBOURS=$(iw dev $DEV station dump | grep -e "^Station " | awk ‚{ print $2 }‘)
zum machen ohne vorher zu prüfen ob das Wifi noch lebt: würde ich nicht tun. Ansonsten macht das Script mehr Schaden als es nutzt.
ja sehr cool deine Verbesserungen. Ich hab den mal reviewt: quickfix: add comments, fix indention and move configvar to the top by rubo77 · Pull Request #26 · eulenfunk/packages · GitHub
dabei fragte ich mich, ob der jetzt nur tunneldigger prüft? wir benutzen noch fastd, kann man dafür auf einfache weise auch einen check für einbauen? oder ist das nicht nötig?
einen abstürzenden/doppelten fastd habeich noch nicht erlebt.
Sprich: Ich habe nur fixes für Szenarien eingebaut, die ich bislang auch mal „in the wild“ gesehen habe.
- es gibt keinen Seamon der derzeit einen (vermeitlich) fehlenden fastd nachstartet
- wegen 1) gibt es auch keine false-positives.
- das tunneldigger-Problem ist eigentlich der tunneldigger-watchdog. Den würde es eigentlich zu fixen gelten. (Teil von Gluon ist der nach wie vor nicht und forken mag ich ihn nicht, da ich dann ein weiteres Ding dauerhaft „in der Wartung“ hätte. Dass wir aber in ffdus nicht allein mit dem Problem sind/waren sehe ich an den Load-spitzen wenn ich mal in die gesammelten Grafana-daten von Nachbardomains „auf l2tp“ schaue.)
Was den Respondd betrifft: ich habe keinen Router mehr im Zugriff, auf dem ein Respondd läuft. Daher vermag ich dazu nichts zu sagen. (Und auch dort: Blind würde ich nichts machen wollen, was ich hinterher nicht testen kann.)