Gluon: Unstable ath9k WLAN

[AKA-47]

Das Problem wird aktuell hier im Forum diskutiert:

https://forum.freifunk.net/t/wifi-mesh-probleme-im-2012-2-gluon/9813/14

Die Konstellation:

Mehrere 841v10 mit 2012.2 im WIFI Mesh
getestet mit selbst gebauter Firmware und experimental builds anderer Site (also nicht von mir)
getestet zusätzlich mit 1043v2
KEIN 802.11s!!
Immer nur einen Knoten mit VPN

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?

[NeoRaider]

1. Ist noch ein direkter Ping über das Link-local auf dem ibss0-Interface möglich? Bitte sowohl Unicast (fe80::......%ibss0) als auch Multicast (ff02::1%ibss0) testen.
2. Wie sieht iw dev ibss0 station dump aus? Bitrate? Signalpegel?
3. Von batman-adv gemessene TQ zu den Nachbarknoten (batctl o)?

Uns sind bisher keine solchen Probleme aufgefallen.

[AKA-47]

1)
ping6 fe80::60e6:28ff:febe:18c4
PING fe80::60e6:28ff:febe:18c4 (fe80::60e6:28ff:febe:18c4): 56 data bytes
64 bytes from fe80::60e6:28ff:febe:18c4: seq=0 ttl=64 time=0.573 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=1 ttl=64 time=0.419 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=2 ttl=64 time=0.401 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=3 ttl=64 time=0.480 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=4 ttl=64 time=0.494 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=5 ttl=64 time=0.394 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=6 ttl=64 time=0.397 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=7 ttl=64 time=0.401 ms
64 bytes from fe80::60e6:28ff:febe:18c4: seq=8 ttl=64 time=0.477 ms
^C
--- fe80::60e6:28ff:febe:18c4 ping statistics ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 0.394/0.448/0.573 ms

ping6 ff02::1
PING ff02::1 (ff02::1): 56 data bytes
64 bytes from fe80::62e3:27ff:febe:18c4: seq=0 ttl=64 time=1.045 ms
64 bytes from fe80::62e3:27ff:febe:18c4: seq=1 ttl=64 time=0.664 ms
64 bytes from fe80::62e3:27ff:febe:18c4: seq=2 ttl=64 time=0.643 ms
64 bytes from fe80::62e3:27ff:febe:18c4: seq=3 ttl=64 time=0.722 ms
64 bytes from fe80::62e3:27ff:febe:18c4: seq=4 ttl=64 time=0.581 ms
--> alles super

2)
Node2:
iw dev ibss0 station dump
Station 62:e6:28:c6:d7:ee (on ibss0)
inactive time: 0 ms
rx bytes: 3504727
rx packets: 28048
tx bytes: 70611
tx packets: 795
tx retries: 104
tx failed: 0
signal: -38 [-39, -44] dBm
signal avg: -37 [-39, -43] dBm
tx bitrate: 130.0 MBit/s MCS 15
rx bitrate: 117.0 MBit/s MCS 14
expected throughput: 4.503Mbps
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

Node1:
Station 62:e6:28:be:18:c4 (on ibss0)
inactive time: 30 ms
rx bytes: 232907589
rx packets: 1909673
tx bytes: 4257570
tx packets: 25132
tx retries: 8100
tx failed: 47
signal: -37 [-41, -40] dBm
signal avg: -37 [-40, -40] dBm
tx bitrate: 65.0 MBit/s MCS 7
rx bitrate: 1.0 MBit/s
expected throughput: 3.194Mbps
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

3)
batctl o | grep ibss
62:e6:28:be:18:c4 0.170s (201) 62:e6:28:be:18:c4 [ ibss0]: 62:e6:28:be:18:c4 (201)

Hatte ich alles schon durchgecheckt. und konnte das Problem sogar an verschiedenen Standorten reproduzieren... bin ein wenig ratlos

[AKA-47]

Achso...und die andere Seite:
Node2:
batctl o | grep ibss | grep "62:e6:28:c6:d7:ee "
62:e6:28:c6:d7:ee 0.450s (209) 62:e6:28:c6:d7:ee [ ibss0]: 62:e6:28:c6:d7:ee (209)

[NeoRaider]

The Gluon master just got an updated mac80211 backport, which was reported to fix some ath9k issues.

[AKA-47]

Sehr gut! Jetzt geht alles wie es soll! Vielen Dank

[AKA-47]

Wann kommt dieser commit in die stable?

[jplitza]

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)

[NeoRaider]

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.

[A-Kasper]

Am 24.03.2016 um 22:48 schrieb Matthias Schiffer:

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.

Ich fänd das sehr sehr gut und wichtig. Ich hatte sogar schon überlegt
auf die 2015er zurück zu gehen, weil die wireless geschichten sich so
krass verschlechtert haben. Das ist schon eine sehr wichtige Funktionalität.

[NeoRaider]

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.

[NeoRaider]

_v2016.1.x-mac80211-test_ hat gerade ein weiteres Update bekommen, bitte testen.

[rotanid]

