Unstable ath9k WLAN #605
Comments
Uns sind bisher keine solchen Probleme aufgefallen. |
|
ping6 fe80::60e6:28ff:febe:18c4 ping6 ff02::1 Node2: Node1: batctl o | grep ibss Hatte ich alles schon durchgecheckt. und konnte das Problem sogar an verschiedenen Standorten reproduzieren... bin ein wenig ratlos |
|
Achso...und die andere Seite: |
|
The Gluon master just got an updated mac80211 backport, which was reported to fix some ath9k issues. |
|
Sehr gut! Jetzt geht alles wie es soll! Vielen Dank |
|
Wann kommt dieser commit in die stable? |
|
Mit 2016.2. Für ein 2016.1.x-Release ist diese Änderung denke ich zu groß. Und 2016.2 braucht vermutlich noch eine Weile (siehe Milestone) |
|
Ich bin am Überlegen, nach v2016.1.3 einen größeren Backport zu machen und in 1-2 Wochen als v2016.1.4 zu releasen, um solche Probleme zu beheben. |
|
Am 24.03.2016 um 22:48 schrieb Matthias Schiffer:
Ich fänd das sehr sehr gut und wichtig. Ich hatte sogar schon überlegt |
|
Ich habe einen neuen Branch v2016.1.x-mac80211-test hinzugefügt, der ein weiters Update der WLAN-Treiber enthält. Das ganze besiert auf v2016.1.x, damit ein unkompliziertes Wechseln zwischen Releases und dem Test-Branch möglich ist. Es wäre sehr hilfreich, wenn die neue Version auf möglichst vielen Routern mit WLAN-Problemen getestet wird. |
|
v2016.1.x-mac80211-test hat gerade ein weiteres Update bekommen, bitte testen. |
|
update heute nacht auf ein paar Knoten gespielt, schon jetzt hat einer davon wieder den Bug :-( |
|
Habe die v2016.1.x-mac80211-test nun seit 4 Tagen im Einsatz. Das Problem tritt weiterhin auf. |
|
v2016.1.x-mac80211-test enthält jetzt einen neuen Patch, bitte testen. |
|
Ähm... der neue Patch kompiliert noch nicht, einen Moment... |
|
So, v2016.1.x-mac80211-test enthält jetzt 2 Commits über v2016.1.x hinaus: Ein weiteres Update von mac80211 und ein Patch von nbd. Bitte erstmal nur das Update testen (also den zweitneusten Commit). Wenn das keinen Unterschied macht, dann einmal mit dem neusten. |
|
Gibt's irgendwas neues hier? |
|
Nach zwei Tagen 548cf1d Test sieht es erstmal deutlich besser aus als mit d31c1c9. Statt mehrmals täglichen Ausfallerscheinungen, hatte ich bisher insgesamt nur zwei Ausfälle. Ob die Zwei Ausfälle problembedingt sind, weiss ich noch nicht genau. Manchmal sind da schnelle Finger an den Ein-/Ausschaltern der Router, und das beeinflusst mein Abfangszenario-Skript. Getestet habe ich auf meshenden CPE210 v1.0, WR841 v8, v9 und v10 mit starker Datenlast auf dem Wifi Mesh- und Clientnetz. Werde weiter beobachten... |
|
Hm, wie es aussieht, so hat sich nur die Häufigkeit verringert. Nennen wir einen Problem-Knoten mal KPUTT Chekov ist ein Knoten, der Wifi-meshend den Knoten KPUTT in die Wolke einbindet. Der Befehl Auffällig ist:
Ausgabe: EDIT: |
|
Nochmal ich.
Das ganze nochmal (wifi gefolgt von iw) ein zweites mal und KPUTT ist weiterhin nicht zu erreichen. Hm, ist das jetzt das Problem von einem Router, oder des Zusammenspiel von beiden/mehreren Routern? |
|
Ok, eine vollständige Lösung aller Probleme wäre auch zu schön gewesen. 2 weitere Tests wären hilfreich:
|
|
Ich habe ein mac80211-Downgrade im Gluon-Master committed (487922a). Bitte testen, wenn es läuft, kommt es nach v2016.2.x. |
|
Also ich habe eine Firmware mit diesem Stand auf ein paar Knoten ausgerollt. Einer der Mesh-Knoten hat sich gestern verabschiedet, war heute aber merkwürdigerweise wieder online, muss sich wohl irgendwie von selbst neu gestartet haben. Uptime jetzt 18 Stunden, muss also gestern gegen 23.00 Uhr passiert sein. Logread: http://pastebin.com/pNyuKxzc Kartenlink: https://map.freifunk-3laendereck.net/#!v:m;n:14cc2070948a
|
|
Wir haben einige Knoten mit der aktuellen Version versehen. Bei einer "PicoStation M2HP" (nur Mesh) taucht seit kurzem das Problem auf, daß sie sich dauerhaft aus dem WLAN ausklinkt, sobald man an der Konsole "wifi" abgesetzt hat. Die Pico ist dann nur noch mittels Reset zu reanimieren. Auf anderen Knoten ist mir bisher noch nichts in dieser Richtung aufgefallen. VG |
|
Könnte das vielleicht ein Kalibrierungsfehler sein? Im master von Linux sind einige Patches, die die Peak-Detect-Kalibrierung der betroffenen Chips auf „softwaretechnisch gelöst” umstellen (der hier und ganz viele andere): Ich teste schon seit ein paar Tagen alle möglichen Patches, die noch nicht bei LEDE oder OpenWrt eingepflegt sind, aber ich dachte NeoRaider wäre da schon dran... Ähnliche Fehler gab es nämlich bei dem WR940N v3, aber ich bin mir nicht sicher, ob die Ursache die gleiche ist. Es könnte ja sein, dass mit der Einführung der zusätzlichen Energiesparfunktionen auf einmal die Hardwarekalibrierung weiterer Chips nicht mehr funktioniert (diese Funktionen schaffen übrigens Airtime und sie abzuschalten ist nicht im Freifunksinne und es hat bei den betroffenen Communities das Problem auch nicht gelöst). Wieso ist hier überhaupt alles auf Deutsch? |
|
as mentioned in the other Ticket ( #993 and maybe #889 ) here some lines from closed other tickets.. sorry for mixing denglish together @rotanid du wolltest konkretes feedback, symptom : wegbrechen der mesh-links - simply dead ... ifconfig mit normaler ausgabe, nichts im logread, nichts im dmesg, aufgefallen weil der mit uplink (!) in einem dichten Meshnetz ohne Mesh-Kontakte war. Lösung - live beobachtet über die status page (die war bei ibss0 leer) - "iwinfo phy0 scan" .. danach sofort neu gefundene meshpartner in der status page. und logisch im meshviewer nach der entsprechenden Verzögerung. ich weis das @Adorfer schon früher von sowas berichtet hatte, konnte das aber nie so genau beobachten. bei uns (Freiburg-support branch) kann das aber aufgrund von sicherungsscripten NUR bei uplinkroutern passieren, alle anderen verlieren ja durch wegbrechendes Mesh ihren uplink und würden final sogar rebooten (nach fastd, network, restart versuchen) >> https://github.com/viisauksena/gluon-fffr/blob/master/files/lib/gluon/fffr/emergency.sh (das löst nicht das mesh link problem, aber durch restart/reboot eben indirekt schon) |
|
weis nicht ob das zusammenhängt, aber eine "seltsame" beobachtung kurz hier notiert: aber das vielleicht einfach nur ein relikt weil phy0 kein direktes if ist, tauscht man das mit ibss0 client0 oder so - gibts keinen fehler |
|
hier noch 2 Fehlerberichte aus dem Freifunk Forum kopiert, damit wir alles an einem Platz haben.
von @Tarnatos
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. von DL3DCF
von mir selbst: |
|
was bringt das edit: wer sind denn "die" entwickler .. ath9k? |
|
wurde von den Entwicklern damals angefordert, die werden schon wissen warum. @viisauksena "die Entwickler" ist bei ath9k primär nbd / Felix von LEDE, siehe das oben von AK-47 verlinkte LEDE issue 176 |
|
Wir haben hier einen weiteren bestätigten Fall:
Nach einem iw client0 scan kamen alle Nachbarn wieder. Logs: |
|
upstream LEDE issue 176 has been closed as fixed, maybe we (well, @neoraider ...) should try another backport? but people would need to participate in debugging that this time before doing the release :) |
|
than an announcement with an proposed commit-id in the forum would be fine - or some extra branch/tag |
|
A commit id posted here and it will be on 20 nodes tomorrow |
|
Are you all going mad?! Can you please stop using this as a forum? |
|
@CodeFetch i couldnt follow your argument so far, even with some sysctl specialy aranged that the Device wont reboot on panic to get some more debug output. Some may have this problem, i had different ones - i guess. But you may explain deeper why this "it is clearly a DMA lock error" and which are the recent kernel features needed - it seems LEDE so far will have a 4.4.32 (i build yesterday) kernel. With many ath9k improvements. Where latest stable is 4.8.11 by kernel.org. Do you think that is recent enough? |
|
@viisauksena i already explained to you, that #753 and therefore your "reboot on panic" or "reboot on oom" doesn't have to do anything with this issue, the ath9k driver instabilities. would you please stop mixing those two issues finally? thanks. |
|
It's the last I'm going to say on that issue here... @rotanid I'm testing, but I also have other things to do and I luckily don't need people to test it as I have a router where the error occurs reliably (one mesh-partner, dozens of clients). From the information given by me you could have found out which patches are relevant and I also named one: torvalds/linux@7da1ddd#diff-722db64892e310f0729be9025924ba52. Every calibration-related or queue-related ath9k patch could be the bad or the good guy. |
|
thanks for your constructive answer. good to know there's someone with sufficient knowledge and a good test device&situation. most of us lack the first and some the latter. that may be why the related LEDE-issue was closed (if it isn't fixed in latest LEDE? didn't test because of missing reliable test location.) |
|
i figured out one specific router in our net , which has failing ibss0 regulary,. Luckily this has own fastd uplink. This is very obvious by looking to the map, because the router should have plenty of ibss mesh links - which it doesnt. so its "nice" to have a reliable failing ibss0 router ... but i really dont know how to go on here - give hints, or help in further debugging. If i can do anything i am happy to do so. At least i will leave this router with this FW for a while.
FW is build around 23.Nov. with this commit |
|
as an update: we still have issues with ath9k devices running the gluon 2016.2.x branch - maybe it is fixed in the lede-based master, but we didn't have time to adapt everything to the big changes in the master branch, yet. |
neocturne
added
the
9. meta: upstream issue
|
Stability should have improved with the switch to LEDE, but it's still not perfect. New upstream issue: https://bugs.lede-project.org/index.php?do=details&task_id=447 |
|
There haven't been any reports of ath9k issues here or in the LEDE bug tracker for a while, so I think we can finally close this. |
Das Problem wird aktuell hier im Forum diskutiert:
https://forum.freifunk.net/t/wifi-mesh-probleme-im-2012-2-gluon/9813/14
Die Konstellation:
Das Problem:
Sobald ich 2 Router mit 2012.2 im Mesh habe bricht mir das WIFI mesh soweit ein das kaum noch Pakete durchgehen.
Folgende Test wurden gemacht um das Problem einzugrenzen:
Eigene Firmware:
-2er Mesh mit 2012.1 auf 1043 und 2012.2 auf 841v10 --> OK
-2er Mesh mit 2012.2 auf 841v10 --> Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er und 2012.2 auf 841v10 --> Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er --> Problem tritt auf
-3er Mesh mit 2012.1 auf 1043 und 2012.2 auf ZWEI 841v10 --> Problem tritt auf
Andere Firmware:
-2er Mesh mit 2012.1 auf 1043 und 2012.2 auf 841v10 --> OK
-2er Mesh mit 2012.2 auf 841v10 --> Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er und 2012.2 auf 841v10 --> Problem tritt auf
-2er Mesh mit 2012.2 auf 1043er --> Problem tritt auf
-3er Mesh mit 2012.1 auf 1043 und 2012.2 auf ZWEI 841v10 --> Problem tritt auf
Fazit: Identische Ergebnisse der Testfälle unabhängig der Hardware! Somit kann ich also den 841v10 als Fehlerquelle sowie auch meine gebackene Firmware ausschließen.
Ich habe sogar Testweise mal die WIFI Kanäle gewechselt was aber auch nichts gebracht hat
Geflasht wurde sicherheitshalber IMMER ein Factory Image mit TFTP Recovery um sicherzugehen das die Kisten komplett neu sind.
Evtl kann sich ein Entwickler daz äußern?
The text was updated successfully, but these errors were encountered: