Ath9k-Probleme - Versionsgeschichte

Yanosz am 28. August 2019 um 10:10 Uhr

2019-08-28T10:10:52Z

← Nächstältere Version		Version vom 28. August 2019, 12:10 Uhr
Zeile 1:		Zeile 1:
			[[Kategorie:Archiv]]
			{{:Archiv-Hinweis}}
	{{TOCright}}		{{TOCright}}
	(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 [http://wireless.kernel.org/en/users/Drivers/ath9k]) nicht richtig.		(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 [http://wireless.kernel.org/en/users/Drivers/ath9k]) nicht richtig.

Yanosz am 5. Juli 2014 um 12:35 Uhr

2014-07-05T12:35:07Z

← Nächstältere Version		Version vom 5. Juli 2014, 14:35 Uhr
Zeile 117:		Zeile 117:
	* 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).		* 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.		* 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.


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

Yanosz am 5. März 2013 um 14:30 Uhr

2013-03-05T14:30:44Z

← Nächstältere Version		Version vom 5. März 2013, 16:30 Uhr
Zeile 9:		Zeile 9:
	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]]		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]]

	~~Dazu~~ gibt es Aussagen, nach denen weitere, ''TP-Link WR1043ND'' bezogene Probleme vorliegen. Hierzu haben jedoch keine Details.<br />		Siehe auch: [[Ath9k-Probleme#Rückmeldungen\|Rückmeldungen]]

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

	'''Es ist insbesondere nicht klar:'''		'''Es ist insbesondere nicht klar:'''
Zeile 16:		Zeile 18:
	# Wie genau eine Störung aussieht		# Wie genau eine Störung aussieht
	# Welche Workrounds existieren		# Welche Workrounds existieren

	~~Siehe auch: [[Ath9k-Probleme#Rückmeldungen\|Rückmeldungen]]~~

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

Rampone: /* Rückmeldungen */

2013-02-25T17:03:50Z

Rückmeldungen

← Nächstältere Version		Version vom 25. Februar 2013, 19:03 Uhr
Zeile 116:		Zeile 116:
	'''Rampones Erfahrungen'''<br />		'''Rampones Erfahrungen'''<br />
	* 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).		* 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.

EGeist am 21. Februar 2013 um 19:30 Uhr

2013-02-21T19:30:23Z

← Nächstältere Version		Version vom 21. Februar 2013, 21:30 Uhr
Zeile 17:		Zeile 17:
	# Welche Workrounds existieren		# Welche Workrounds existieren

	~~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).~~		Siehe auch: [[Ath9k-Probleme#Rückmeldungen\|Rückmeldungen]]

	Quelle IRC-Channel ''#freifunk'' im IRCnet, 20.02.2013, abends:		Quelle IRC-Channel ''#freifunk'' im IRCnet, 20.02.2013, abends:
Zeile 112:		Zeile 112:
	** https://dev.openwrt.org/ticket/9654		** https://dev.openwrt.org/ticket/9654
	** https://dev.openwrt.org/ticket/11862		** https://dev.openwrt.org/ticket/11862

			==Rückmeldungen==
			'''Rampones Erfahrungen'''<br />
			* 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).

Rampone am 21. Februar 2013 um 18:12 Uhr

2013-02-21T18:12:05Z

← Nächstältere Version		Version vom 21. Februar 2013, 20:12 Uhr
Zeile 16:		Zeile 16:
	# Wie genau eine Störung aussieht		# Wie genau eine Störung aussieht
	# Welche Workrounds existieren		# Welche Workrounds existieren

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

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

EGeist: /* Umgang in Freifunk-KBU */

2013-02-21T15:31:00Z

Umgang in Freifunk-KBU

← Nächstältere Version		Version vom 21. Februar 2013, 17:31 Uhr
Zeile 24:		Zeile 24:

	== Umgang in Freifunk-KBU ==		== Umgang in Freifunk-KBU ==
	Die Freifunk-KBU [[Firmware]] enthält ab [http://jenkins.kbu.freifunk.net/files/release/~~latest/ff-kbu-tl-wr1043nd-v1-v.~~1.0~~.bin~~ Version 1.~~0beta11~~] ath9k-watchdog [https://github.com/ff-kbu/ath9k-watchdog]. Dieses Software überwacht ständig jeden Node. Erkennt der watchdog einen Ausfall, so wird		Die Freifunk-KBU [[Firmware]] enthält ab Version 1.0beta11, das ist eine Vorabversion der derzeitig aktuellen [http://jenkins.kbu.freifunk.net/files/release/1.0/ Version 1.0], ath9k-watchdog [https://github.com/ff-kbu/ath9k-watchdog].<br />
			Dieses Software überwacht ständig jeden Node.

			'''Erkennt der watchdog einen Ausfall, so wird:'''
	# Die Ausgabe des Kernel-Ringbuffers (dmesg) gesichert		# Die Ausgabe des Kernel-Ringbuffers (dmesg) gesichert
	# Der Node neu gestartet		# Der Node neu gestartet
Zeile 31:		Zeile 34:
	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.		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.		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! ==		== Wir brauchen Deine Hilfe! ==

EGeist: /* Bekannte Probleme */

2013-02-21T14:43:45Z

Bekannte Probleme

← Nächstältere Version		Version vom 21. Februar 2013, 16:43 Uhr
Zeile 9:		Zeile 9:
	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]]		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]]

	Dazu gibt es Aussagen, nach denen weitere, ''TP-Link WR1043ND'' bezogene Probleme vorliegen. Hierzu haben jedoch keine Details. Es ist insbesondere nicht klar,		Dazu gibt es Aussagen, nach denen weitere, ''TP-Link WR1043ND'' bezogene Probleme vorliegen. Hierzu haben jedoch keine Details.<br />
	# Welche Revisionen und ggf. Typen betroffen sind. Ist das Problem auf den TP-Link WR1043ND beschränkt?
			'''Es ist insbesondere nicht klar:'''
			# Welche Revisionen und ggf. Typen betroffen sind.
			# Ist das Problem auf den TP-Link WR1043ND beschränkt?
	# Wie genau eine Störung aussieht		# Wie genau eine Störung aussieht
	# Welche Workrounds existieren		# Welche Workrounds existieren