update heute nacht auf ein paar Knoten gespielt, schon jetzt hat einer davon wieder den Bug :-(
geringe sample size, würde aber bisher eher sagen es ist schlechter als ohne den test-branch

[oszilloskop]

Habe die v2016.1.x-mac80211-test nun seit 4 Tagen im Einsatz. Das Problem tritt weiterhin auf.
Bei mir sieht es so aus, als ob sich die v2016.1.4 und die v2016.1.x-mac80211-test bezüglich der Problemhäufigkeit nichts geben.

[NeoRaider]

v2016.1.x-mac80211-test enthält jetzt einen neuen Patch, bitte testen.

[NeoRaider]

Ähm... der neue Patch kompiliert noch nicht, einen Moment...

[NeoRaider]

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.

[NeoRaider]

Gibt's irgendwas neues hier?

[oszilloskop]

Ja, bin gerade mit meinen Test bezüglich d31c1c9 durch.
Leider tritt das Problem weiterhin auf.

Werde heute noch 548cf1d auf einige Router aufspielen.

[oszilloskop]

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...

[oszilloskop]

Hm, wie es aussieht, so hat sich nur die Häufigkeit verringert.
Ich habe jetzt noch 2 Knoten, welche ein/das Problem haben.

Nennen wir einen Problem-Knoten mal KPUTT
KPUTT hat die MAC ea:97:f7:a1:bf:2c

Chekov ist ein Knoten, der Wifi-meshend den Knoten KPUTT in die Wolke einbindet.

Der Befehl iw dev ibss0 station dump auf Chekov ergibt die unten aufgeführte Ausgabe.

Auffällig ist:

• Der Name von KPUTT kann nicht aufgelöst werden
• Die TX Bitrate von KPUTT hängt auffällig vier mal bei 1.0 MBit/s
• KPUTT (ea:97:f7:a1:bf:2c) taucht 5 mal auf)
• Auf unserer MAP liegt die TX TQ von KPUTT zu Cjekov bei 2-4%
• Auf unserer MAP ist die TX TQ von Chekov zu KPUTT nicht mehr aufgeführt

Ausgabe:

root@Chekov:~# iw dev ibss0 station dump
Station ea:97:f7:a1:bf:2c (on ibss0)
    inactive time:  6800 ms
    rx bytes:   782524109
    rx packets: 5289540
    tx bytes:   0
    tx packets: 0
    tx retries: 362968
    tx failed:  7023
    signal:     -53 [-55, -57] dBm
    signal avg: -53 [-55, -58] dBm
    tx bitrate: 1.0 MBit/s
    rx bitrate: 104.0 MBit/s MCS 13
    expected throughput:    43.303Mbps
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 23890 seconds
Station ea:97:f7:a1:bf:2c (on ibss0)
    inactive time:  6800 ms
    rx bytes:   782486698
    rx packets: 5289265
    tx bytes:   0
    tx packets: 0
    tx retries: 362968
    tx failed:  7023
    signal:     -53 [-55, -57] dBm
    signal avg: -53 [-55, -58] dBm
    tx bitrate: 1.0 MBit/s
    rx bitrate: 104.0 MBit/s MCS 13
    expected throughput:    4.119Mbps
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    no
    MFP:        no
    TDLS peer:  no
    connected time: 23889 seconds
Station ea:97:f7:a1:bf:2c (on ibss0)
    inactive time:  6800 ms
    rx bytes:   782487085
    rx packets: 5289266
    tx bytes:   0
    tx packets: 0
    tx retries: 362968
    tx failed:  7023
    signal:     -53 [-55, -57] dBm
    signal avg: -53 [-55, -58] dBm
    tx bitrate: 1.0 MBit/s
    rx bitrate: 104.0 MBit/s MCS 13
    expected throughput:    4.119Mbps
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    no
    MFP:        no
    TDLS peer:  no
    connected time: 23889 seconds
Station ea:97:f7:a1:bf:2c (on ibss0)
    inactive time:  6800 ms
    rx bytes:   782487085
    rx packets: 5289266
    tx bytes:   0
    tx packets: 0
    tx retries: 362968
    tx failed:  7023
    signal:     -53 [-55, -57] dBm
    signal avg: -53 [-55, -58] dBm
    tx bitrate: 1.0 MBit/s
    rx bitrate: 104.0 MBit/s MCS 13
    expected throughput:    4.119Mbps
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    no
    MFP:        no
    TDLS peer:  no
    connected time: 23889 seconds
Station ea:97:f7:a1:bf:2c (on ibss0)
    inactive time:  30 ms
    rx bytes:   804896639
    rx packets: 5668484
    tx bytes:   2285864334
    tx packets: 2674955
    tx retries: 362968
    tx failed:  7023
    signal:     -54 [-56, -58] dBm
    signal avg: -53 [-55, -57] dBm
    tx bitrate: 117.0 MBit/s MCS 14
    rx bitrate: 104.0 MBit/s MCS 13
    expected throughput:    43.303Mbps
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 23889 seconds

EDIT:
Ausgabe von batctl o | grep ea:97:f7:a1:bf:2c auf Chekov

ea:97:f7:a1:bf:2c    4.780s   (  4) ea:97:f7:a1:bf:2c [     ibss0]: ea:97:f7:a1:bf:2c (  4)

[oszilloskop]

Nochmal ich.
Nachdem ich auf Chekov! den Befehl wifi abgesetzt habe, sieht die Ausgabe von
root@Chekov:~# iw dev ibss0 station dump wie folgt aus:

Station ea:97:f7:a1:bf:2c (on ibss0)
    inactive time:  40 ms
    rx bytes:   157287
    rx packets: 2259
    tx bytes:   345672
    tx packets: 4342
    tx retries: 1050
    tx failed:  54
    signal:     -54 [-55, -58] dBm
    signal avg: -53 [-55, -58] dBm
    tx bitrate: 104.0 MBit/s MCS 13
    rx bitrate: 104.0 MBit/s MCS 13
    expected throughput:    40.283Mbps
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 143 seconds 

batctl o | grep ea:97:f7:a1:bf:2c ergibt folgendes:
ea:97:f7:a1:bf:2c 2.330s ( 7) ea:97:f7:a1:bf:2c [ ibss0]: ea:97:f7:a1:bf:2c ( 7)

