Ath9k-Probleme

Hinweis: Diese Seite wurde in das Archiv verschoben. Die Informationen sind größtenteils veraltet und nur für Spezialfälle relevant.

(Fast) alle Geräte, die wir im Freifunk-KBU Netz betreiben verwenden ähnlich wlan-Chips (Typ: Atheros 802.11n). Diese Chips funktionierenden mit dem in Linux enthaltene Treiber (ath9k [1]) nicht richtig.

Bekannte Probleme

Wir beobachten, dass das WLAN komplett oder in Teilen (nur ad-hoc oder nur master) ausfällt. Diese Ausfälle treten zusammen mit folgenden Kernel-Meldungen auf:

ath: phy0: Could not stop RX, we could be confusing the DMA engine when we start RX up

Wir wissen nicht, ob die Meldung bei jedem Ausfall erscheint. Wir können auch nicht sagen, ob die Meldung auch erscheint, wenn kein Ausfall vorliegt.

Leider lassen sich die Probleme nur schwer reproduzieren. Häufig treten sie nur in Verbindung mit bestimmten Endgeräten oder örtlichen Besonderheiten auf. Details siehe #Externe Quellen

Siehe auch: Rückmeldungen

Darüber hinaus gibt es Aussagen, nach denen weitere, TP-Link WR1043ND bezogene Probleme vorliegen. Hierzu haben jedoch keine Details.

Es ist insbesondere nicht klar:

1. Welche Revisionen und ggf. Typen betroffen sind.
2. Ist das Problem auf den TP-Link WR1043ND beschränkt?
3. Wie genau eine Störung aussieht
4. Welche Workrounds existieren

Quelle IRC-Channel #freifunk im IRCnet, 20.02.2013, abends:

<nbd> den wr1043nd würd ich nicht unbedingt empfehlen
<nbd> funktioniert zwar, hat aber nen veralteten wlan chip drin der deutlich störanfälliger als die neueren geräte ist

Umgang in Freifunk-KBU

Die Freifunk-KBU Firmware enthält ab Version 1.0beta11, das ist eine Vorabversion der derzeitig aktuellen Version 1.0, ath9k-watchdog [2].
Dieses Software überwacht ständig jeden Node.

Erkennt der watchdog einen Ausfall, so wird:

1. Die Ausgabe des Kernel-Ringbuffers (dmesg) gesichert
2. Der Node neu gestartet
3. Die gesicherte Ringbuffer-Ausgabe an unseren Server übermittelt.

Die so ermittelten Ergebnisse sind online einsehbar http://register.kbu.freifunk.net/watchdog_bites/. Auf diese Weise wissen wir, wann welche Nodes betroffen sind und können Aussagen über den Umfang des Problems machen. In Zukunft können wir somit abschätzen, ob neue Versionen des WLAN-Treibers oder andere Konfigurationseinstellungen Auswirkungen haben.

Aktuell versuchen wir abzuschätzen, welche anderen Daten für das Debugging der Probleme relvant sind (ath9k-Debug-Informationen, Wireless-Lan Frame header, verbundene Hardware) und werden den watchdog ggf. erweitern. Der Watchdog wird dabei auch in Zukunft keine personenbezogenen Daten ermitteln und verarbeiten.

Wir brauchen Deine Hilfe!

• Hast Du ein Problem mit dem wlan?
• Fällt es aus?
• Ist die Funkverbindung instabil obwohl eine gute Signalstärke angezeigt wird?

