Was genau hat das mit 2.4 zu tun? Heisst das auf 5GHz macht der quickfix Probleme?
Und nochwas:
der gluon-quickfix könnte doch auch noch nach alfred checken, ob das noch läuft, oder?
Wäre das so korrekt eingebaut?
ein reboot weil prozesse nicht laufen halt ich persönlich für zu hart, besonders alfred und respondd und dropbear lassen sich schmerzfrei neu starten - und da hab ich noch NIE beobachtet das die im einzelnen ausgefallen sind. …
@rubo77 das sieht gut aus, kannste auch selber testen indem du die entsprechende Zeile in einem router startest, sollte da kein alfred laufen macht der „reboot“ - der comment dahinter geht in der regel bei einem reboot auf den plasteroutern verloren, da die kein persistentes log hab
Der Comment ist ja nur fürs Debuggen. Dazu mußt du die reboot Zeile auskommentiert. Steht da ja. Also ein simolierter Reboot
Hat da schon jemand Erfahrungen und kann das Script verbessern, das er nicht immer gleich in allem Fällen rebootet?
Leider reicht ein Alfred restart nicht.
Wir haben hier so einen Kandidaten:
http://mesh.ffki.de/#!v:m;n:24a43ce4c917
Alfred friert da schon mal gerne ein und nur ein Reboot hilft dann…
Der Knoten ist weiterhin online und arbeitet ohne Probleme. Er ist nur in der Karte offline.
Und ich glaube ein chekc, ob alfred noch läuft, ist hier nicht ausreichend, denn der läuft ja noch, ist nur irgendwie nicht mehr richtig am arbeiten, müste man was anderes checken.
die frage wäre ob alfred oder respondd oder announced das wesentliche Element sind, die die infos zum karten-backend bringen. - da hab ich keine Ahnung von eurer Technik und derem Stand
Alfred prüft man in etwa so ; auf positiven output von alfred -r 159 oder mit echo foo|alfred -s 110 ; alfred -r 110
respondd in etwa so : gluon-neighbour-info -d ::1 -p 1001 -t 1 -c 1 -r statistics" (wenn gluon neighbour installiert wurde)
ihr kommt etwas vom Thema ab 
lese und sehe ich das denn richtig, bisher hat nur eine einzige Person von einem angeblichen wifi Problem berichtet?
Falls ja, mal wieder viel Lärm um wenig…
Dann melde ich mich hier halt als eine zweite Person, bei der sich mit 2016.2.1 nach 2 Tagen und 15 Stunden auf einem 841er das WLAN aufgehängt hat.
ok, und nun kommen wir zum spannenden Teil:
Beteiligung an der Lösung (wenn schon nicht im IRC, auf der ML oder im github issue #605)
- erfolgte der Build mit einem kompletten clean?
- Mit welcher Version lief es zuletzt wirklich besser?
- ibss oder 11s?
- Was steht in „logread“ dazu? Was in „dmesg“?
- Was ist der Inhalt von /sys/kernel/debug/ieee80211/phy0/ath9k/reset
(die letzten 2 Antworten kann man natürlich nicht geben, wenn man gleich rebootet)
1 „Gefällt mir“
Wir sind zu dritt:
@Petabyteboy du und meine Wenigkeit
Ich habe unmittelbar bei Auftreten des Problems im IRC angefragt. Erhielt jedoch keine Reaktion. Das es sich dabei um Bug 605 handelt ist euch sicherlich klar, für Außenstehenden jedoch nicht auf Anhieb ersichtlich!
Antworten:
- Build dir von 2016.1.5 mit make clean GLUON_TARGET= gesäubert
- Gluon 16.5 (spätere habe ich nicht installiert)
- Das Problem trat mit IBSS auf einem WDR4900 und mit 11s auf 2 CPE210v1 auf
- ff-wdr4900-#605 - Pastebin.com
- ff-cpev1-#605 - Pastebin.com
Ich habe nun den fix aktiv und alles ist gut.
Bei mir zeigte sich der Fehler auch nicht in schlechter WiFi Performance, sondern in geringen Bandbreiten <3MBit/s nach einem iw $dev scan kamen wieder „normale“ Bandbreiten zustande.
2 „Gefällt mir“
zu 3: ibss (1 ibss Link und 3 Clients als es auftrat)
zu 4: logread: kein Eintragungen, es verschwinden nach und nach die Clients mit „deauthenticated due to inactivity (timer DEAUTH/REMOVE)“
dmesg: keine Eintragungen
zu 5:
Habe keinen Reset durchgeführt, sondern „iw client0 scan“.
cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
Baseband Hang: 0
Baseband Watchdog: 11
Fatal HW Error: 0
TX HW error: 0
Transmit timeout: 0
TX Path Hang: 2
PLL RX Hang: 0
MAC Hang: 0
Stuck Beacon: 112
MCI Reset: 0
Calibration error: 0
Tx DMA stop error: 116
Rx DMA stop error: 0
1 „Gefällt mir“
@rotanid und all others: feedback im issue tracker github ibss0 hickup in v2016.2++ · Issue #933 · freifunk-gluon/gluon · GitHub
und die Diskussion in der Hauptsache zu dem ATH9k instability bug zusammengeführt
Unstable ath9k WLAN · Issue #605 · freifunk-gluon/gluon · GitHub
kann jemand eine „Anleitung“ geben wie man so einen wifihänger möglichst zuverlässig produziert? ich selber hab das nur als sehr sehr rares Ereignis
bitte den quickfix genau ansehen, bevor ihr den verwendet und damit entscheidet ob die reboots wirklich nötig sind
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.)