Das ganze nochmal (wifi gefolgt von iw) ein zweites mal

root@Chekov:~# iw dev ibss0 station dump
Station ea:97:f7:a1:bf:2c (on ibss0)
    inactive time:  200 ms
    rx bytes:   10066
    rx packets: 145
    tx bytes:   0
    tx packets: 0
    tx retries: 0
    tx failed:  0
    signal:     -56 [-58, -61] dBm
    signal avg: -55 [-57, -60] dBm
    tx bitrate: 1.0 MBit/s
    rx bitrate: 1.0 MBit/s
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 18 seconds

und batctl o
ea:97:f7:a1:bf:2c 5.410s ( 12) ea:97:f7:a1:bf:2c [ ibss0]: ea:97:f7:a1:bf:2c ( 12)

KPUTT ist weiterhin nicht zu erreichen.

Hm, ist das jetzt das Problem von einem Router, oder des Zusammenspiel von beiden/mehreren Routern?

[NeoRaider]

Ok, eine vollständige Lösung aller Probleme wäre auch zu schön gewesen. 2 weitere Tests wären hilfreich:

1. In 548cf1d gibt es die Datei openwrt/package/kernel/mac80211/patches/990-test.patch; diese enthält 2 unabhängige Patch-Chunks. Diese beiden Chunks sollten einmal unabhängig voneinander getestet werden, um herauszufinden, welcher sich auf das Problem auswirkt. Nach Verändern der Patch-Datei einfach einmal make package/mac80211/clean ausführen, damit es neu gebaut wird.
2. Ich hatte die Ursache des Problems bisher auf eine Version zwischen compat-wireless 2015-03-09 und 2015-07-21 eingegrenzt, da nach dem Update auf 2015-07-21 vermehrt Bug Reports kamen. Was sind deine beiden Problemknoten für Hardware? Wenn die Hardware schon von 6e79982442b17de54a52ad4fc5e7ba1558475412 unterstützt wurde, wäre auch damit ein Vergleich hilfreich, um herauszufinden, ob das Problem auch unter 2015-03-09 auftritt.

[oszilloskop]

Die Problemknoten sind z.z. WR841 v8 und v10.

Okay, werde versuchen das alles mal irgendwie durchzutesten. Das wird mehrere Tage dauern.

[oszilloskop]

Aufgrund, dass ich nur eingeschränkten physischen Zugriff auf einige Problem Router habe, habe ich
vor mehrerenTagen nur den Commit 6e79982 aus Punkt 2. auf 12 Unterkunfts-Router aufgespielt (WR841 v8,V9 und V10).

• Das Fehlerbild der reduzierten Mesh TX-TQ ist innerhalb von 5 Tagen noch 3 mal aufgetreten (leider an einem wichtigen Mesh Knoten).
• Das Fehlerbild, das sich das WLAN komplett verabschiedet hat, trat bei mir noch 1 mal auf.

Ob und wann ich die Untersuchung aus Punkt 1. durchführen kann, ist noch nicht wirklich klar.

[oszilloskop]

Gerade hatte ich bei einem WR841 v8 mit Gluon v2016.1.5 einen Mesh-Hänger. Die meshende Gegenstelle sah den Router mit einer TQ von nur 5%.

Nachdem ich die Gegenstelle mit dem Befehl 'wifi' bearbeitet hatte, sah die Gegenstelle den Problem-Router (er tauchte auf der Statusseite auf), jedoch wurde als TQ lediglich ein '-' angezeigt.

Da der hängende Router per cronjob alle paar Stunden 'wifi' aufruft, konnte ich nach der Wiederbelebung des WLANs folgendes per 'dmesg' auslesen:

Hier klicken -> http://pastebin.com/0Re0uXJ0

Ab Zeil 231 wird es evtl. interessant.

[NeoRaider]

@oszilloskop, wie lange wartest du nach so einem Reset, bis du die TQ anschaust?

Allgemein dauert es etwa 10 Minuten, bis die TQ von einem neuen Link ihren endgültigen Wert erreicht hat, da die TQ aus einem gleitenden Mittelwert des Paketverlusts gebindet wird. Dazu kommt, dass eine TQ nur dann überhaupt von batman-adv ausgespuckt wird, wenn die direkte Verbindung bevorzugt ist. Wenn es also einen Zwischen-Hop gibt und batman-adv die Verbindung über den zusätzlichen Hop sinnvoller findet, wird als TQ für die direkte Verbindung immer nur '-' angezeigt.

Die Kernel-Meldung ist seltsam, ich würde am ehesten auf doppelte MAC-Adressen irgendwo in dem Setup tippen, aber ich bin nicht sicher...

Du hast geschrieben, dass es mit 6e79982 noch ein paar Mal Probleme gab. Kannst du irgendwie in Relation setzen, wie häufig die Probleme mit den verschiedenen Versionen sind? Tritt es mit 548cf1d etwa so häufig auf wie mit 6e79982, und mit v2016.1.x deutlich häufiger?

[oszilloskop]

@NeoRaider
Das mit der TQ ist extrems merkwürdig. Habe gerade wieder einen aktuellen Ausfall der gleichen Routers (WR851N v8). Nach einem "wifi" auf der Gegenstelle, wird auf der Gegenstelle die TQ des Problem-Router angezeigt und zwar wie folgt: Sie geht ziemlich schnell auf 17% hoch und läuft dann innerhalb von 2 Minuten auf 2% runter. Per batctl ping -c 10 xx:yy:zz war der Problemreouter zu keiner Zeit anpingbar.