Wir sind an allen Problem interessiert, die im Freifunk-KBU Netz auftreten, um das Ausmaß der ath9k-Probleme zu verstehen. Gleichzeitig benötigen wir Patterns für unseren watchdog. Fällt bei Dir das wlan aus, ohne dass das Gerät neu starten, liegt ein unbekanntes Problem vor. In diesem Fall verbinde Dich bitte per ssh mit Deinem Node und sende uns die Ausgabe des dmesg-Kommandos. Hierzu musst Du zuvor den config_mode (Installation#Konfigurieren_des_Nodes) durchlaufen und ein Kennwort gesetzt haben.

Wichtig: Starte den Node nicht neu, sonst gehen die Protokoll-Daten verloren.

Ein ausgefallener Node ist mglw. nicht mehr Teil des Freifunk-Netzes. Daher musst Du Dich über die Link-Local-Adresse zum Node verbinden. Diese kannst Du herausfinden, indem Du Dich

1. Per Kabel mit dem WAN-Port verbindest,
2. Einen Ping an alle erreichbaren Geräte sendest
3. Die Adressen einzeln ausprobierst.

Beispiel Mac OS X (auf Linux: eth0 statt en0):

# 1. Ping an alle erreichbaren Geräte

$ ping6 -I en0 ff02::1
PING6(56=40+8+8 bytes) fe80::ca2a:14ff:fe2c:f6c5%en0 --> ff02::1
16 bytes from fe80::ca2a:14ff:fe2c:f6c5%en0, icmp_seq=0 hlim=64 time=0.071 ms
16 bytes from fe80::b248:7aff:fecb:2d57%en0, icmp_seq=0 hlim=255 time=0.423 ms

# Etwa 3 Sekunden warte, dann mit STRG+C / CRTL+C abbrechen

--- ff02::1 ping6 statistics ---
1 packets transmitted, 1 packets received, +1 duplicates, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.071/0.247/0.423/0.176 ms


# 2. Alle Geräte nacheinander testen. Tipp: Mit langsamsten Gerät (hier: time=0.423 ms) anfangen.
# Ein Kennwort muss zuvor im config-Mode gesetzt sein.

$ ssh root@fe80::b248:7aff:fecb:2d57%en0 
The authenticity of host 'fe80::b248:7aff:fecb:2d57%en0 (fe80::b248:7aff:fecb:2d57%en0)' can't be established.
RSA key fingerprint is d2:73:fe:42:a0:39:8a:c4:2b:59:45:09:c1:8f:7c:db.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'fe80::b248:7aff:fecb:2d57%en0' (RSA) to the list of known hosts.
root@fe80::b248:7aff:fecb:2d57%en0's password: 


BusyBox v1.19.4 (2013-02-14 10:13:36 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 ATTITUDE ADJUSTMENT (2013-02-14_10-09-15 (ff-kbu-continuous), 2013-02-14_10-09-15-continuous)
 -----------------------------------------------------
  * 1/4 oz Vodka      Pour all ingredients into mixing
  * 1/4 oz Gin        tin with ice, strain into glass.
  * 1/4 oz Amaretto
  * 1/4 oz Triple sec
  * 1/4 oz Peach schnapps
  * 1/4 oz Sour mix
  * 1 splash Cranberry juice
 -----------------------------------------------------
root@b0487acb2d58:~# dmesg
[    0.000000] Linux version 3.3.8 (tomcat6@ff-jenkins) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1 Thu Feb 14 10:35:58 CET 2013
[    0.000000] MyLoader: sysp=ffffffff, boardp=ffffffff, parts=f0f0f0f0
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU revision is: 00019374 (MIPS 24Kc)

# ... usw ...
# Vollständige(!) Ausgabe bitte per E-Mail an info@kbu.freifunk.net senden.

Externe Quellen

• "bugs" (ath9k-Projekt): http://wireless.kernel.org/en/users/Drivers/ath9k/bugs
• OpenWRT-Tickets
  • https://dev.openwrt.org/ticket/9654
  • https://dev.openwrt.org/ticket/11862

Rückmeldungen

Rampones Erfahrungen

• Bei mir treten diese WLAN Fehler vor allem auf den "lite-n/150Mbit" fähigen Geräten auf. Diese sind bei mir: wr740n v4.21 und wr741n v4.xx(noch nachschauen). Ein TX-DMA Fehler tritt auch gerne beim 1043ND auf, aber es "schiesst" WLAN bei weitem seltener ab (in einem halben Jahr nur einmal).
• Desweiteren scheint es so, ob würde beim unerlaubten option noscan '1' Modus der Router nicht so häufig abstürzen. (Es gibt ja auch den Vorschlag auf rein g zu schalten). Könnte der Nachbarschafts ssid scan um auf 40 MHz zuschalten ein wenig schuld dran sein? werde mal noscan 0' und ht20 probieren.

2014-07-05
<yanosz> tcatm: Koordinierst Du das Debugging zu den 1043nd issues mit nbd?
<tcatm> yanosz: Ja, rege in #freifunk/ircnet.
<yanosz> strange ... afair hatten wir auf dem wcw vereinbart, dass unsere ML Stand der Dinge sein soll.
<yanosz> Die Diskussion im IRC ging jetzt völlig an mir vorbei :-/
<tcatm> War auch quasi nur die Information, dass offenbar die BE-Queue hängt, wenn der Bug auftritt.
<yanosz> insb. weil ich von nbd eigentlich gehört hab', dass die 1043 jetzt gut aussehen.
<yanosz> und kein follow-up auf der Liste ... 
<yanosz> das stellt irgendwie so die existenzfrage an die Liste :-/
<tcatm> Wobei das alles auf anderen Geräten als den 1043nd war.
<yanosz> ok
<yanosz> auf welchen denn?
<yanosz> das sehe ich im Bugreport so eher nicht
<tcatm> UniFi und WDR3600 bisher.
<yanosz> ok
<yanosz> ich hab so das subjektive gefühl, dass AA da mal deutlich stabiler war ... und ziemlich viel als regression gekommen ist.
<tcatm> Ist halt alles sehr vage, darum hab ich noch keine Geräten bei geschrieben. Sobald ich was hab, was man halbwegs reproduzieren kann, schreib ich einen ausführlicheren Bugreport.
<yanosz> ok
<tcatm> Ja. Vielleicht könnte man dann auch mal bisecten.
<tcatm> T_X hatte auch eine stacktrace gesehen, der mit dem Problem zusammenhängen könnte: https://github.com/freifunk-gluon/gluon/issues/93#issuecomment-47997648
<yanosz> ggf.... es kann auch einfach sein, dass der Bug strange seiteneffekte hat
<yanosz> bspw. das unter load der Treibre nicht mehr schnell genug ist und in race conditions läuft
<tcatm> Möglich..
<tcatm> Ich vermute ja, dass es an "merkwürdigen" WLAN Chips in Clients liegen könnte.
<yanosz> auch denkbar
<neoraider> Also, AA ist instabil seit http://git.openwrt.org/?p=12.09/openwrt.git;a=commit;h=d29f21c84e2d8af8a5c18ceae80426c026ddac07
<tcatm> Ansonsten könnten wir vielleicht so eine Art Honeypot aufstellen. 1043er, die neben viel genutzten Knoten stehen und so viel Traffic abbekommen. Der andere Knoten könnte dann übernehmen, wenn der 1043er ausfällt.
<neoraider> Da wurde das erste mal ath9k von BB nach AA gebackportet
<tcatm> Ah. Das passt.
<tcatm> Evtl. erreichen wir die vorherige Stabilität schon allein durch reverten von http://git.openwrt.org/?p=12.09/openwrt.git;a=blob;f=package/mac80211/patches/540-ath9k_reduce_ani_interval.patch;h=e899903478b2488c62745779feaa71666cbb9756;hb=d29f21c84e2d8af8a5c18ceae80426c026ddac07
<neoraider> Naja, oder das Problem liegt nicht in einem der OpenWrt-Patches
<neoraider> Wer weiß
<yanosz> s/seit/bis/ ?
<yanosz> neoraider?
<neoraider> yanosz, nein, seit
<yanosz> ok
<neoraider> Also, auf 1043 war es eh immer instabil
<neoraider> Aber seit dem Commit ist es viel schlimmer geworden
<neoraider> Und auch auf viel mehr Geräten
<yanosz> ok.
<yanosz> danke für die Info
<yanosz> nbd weiß das, oder?
<tcatm> Klar, es liegt nicht direkt an den Patches. Der ANI Code scheint jedoch einen Einfluss auf die Stabilität zu haben und in einigen Bugreports war zu erkennen, dass ein kleiner ANI Interval solche Probleme verursacht.