EGeist: /* Umgang in Freifunk-KBU */

2013-02-21T14:40:16Z

Umgang in Freifunk-KBU

← Nächstältere Version		Version vom 21. Februar 2013, 16:40 Uhr
Zeile 21:		Zeile 21:

	== Umgang in Freifunk-KBU ==		== Umgang in Freifunk-KBU ==
	Die Freifunk-KBU [[Firmware]] enthält ab Version 1.0beta11 ath9k-watchdog [https://github.com/ff-kbu/ath9k-watchdog]. Dieses Software überwacht ständig jeden Node. Erkennt der watchdog einen Ausfall, so wird		Die Freifunk-KBU [[Firmware]] enthält ab [http://jenkins.kbu.freifunk.net/files/release/latest/ff-kbu-tl-wr1043nd-v1-v.1.0.bin Version 1.0beta11] ath9k-watchdog [https://github.com/ff-kbu/ath9k-watchdog]. Dieses Software überwacht ständig jeden Node. Erkennt der watchdog einen Ausfall, so wird
	# Die Ausgabe des Kernel-Ringbuffers (dmesg) gesichert		# Die Ausgabe des Kernel-Ringbuffers (dmesg) gesichert
	# Der Node neu gestartet		# Der Node neu gestartet

EGeist: /* Umgang in Freifunk-KBU */

2013-02-21T14:09:47Z

Umgang in Freifunk-KBU

← Nächstältere Version		Version vom 21. Februar 2013, 16:09 Uhr
Zeile 21:		Zeile 21:

	== Umgang in Freifunk-KBU ==		== Umgang in Freifunk-KBU ==
	Die Freifunk-KBU ~~firmware~~ enthält ab Version 1.0beta11 ath9k-watchdog [https://github.com/ff-kbu/ath9k-watchdog]. Dieses Software überwacht ständig jeden Node. Erkennt der watchdog einen Ausfall, so wird		Die Freifunk-KBU [[Firmware]] enthält ab Version 1.0beta11 ath9k-watchdog [https://github.com/ff-kbu/ath9k-watchdog]. Dieses Software überwacht ständig jeden Node. Erkennt der watchdog einen Ausfall, so wird
	# Die Ausgabe des Kernel-Ringbuffers (dmesg) gesichert		# Die Ausgabe des Kernel-Ringbuffers (dmesg) gesichert
	# Der Node neu gestartet		# Der Node neu gestartet