Problemhäufigkeit.
v2016.1.x und 548cf1d geben sich nicht viel. Bei meinen Test sah es erst gut aus, nach 2-3 Tagen ist die Häufigkeit dann aber gleichgezogen und trat täglich bei mehreren Routern auf.

Der ältere 6e79982 sieht deutlich besser aus, ist aber auch nicht total clean. Häufigkeit deutlich unter 1 pro Tag und das auch auf weniger Routern (und manchmal inkl. Selbstheilung).

Hm. Ich hätte Protokoll führen sollen :o( und wünschte mir, es gibt noch weitere Tester :o)

[rotanid]

(EDIT: ach der issue ist ja deutsch...)
da wir unser workaround script nutzen, kann ich nicht viel helfen.
Heute hatten wir den Fall, dass ein client zwar im station dump des client0 devices sichtbar war, aber nicht in "batctl tl" und das wifi auch wirklich defekt war.
das war von unserem script noch nicht abgedeckt, es dachte sich "oh schön ein client, wohl alles ok!"

root@knotenname:~# iw dev client0 station dump
Station 84:1b:5e:XX:XX:XX (on client0)
    inactive time:  114290 ms
    rx bytes:   358547302
    rx packets: 1856844
    tx bytes:   33282786
    tx packets: 326875
    tx retries: 155949
    tx failed:  1533
    signal:     -66 [-74, -67, -77] dBm
    signal avg: -59 [-65, -64, -64] dBm
    tx bitrate: 72.2 MBit/s MCS 7 short GI
    rx bitrate: 65.0 MBit/s MCS 7
    expected throughput:    28.838Mbps
    authorized: yes
    authenticated:  yes
    preamble:   short
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 175704 seconds

[mbaumga]

Guten Abend miteinander. Ich habe gerade einen Knoten, dessen Nachbarknoten ein kaputtes Wifi hat und keine Mesh-Verbindung zusammenbekommt.

Der Knoten mit dem funktionierenden WLAN hat keine anderen Mesh-Partner in der Nähe, als den Knoten mit dem broken WLAN und auch keine Clients verbunden. Trotzdem erscheint bei iwinfo auf dem Mesh-Interface als Bit Rate 1.0Mbit/s. Normalerweise sollte ja bei fehlenden Verbindungspartnern die Rate auf "Unknown" wechseln.
Ich habe auf der Statusseite den kaputten Knoten mit konstanten 4% TQ als Mesh-Partner auf dem ibss0-Interface.

root@knotenname:~# iwinfo ibss0 info
ibss0     ESSID: "mesh.tecff"
          Access Point: 02:0F:8F:XX:XX:XX
          Mode: Ad-Hoc  Channel: 6 (2.437 GHz)
          Tx-Power: 14 dBm  Link Quality: 49/70
          Signal: -61 dBm  Noise: -95 dBm
          Bit Rate: 1.0 MBit/s
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: unknown [Generic MAC80211]
          TX power offset: unknown
          Frequency offset: unknown
          Supports VAPs: yes  PHY name: phy0

Normalerweise wird doch das Interface vor Verbindungsaufbau auf 1.0Mbit/s gesetzt und auch die Managementpakete damit verschickt, da ja noch kein Aushandeln der Übertragungsrate stattgefunden hat.

Dump, was so alles an Paketen rumfliegt auf den Mesh-Interfaces.

Summa Summarum: Bleibt der kaputte Router irgendwo zwischen Initialisierung des Verbindungsaufbaus und aushandeln der Verbindung einfach hängen?

