Fortsetzung der Diskussion von [ANNOUNCE] Gluon v2016.2.1:
Wie habt ihr das bemerkt? Habt ihr da ein Monitoring?
Zum Einen beobachten wir aktuell die CPEs eng wegen der Meshprobleme seit 2016.x.
Zum anderen hat @petabyteboy einen Fix eingebaut, welcher bei Absinken der Anzahl der Meshnachbarn einen IW Scan macht. Grafana bzw. Meshviewer macht den Rest…
Ah OK. Ich konnte das Problem hier eben auf einem WDR4900 unter 2016.1.5 bestätigen.
Zwei CPEs laufen nun mit 2016.2.1 werde auch beobachten und berichten.
1 „Gefällt mir“
@Frank @PetaByteBoy - habt ihr mir ein link zu demgenannten „fix“ - würd ich mir gern ansehen
@adorfer - kann das sehr vereinzelt sonst auch bestätigen
@fuzzle packages/gluon-quickfix at v2016.2 · eulenfunk/packages · GitHub
ist hardcoded für 2.4GHz 802.11s
1 „Gefällt mir“
Perfekt.
Damit lässt sich das zunächst fixen, danke.
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