Edit: Habe gerade aus Spaß "wifi" auf dem guten Router ausgeführt und die TQ schoss auf einen Schlag auf 45% hoch und ist nach <1min auf 2% gesunken. Die Übertragungsrate des ibss0-Interfaces ist laut iwinfo auf 130Mbit/s gestiegen und bleibt auch da.
Der Router mit dem broken Wifi ist aber weiterhin nicht zu erreichen.
Einen dump, was an Paketen rumfliegt kann ich leider nicht machen, da ich mir das monitoring-Interface mit dem Ausführen von "wifi" zerschieße und ich leider kein drittes Gerät in der Nähe habe zum dumpen. :(

Edit 2: Ich hab noch ein paar mal wifi ausgeführt und kam immer wieder zu verschiedene Ergebnisse:

• Die TQ schnellt kurz hoch und sinkt dann wieder in die Abgründe und das ibss0-Interface geht auf > 1.0 Mbit/s
• Die TQ verschwindet und die Bit Rate geht auf 1.0 Mbit/s

Die Ergebnisse kamen eher Random mal das Eine, oder das Andere.

Wifi wurde immer mit ein bisschen Zeit dazwischen ausgeführt, damit sich die Verbindung eventuell wieder fangen kann.

[Adorfer]

Ich habe auf der Statusseite den kaputten Knoten mit konstanten 4% TQ als Mesh-Partner auf dem ibss0-Interface.

Damit beschreibst Du ziemlich genau eines der 3-4 Szenarien: Clients verschwunden, alle Meshlinks von binnen Minutenfrist von von >80% auf 2-4% runter, dort aber "stabil"... unbenutzbar.

[rotanid]

hat es zwischenzeitlich jemand geschafft, das Problem gewollt zu reproduzieren durch irgendeine Form von künstlich erzeugtem Traffic auf einem bestimmten Übertragungsweg (ibss, client, ...)?
Ich leider nicht...

[bitboy0]

Ich weiß nicht ob ich das gleiche Problem hier haben könnte...
ffrn.de / gluon-v2016.1.5 stable und die versionen davor auch (seit 3 Monaten)

Mein Uplink-Knoten (1043v2) ist die ganze Zeit über online, aber alles dahinter ist tot. Auch kann man sich nicht einwählen. Ich hab jetzt einen Offloader hingestellt und da dran zwei Knoten. Einen 841V10, und den 1043v2.

Heute sah das dann so aus: http://s.ffrn.de/dashboard/db/nodes?var-Node=Ladenburg-OHS-001&var-Node=Ladenburg-OHS-002&var-Node=Ladenburg-OHS-003&var-Node=Ladenburg-OHS-004&var-Node=Ladenburg-OHS-005&var-Node=Ladenburg-OHS-006&var-Node=Ladenburg-OHS-T01&from=1468214317777&to=1468229889353

Beide Knoten (OHS-001 und OHS-T01) haben ca. 10 m zu OHS-002 und wenn nur einer der beiden ausfällt, müsste alles weiterlaufen. Aber BEIDE haben einfach für ne knappe Stunde nichts per WLAN gemacht. Keine Clients, kein Mesh. Dann ging alles wieder wie es soll.

Diese Unterbrechungen habe ich alle paar Tage und für eine Zeit von ca. 1h bis 8h.

Ab und an hatte ich auch einen Knoten der mit 5% TQ hing. Wenn ich alle Knoten außenrum neu gestartet habe, ging der wieder in's Mesh und lief dann auch wieder normal.

Sagt mir ob sich das für euch anfühlt, wie das Problem um das es hier geht?

[oszilloskop]

Ja, das hört sich genau nach diesem Problem an.

[NeoRaider]

Es gibt mal wieder ein mac80211-Update im Master, das einige Verbesserungen der ath9k-Stabilität bringen könnte.

[Sprinterfreak]

Tritt in Regensburg auch absolut random auf.
Ich hab hier aktuell 3 Knoten (2x 1043v2, 1x CPE210) bei denen es intensiv auftritt.
In der Tat ist es durch ausführen von wifizu beheben.
Drum habe ich auf betroffenen Knoten einen micron eingerichtet:

*/5 * * * * batctl gwl | grep '=>' >/dev/null || wifi

Der läuft alle 5 Minuten und holt sie wieder zurück, wenn kein Gateway verfügbar/selected ist.
So bleiben sie wenigstens administrierbar...
Evtl. sollte man den dirty fix bis zum finalen fix in den Snapshot mit übernehmen?
Häufigkeit ist von 2 Minuten bis 1x alle 2 Tage alles drin... Es ist auch nicht immer wirklich von der lokalen Netzlast abhängig. Interessant wäre hier gluon-airtime.
Läuft evtl. der Hardware-Puffer vom ath bei busy Air über? -> unhandled exception?
Wie reagiert batman auf halbe/korrupte Datagramme z.B. durch busy Air?

Die Knoten meshen lediglich über wlan nicht mehr. Per lan bleiben sie erreichbar.

An einem unserer zentralen Mesh's haben wir schon in früheren Zeiten einen pingenden Pi an einem 1043 zum "Neustarten" per Relais dran. :-)
Seit dem micron ist allerdings kein Powercycel mehr nötig gewesen.

[Sprinterfreak]

Der Bug ist wohl tatsächlich eher in dem ath9k-Treiber von openwrt zu suchen.
In #openwrt gibts exakt vergleichbare Reports auch ohne Gluon.

[NeoRaider]

@Sprinterfreak, ich wüsste nicht, wo ich den Fehler sonst suchen sollte, als in ath9k - dass es kein Gluon-spezifisches Problem ist, ist eigentlich klar.

Ich mache zur Zeit regelmäßig mac80211-Backports vom LEDE-master nach Gluon, um aktuellere Versionen der Treiber testen zu können, die einige interessante Bugfixes haben. Ich würde daher allgemein darum bitten, gelegentlich den Gluon-Master auszuprobieren und Feedback zu liefern, ob es damit besser läuft.

[rotanid]

@Sprinterfreak übrigens, dein Cronjob ist so nicht wirklich empfehlenswert, weil er im Zweifelsfall alle 5 Minuten das wifi wieder neustartet, obwohl schon der letzte Neustart nichts gebracht hat. guck dir mal das workaround package an: https://github.com/tecff/gluon-packages/tree/master/tecff-ath9k-broken-wifi-workaround

[Sprinterfreak]

@rotanid nicht schlimm. Wenn sowieso keine Gw-Verbindung besteht, darf neugestartet werden.
Ist ja auch nur ein Notfall-Einzeiler, der allerdings bisher sehr gute Ergebnisse an empfindlichen Stellen leistet. Behebt ja auch nicht das Problem, sondern nur die Auswirkungen und ist wie der broken-wifi-workaround keines Wegs eine "Lösung".

[kpanic23]

So wie es aussieht, hab ich den Bug mal in flagranti erwischt, und zwar auf einem Knoten mit VPN-Uplink. So konnte ich die Logs mal auslesen, vor und nach dem Ausführen von wifi.
Ich hoffe, es hilft weiter...

logread-vor-wifi.txt
logread-nach-wifi.txt

Edit: Sorry, hatte zweimal das gleiche File angehängt...

[NeoRaider]

Wie gut läuft ath9k zur Zeit im Gluon-Master? Besser/schlechter/ähnlich, relativ zu 2016.1.x?

[rotanid]

aus dem IRC:

03:30:57 < hexa- > hier ist alles prima mit gluon master
03:31:07 < hexa- > hab keinen mesh ausfall mehr feststellen können

[kpanic23]

Kann ich so unterschreiben!
Wir haben massive Probleme mit ein paar wenigen Knoten gehabt. Seit ich diese auf einen Master-Build (gluon-v2016.1-203-g91881f4) geflasht habe, ist Ruhe im Karton. Kein einziger Ausfall seither.

[AKA-47]

in der 2016.2.x commit a54e7654cda80c8b9ea3fc991719c1e254c4f995 konnte ich es wieder beobachten vgl.
https://bugs.lede-project.org/index.php?do=details&task_id=176

allerdings kommt das wifi irgendwann einfach zurück.

cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset
Baseband Hang: 0
Baseband Watchdog: 26
Fatal HW Error: 0
TX HW error: 0
Transmit timeout: 0
TX Path Hang: 140
PLL RX Hang: 0
MAC Hang: 0
Stuck Beacon: 213
MCI Reset: 0
Calibration error: 0
Tx DMA stop error: 209
Rx DMA stop error: 0

[Antaiir]

Hallo zusammen,

ich habe ebenfalls das Problem, daß einer der von mir betreuten Knoten ständig sein WLAN verliert. Es handelt sich um eine "Ubiquiti Bullet M2HP Titanium", auf welcher Gluon 2016.2 läuft.

Ich hänge mal 2 Ausgaben von logread an. Wenn ich zur Analyse noch mehr beisteuern kann, laßt es mich wissen. :)

logread_alt.txt
logread_neu.txt

[rotanid]

hi @Antaiir , wenn du wirklich Gluon in genau Version 2016.2 laufen hast, dann wäre der erste Rat, bitte eine aktuellere Version aufzuspielen, da im Branch v2016.2.x am Freitag ein Bugfix zu diesem Problem eingegangen ist, den dein Vorposter @AKA-47 bereits benutzt.

@AKA-47 was meinst du mit "es kommt zurück" und "irgendwann"? Ist da eine gleichbleibende Zeitspanne und etwas dazu passendes im Log erkennbar beispielsweise? vermutlich bleibt da aber vorerst das LEDE-Ticket dann der geeignetere Platz für dieses Problem...

[petabyteboy]

Bei uns sind die CPE210 v1.0 mit gluon-v2016.2-2-ga54e765 und 802.11s manchmal auf einmal taub. Die Gegenseite hört den Knoten aber noch. Das beobachten wir so jetzt zum 3. Mal in 3 Tagen. Logs gibts bald.

Außerdem haben wir eine CPE210 v1.0, die nicht mehr pingbar ist auf keiner ihrer IP-Adressen (nichtmal link-local), jedoch als Mesh-Link (nur mit MAC) in der Statusseite des Nachbarn angezeigt wird.

[Adorfer]

Das Zweite (batman-mesh läuft, ipv6 nicht mehr über air erreichbar) ist eventuel kein Radio-Bug, sondern eher im Batman zu suchen. (Hier läuft dagegen der Dir bekannte Ping-check auf eine Alias-IP, die redundant auf diversen Hosts erreichbar ist, nach erstmaliger Erreichbarkeit erfolgt bei fortgesetzter Nichterreichbarkeit ein Reboot.)

[petabyteboy]

https://petabyteboy.de/daten/dmesg
logread hatte nichts interessantes

[Antaiir]

Hallo zusammen,

ein Kollege hat für mich eine neue Firmware basierend auf dem von @rotanid erwähnten Patch gebaut und wir haben die Sache ein paar Tage beobachtet. Bis jetzt sieht alles gut aus, WLAN ist bei der besagten Bullet bisher nicht wieder weggeflogen und im Log stehen quasi nur noch diverse Handshakes drin, also ohne besondere Auffälligkeiten.

Danke. :)

VG
Antaiir

[petabyteboy]

Ich korrigiere: die Taubheit des Routers war offensichtlich nicht von einer Log-Nachricht begleitet. Die letzte Nachricht trat 5 Stunden vor dem Abbruch der Verbindungen auf.

@NeoRaider willst du das hier wieder öffnen oder soll ich ein neues anlegen?

[rotanid]

@plumpudding dann hätte man während der Taubheit, also vor einem reboot oder wifi befehl, den Inhalt von /sys/kernel/debug/ieee80211/phy0/ath9k/reset noch gebraucht am Besten.
und vielleicht die Ausgabe des station dump Befehls, falls da noch Geräte auftauchen sollten trotz "Taubheit".

[petabyteboy]

root@FF_GL_DRK_Jakobstr_101_UP:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset 
    Baseband Hang:  0
Baseband Watchdog:  0
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  0
        MCI Reset:  0
Calibration error:  0
Tx DMA stop error:  0
Rx DMA stop error:  0
root@FF_GL_DRK_Jakobstr_101_UP:~# iw dev mesh0 station dump
root@FF_GL_DRK_Jakobstr_101_UP:~# iw dev mesh0 scan
BSS f6:f7:6e:30:3c:48(on mesh0)
    TSF: 4358144384 usec (0d, 01:12:38)
    freq: 2472
    beacon interval: 1000 TUs
    capability: (0x0000)
    signal: -53.00 dBm
    last seen: 30 ms ago
    Information elements from Probe Response frame:
    SSID: 
    HT capabilities:
        Capabilities: 0x11ef
            RX LDPC
            HT20/HT40
            SM Power Save disabled
            RX HT20 SGI
            RX HT40 SGI
            TX STBC
            RX STBC 1-stream
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 8 usec (0x06)
        HT TX/RX MCS rate indexes supported: 0-15
    HT operation:
         * primary channel: 13
         * secondary channel offset: no secondary
         * STA channel width: 20 MHz
root@FF_GL_DRK_Jakobstr_101_UP:~# iw dev mesh0 station dump
Station f6:f7:6e:30:3c:48 (on mesh0)
    inactive time:  110 ms
    rx bytes:   107053
    rx packets: 813
    tx bytes:   2333
    tx packets: 17
    tx retries: 8
    tx failed:  0
    signal:     -50 [-50, -59] dBm
    signal avg: -49 [-50, -58] dBm
    tx bitrate: 117.0 MBit/s MCS 14
    rx bitrate: 144.4 MBit/s MCS 15 short GI
    expected throughput:    43.303Mbps
    mesh llid:  32047
    mesh plid:  56811
    mesh plink: ESTAB
    mesh local PS mode: ACTIVE
    mesh peer PS mode:  ACTIVE
    mesh non-peer PS mode:  ACTIVE
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 9 seconds
Station fa:32:0c:f4:fc:09 (on mesh0)
    inactive time:  110 ms
    rx bytes:   91094
    rx packets: 677
    tx bytes:   429
    tx packets: 6
    tx retries: 0
    tx failed:  0
    signal:     -56 [-56, -68] dBm
    signal avg: -55 [-55, -66] dBm
    Toffset:    -62128075304 us
    tx bitrate: 13.0 MBit/s MCS 1
    rx bitrate: 6.5 MBit/s MCS 0
    expected throughput:    9.612Mbps
    mesh llid:  56551
    mesh plid:  3384
    mesh plink: ESTAB
    mesh local PS mode: ACTIVE
    mesh peer PS mode:  ACTIVE
    mesh non-peer PS mode:  ACTIVE
    authorized: yes
    authenticated:  yes
    preamble:   long
    WMM/WME:    yes
    MFP:        no
    TDLS peer:  no
    connected time: 9 seconds
root@FF_GL_DRK_Jakobstr_101_UP:~# 

und nach dem scan war er dann auch nicht mehr taub...
passiert jetzt aber echt sehr regelmäßig mind. 1x am tag

[NeoRaider]

Ich werde zusehen, ath9k wieder in den Zustand von Commit 91881f4 zu bekommen, da wahrscheinlich in der Zwischenzeit ein neues Problem aufgetreten ist.

[NeoRaider]

Ich habe ein mac80211-Downgrade im Gluon-Master committed (487922a8d9b7ac564effe25632fd90e2cb6979b9). Bitte testen, wenn es läuft, kommt es nach v2016.2.x.

[kpanic23]

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.
Heute hat sich ein anderer Knoten weggehängt, ist aber vorhin wundersamerweise wieder aufgetaucht.
Ich habe mich gleich draufverbunden und das Log gezogen. Merkwürdigerweise steht im betreffenden Zeitraum absolut gar nichts im logread-Log. dmesg zeigt:
[18422.850000] ath: phy0: Timeout while waiting for nf to load: AR_PHY_AGC_CONTROL=0xd0dda

Logread: http://pastebin.com/pNyuKxzc

Kartenlink: https://map.freifunk-3laendereck.net/#!v:m;n:14cc2070948a

[Antaiir]

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
Antaiir

[petabyteboy]

Bei uns ist seit dem Update von https://github.com/freifunk-gluon/gluon/commit/a54e7654cda80c8b9ea3fc991719c1e254c4f995 auf https://github.com/freifunk-gluon/gluon/commit/1c3d97889adbdb6b7b316174645d6c5e92ad228d alles zurück bei alter Stabilität. In den letzten 2 Tagen hat kein Router durchgebootet und es wird mindestens das doppelte an Traffic geschoben (Testsubjekte sind CPE210 mit 802.11s).

[CodeFetch]

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):
https://github.com/torvalds/linux/commit/7da1ddddd55fdf478f712643e145e5d343f4ba46#diff-722db64892e310f0729be9025924ba52

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... Übermorgen werde ich mal berichten, wenn sich hier nichts anderes ergibt.
EDIT: Dauert noch etwas. Muss jetzt erst mal 2016.2.1 testen :+1: ...

Ä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?

[viisauksena]

as mentioned in the other Ticket ( #993 and maybe #889 )
at least with release v2016.2.x there is a light tendency for ibss0 (or whole wifi?) to fail/hickup .. being unresponsive
this is also mentionend in https://forum.freifunk.net/t/announce-gluon-v2016-2-1 and https://forum.freifunk.net/t/wifihaenger-in-gluon-2016-2-x-quickfix/13821
a working solution seem to be wifi (think @rotanid mentioned this ) or done successfull by myself iwinfo phy0 scan

here some lines from closed other tickets.. sorry for mixing denglish together

@rotanid du wolltest konkretes feedback,
Firmware mit dem master build zu dem zeitpunkt wo der 2016.2.1 rauskam, inkl make clean und make update im vorfeld. benutzt wird ibss0 und bat-v14 - aufgefallen an 2 unterschiedlichen Tplink 841 - die autoupdate hinter sich haben.

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.
gelöst wurde das temporär mit einem Stündlichen iwinfo phy0 scan als micron job
daher der Bugname "hickup".

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)

[viisauksena]

weis nicht ob das zusammenhängt, aber eine "seltsame" beobachtung kurz hier notiert:
an einem meshenden laufenden router ohne symptome
iwinfo phy0 scan ;dmesg |tail -n 2; logread | tail -n2
erzeugt VOR dem output von iwinfo noch

[11062.610000] IPv6: ADDRCONF(NETDEV_UP): tmp.phy0: link is not ready
Sun Nov 13 19:45:50 2016 kern.info kernel: [10964.770000] IPv6: ADDRCONF(NETDEV_UP): tmp.phy0: link is not ready

aber das vielleicht einfach nur ein relikt weil phy0 kein direktes if ist, tauscht man das mit ibss0 client0 oder so - gibts keinen fehler

[rotanid]

hier noch 2 Fehlerberichte aus dem Freifunk Forum kopiert, damit wir alles an einem Platz haben.
Meine Fragen waren:

• 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

von @Tarnatos

• 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
• http://pastebin.com/iL93gBDf
• http://pastebin.com/ttArb9YP

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

• ibss (1 ibss Link und 3 Clients als es auftrat)
• logread: kein Eintragungen, es verschwinden nach und nach die Clients mit "deauthenticated due to inactivity (timer DEAUTH/REMOVE)"
  dmesg: keine Eintragungen
• 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

von mir selbst:

Baseband Hang:  0
Baseband Watchdog: 330
   Fatal HW Error:  0
      TX HW error:  0
 Transmit timeout:  0
     TX Path Hang:  0
      PLL RX Hang:  0
         MAC Hang:  0
     Stuck Beacon:  1
        MCI Reset:  0
Calibration error:  0
Tx DMA stop error:  0
Rx DMA stop error:  0

[viisauksena]

was bringt das cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset .. hab hier router die haben da einiges dramatischere Werte und fahren seit Tagen problemlos inkl meshenden Routern und Traffic im GB bereich

edit: wer sind denn "die" entwickler .. ath9k?
(mal von einem sauber laufenden router - paar tage mitmesh und gb traffic und immer wieder clients)
ath9k_debug.txt

[rotanid]

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

[Tarnatos]

Wir haben hier einen weiteren bestätigten Fall:
http://mesh.freifunk.in-kiel.de/#!v:m;n:10feede661f4

• Gluon 16.5
• IBSS auf einem WR1043v2

Nach einem iw client0 scan kamen alle Nachbarn wieder.

Logs:
wifi-down-gluon-605.txt

[rotanid]

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 :)

[viisauksena]

than an announcement with an proposed commit-id in the forum would be fine - or some extra branch/tag

[petabyteboy]

A commit id posted here and it will be on 20 nodes tomorrow

[CodeFetch]

Are you all going mad?! Can you please stop using this as a forum?
Nothing has been fixed - the issue was closed, because people were acting like you being no help.
It is clearly a DMA lock error. No matter how many logs you post with the same commands executed it will be the same phenomenon. Tx DMA stop error, Stuck beacon... Google it if you don't know what it is.
Unless the LEDE kernel source isn't updated to a very recent version, chances are bad, that it contains the needed fix. And it isn't said that the bug didn't exist before. Maybe it just occurs more frequently since e.g. powersave update. There are many patches in kernel master which address issues similar to this. Go and test the patches or wait until someone else did, but this "forum culture" here is just distracting...

[viisauksena]

@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?

[rotanid]

@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.
@CodeFetch either you know the relevant patches, then please name them. perhaps you are testing the patches, then please report about the results or even provide instructions or binaries so others could participate in testing - or if you don't know or test, i don't see what your comment is about other than "distracting".

[CodeFetch]

It's the last I'm going to say on that issue here...
@viisauksena This issue occured often in kernel history and you can find lots of information on it. It can have many reasons but all are related to the device driver (in this case ath9k). You can identify this as a DMA lockup because of the stuck beacons, the Tx DMA stop error or basebandwatchdog interrupts. Tx DMA stop error means that it was tried to remove packets from the queue and it failed. Stuck beacons means that beacons in the queue were removed as they took too long to be sent (no airtime and I mean NO airtime - e.g. radar) or there was a lockup in the DMA queue (I mean the hardware thing in the wifichip) and they just can't be sent anymore. I don't really know the Basebandwatchdog code, but it can also be triggered if there's a DMA lockup and tries to reset the device if there is a failure in general. So if you have either Tx DMA stop errors or stuck beacons or basebandwatchdog issues it is a good hint that the "DMA locked" at a specific state. No, that's not recent enough I think. There are many, many patches for newer chipsets that were released in the last months which are simply being overlooked by LEDE and OpenWrt. They are quite relevant because the board design of newer devices change the chips' behaviour (e.g. temperature compensation patch works well on one device and makes the problem worse on another - both having identical chipsets but another board revision). The Qualcomm-devs release patches for their customers (e.g. TP-Link) if they find such a weird behaviour in one of their boards. And that's one of the problems. On the one hand they don't test if an "outdated" board will still work with their patch, on the other private folks do. It's hard to properly support every board. So you really have to be careful what patches you add.

@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.

[rotanid]

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 hope your findings will lead to improvements upstream, even if you're not going to comment again here.

[viisauksena]

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.
While the router has own uplink, the normal "emergency-script" in fffr wouldnt work - since this only target loss of network and not crippled mesh network. (like restarting wifi, iwinfo phy scan, restarting fastd, restarting network etc).
This router have a working hourly micrond job iwinfo phy0 scan - which i thought would prevent this loosing of mesh links - which it does not! A manual check batctl o -H|grep -v mesh-vpn support this - instead wifi command do resolve this issue. This is clearly not the the hacky way to go - a hourly wifi. (extremly hacky micron.d if [ $(uci get wireless.ibss_radio0.disabled) -eq 0 ]; then if [ $(batctl o -H|grep -v mesh-vpn|wc -l) -eq 0 ]; then iwinfo ibss0 scan|grep -q $(uci get wireless.ibss_radio0.bssid) && wifi ;fi;fi)

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.

cat /sys/kernel/debug/ieee80211/phy0/ath9k/reset is all 0 (no DMA errors or stuck beacons as suggested by @CodeFetch - uptime 11h right now)

FW is build around 23.Nov. with this commit
http://openfreiburg.de/freifunk/meshviewer/#!v:m;n:60e3275a2aec
http://openfreiburg.de/freifunk/meshi2/#!v:m;n:60e3275ffdd2

[rotanid]

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.

[NeoRaider]

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

[NeoRaider]

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.