|
dev-rke
Anmeldungsdatum:
14. Juni 2014
Beiträge: Zähle...
|
Hallo, nach dem Update von Ubuntu 13.10 auf Ubuntu 14.04 LTS vor etwas mehr als einem Monat habe ich kontinuierliche Netzwerk-Lags.
Dies äußert sich konkret in hohen Ping-Zeiten, was insbesondere bei Livestreams oder Spielen störend ist. Meine Infrastruktur:
Fritzbox (alle aktuellen Softwareupdates installiert)
TP-Link WND4800 (ath9k unter Kernel 3.13.0-29-generic) Ich hatte mich damals für die TP-Link entschieden, da der ath9k bereits WLAN unter 5ghz unterstützt.
Auch wenn es anfangs einige Probleme mit den tatsächlich nutzbaren Kanälen gab, habe ich das WLAN unter Ubuntu 13.10 stabil zum laufen bekommen.
Mit dem Update auf 14.04 scheint der Versand und Empfang von Daten im Abstand von ca. 100 Sekunden komplett einzufrieren:
Ping-Zeiten von 5ms zur Fritzbox steigen bis 2000ms. Die Dauer dieses Einfrierens beträgt ca. 5 Sekunden, danach läuft wieder alles für ca. 100 Sekunden.
Das betrifft sowohl Verbindungen unter 5ghz, als auch Verbindungen unter 2,4ghz. Anfangs dachte ich, es könnte etwas mit der Systemkonfiguration zu tun haben, dies kann ich nach einigen Tests jedoch ausschließen.
Wenn ich im GRUB Ubuntu 14.04 LTS mit dem älteren 3.11er-Kernel starte, verhält sich die Netzwerkverbindung ganz normal.
Keine Lags und auch keine Freezes, wenn ich einen Ping durchführe. Da dies abhängig von der genutzten Anwendung durchaus extrem störend sein kann:
Kann mir jemand weiterhelfen, wo ich mich tiefergehender informieren kann oder was konkret nun zu tun ist?
Ich vermute fast, dass hier ein Bugreport an die ath9k-Entwickler gehen müsste - allerdings dürfte das Problem ja auch noch andere
betreffen und trotz umfangreicher Suche habe ich bislang noch nichts ähnliches gefunden.
Kann ich euch irgendwelche hilfreichen Logfiles etc. zur Verfügung stellen, um den Fehler einzugrenzen? dmesg sagt bisher nichts negatives, wenn ich nach ath9k greppe, auch bei manuellem Einsehen des Logs keine negativen Nachrichten, die das Netzwerk betreffen.
Bei iwconfig sieht man den sich unregelmäßig erhöhenden Wert "Invalid misc:1209" - was genau heisst das und wo finde ich hierzu mehr Informationen?
Power Management der Karte ist auf off, kann auch manuell nicht aktiviert werden, nehme an, dass es sich hierbei um eine Einschränkung des Treibers handelt. Ich nutze Ubuntu nun seit über 2 Jahren auf dem Desktop, bin sehr zufrieden mit der Performance und habe auch einige auftretende Problemchen lösen können,
doch dieser Fehler stört mich sehr und ich habe bisher keinen Lösungsweg gefunden. Danke für eure Unterstützung. Gruß rke
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14246
|
dev-rke schrieb: nach dem Update von Ubuntu 13.10 auf Ubuntu 14.04 LTS vor etwas mehr als einem Monat habe ich kontinuierliche Netzwerk-Lags. Ping-Zeiten von 5ms zur Fritzbox steigen bis 2000ms. Die Dauer dieses Einfrierens beträgt ca. 5 Sekunden, danach läuft wieder alles für ca. 100 Sekunden.
Poste mal mit altem (13.10) und neuem (14.04) Kernel, die Ausgaben von:
modinfo ath9k mtr -4nr -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})mtr -4nur -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})
Die mtr-Tests dauern 5 Minuten (2 x 150 Sec.).
Evtl. auch mit deaktivierter "hardware encryption" beim ath9k versuchen. Siehe die Ausgabe von:
modinfo ath9k | grep -i nohwcrypt
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
Hallo lubux, Ubuntu 14.04 LTS, Kernel 3.13.0-29-generic modinfo ath9k
filename: /lib/modules/3.13.0-29-generic/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko
license: Dual BSD/GPL
description: Support for Atheros 802.11n wireless LAN cards.
author: Atheros Communications
srcversion: 470F4A9FC9506B4AE23CF37
alias: platform:qca955x_wmac
alias: platform:ar934x_wmac
alias: platform:ar933x_wmac
alias: platform:ath9k
alias: pci:v0000168Cd00000036sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000036sv0000185Fsd00003027bc*sc*i*
alias: pci:v0000168Cd00000036sv00001B9Asd00002810bc*sc*i*
alias: pci:v0000168Cd00000036sv0000144Fsd00007202bc*sc*i*
alias: pci:v0000168Cd00000036sv00001A3Bsd00002130bc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00000612bc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00000652bc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00000642bc*sc*i*
alias: pci:v0000168Cd00000036sv0000168Csd0000302Cbc*sc*i*
alias: pci:v0000168Cd00000036sv0000168Csd00003027bc*sc*i*
alias: pci:v0000168Cd00000036sv0000144Dsd0000411Ebc*sc*i*
alias: pci:v0000168Cd00000036sv0000144Dsd0000411Dbc*sc*i*
alias: pci:v0000168Cd00000036sv0000144Dsd0000411Cbc*sc*i*
alias: pci:v0000168Cd00000036sv0000144Dsd0000411Bbc*sc*i*
alias: pci:v0000168Cd00000036sv0000144Dsd0000411Abc*sc*i*
alias: pci:v0000168Cd00000036sv00001028sd0000020Ebc*sc*i*
alias: pci:v0000168Cd00000036sv0000103Csd0000217Fbc*sc*i*
alias: pci:v0000168Cd00000036sv0000103Csd000018E3bc*sc*i*
alias: pci:v0000168Cd00000036sv000017AAsd00003026bc*sc*i*
alias: pci:v0000168Cd00000036sv00001A3Bsd0000213Abc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00000662bc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00000672bc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00000622bc*sc*i*
alias: pci:v0000168Cd00000036sv0000185Fsd00003028bc*sc*i*
alias: pci:v0000168Cd00000036sv0000105Bsd0000E069bc*sc*i*
alias: pci:v0000168Cd00000036sv0000168Csd0000302Bbc*sc*i*
alias: pci:v0000168Cd00000036sv0000168Csd00003026bc*sc*i*
alias: pci:v0000168Cd00000036sv0000168Csd00003025bc*sc*i*
alias: pci:v0000168Cd00000036sv00001B9Asd00002812bc*sc*i*
alias: pci:v0000168Cd00000036sv00001B9Asd00002811bc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00006671bc*sc*i*
alias: pci:v0000168Cd00000036sv000011ADsd00000632bc*sc*i*
alias: pci:v0000168Cd00000036sv0000185Fsd0000A119bc*sc*i*
alias: pci:v0000168Cd00000036sv0000105Bsd0000E068bc*sc*i*
alias: pci:v0000168Cd00000036sv00001A3Bsd00002176bc*sc*i*
alias: pci:v0000168Cd00000036sv0000168Csd00003028bc*sc*i*
alias: pci:v0000168Cd00000037sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000034sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000034sv000010CFsd00001783bc*sc*i*
alias: pci:v0000168Cd00000034sv000014CDsd00000064bc*sc*i*
alias: pci:v0000168Cd00000034sv000014CDsd00000063bc*sc*i*
alias: pci:v0000168Cd00000034sv0000103Csd00001864bc*sc*i*
alias: pci:v0000168Cd00000034sv000011ADsd00006641bc*sc*i*
alias: pci:v0000168Cd00000034sv000011ADsd00006631bc*sc*i*
alias: pci:v0000168Cd00000034sv00001043sd0000850Ebc*sc*i*
alias: pci:v0000168Cd00000034sv00001A3Bsd00002110bc*sc*i*
alias: pci:v0000168Cd00000034sv00001969sd00000091bc*sc*i*
alias: pci:v0000168Cd00000034sv000017AAsd00003214bc*sc*i*
alias: pci:v0000168Cd00000034sv0000168Csd00003117bc*sc*i*
alias: pci:v0000168Cd00000034sv000011ADsd00006661bc*sc*i*
alias: pci:v0000168Cd00000034sv00001A3Bsd00002116bc*sc*i*
alias: pci:v0000168Cd00000033sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000032sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000032sv00001043sd0000850Dbc*sc*i*
alias: pci:v0000168Cd00000032sv00001B9Asd00001C01bc*sc*i*
alias: pci:v0000168Cd00000032sv00001B9Asd00001C00bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00001F95bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00001195bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00001F86bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00001186bc*sc*i*
alias: pci:v0000168Cd00000032sv00001B9Asd00002001bc*sc*i*
alias: pci:v0000168Cd00000032sv00001B9Asd00002000bc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Fsd00007197bc*sc*i*
alias: pci:v0000168Cd00000032sv0000105Bsd0000E04Fbc*sc*i*
alias: pci:v0000168Cd00000032sv0000105Bsd0000E04Ebc*sc*i*
alias: pci:v0000168Cd00000032sv000011ADsd00006628bc*sc*i*
alias: pci:v0000168Cd00000032sv000011ADsd00006627bc*sc*i*
alias: pci:v0000168Cd00000032sv00001C56sd00004001bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002100bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002C97bc*sc*i*
alias: pci:v0000168Cd00000032sv000017AAsd00003219bc*sc*i*
alias: pci:v0000168Cd00000032sv000017AAsd00003218bc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd0000C708bc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd0000C680bc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd0000C706bc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd0000410Fbc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd0000410Ebc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd0000410Dbc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd00004106bc*sc*i*
alias: pci:v0000168Cd00000032sv0000144Dsd00004105bc*sc*i*
alias: pci:v0000168Cd00000032sv0000185Fsd00003027bc*sc*i*
alias: pci:v0000168Cd00000032sv0000185Fsd00003119bc*sc*i*
alias: pci:v0000168Cd00000032sv0000168Csd00003122bc*sc*i*
alias: pci:v0000168Cd00000032sv0000168Csd00003119bc*sc*i*
alias: pci:v0000168Cd00000032sv0000105Bsd0000E075bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002152bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd0000126Abc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002126bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00001237bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002086bc*sc*i*
alias: pci:v0000168Cd00000030sv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Esv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Dsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Csv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Bsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Bsv00001A3Bsd00002C37bc*sc*i*
alias: pci:v0000168Cd0000002Asv000010CFsd00001536bc*sc*i*
alias: pci:v0000168Cd0000002Asv000010CFsd0000147Dbc*sc*i*
alias: pci:v0000168Cd0000002Asv000010CFsd0000147Cbc*sc*i*
alias: pci:v0000168Cd0000002Asv0000185Fsd0000309Dbc*sc*i*
alias: pci:v0000168Cd0000002Asv00001A32sd00000306bc*sc*i*
alias: pci:v0000168Cd0000002Asv000011ADsd00006642bc*sc*i*
alias: pci:v0000168Cd0000002Asv000011ADsd00006632bc*sc*i*
alias: pci:v0000168Cd0000002Asv0000105Bsd0000E01Fbc*sc*i*
alias: pci:v0000168Cd0000002Asv00001A3Bsd00001C71bc*sc*i*
alias: pci:v0000168Cd0000002Asv*sd*bc*sc*i*
alias: pci:v0000168Cd00000029sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000027sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000024sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000023sv*sd*bc*sc*i*
depends: ath9k_hw,mac80211,ath9k_common,cfg80211,ath
intree: Y
vermagic: 3.13.0-29-generic SMP mod_unload modversions 686
signer: Magrathea: Glacier signing key
sig_key: <<<RKE: REMOVED>>>
sig_hashalgo: sha512
parm: debug:Debugging mask (uint)
parm: nohwcrypt:Disable hardware encryption (int)
parm: blink:Enable LED blink on activity (int)
parm: btcoex_enable:Enable wifi-BT coexistence (int)
parm: bt_ant_diversity:Enable WLAN/BT RX antenna diversity (int)
parm: ps_enable:Enable WLAN PowerSave (int) mtr -4nr -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})
Start: Sun Jun 15 13:53:12 2014
HOST: RKE-PC Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.100 0.0% 150 1.7 57.1 1.5 1118. 229.6 mtr -4nur -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})
Start: Sun Jun 15 14:00:03 2014
HOST: RKE-PC Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.100 0.0% 150 2.3 29.1 1.6 1088. 165.1 Wie man an den Ergebnissen sieht: es gehen keine Pakete verloren, irgendwas scheint jedoch im System einzufrieren, sodass sehr hohe Lags entstehen.
Das System an sich reagiert in der Freeze-Time einwandfrei, d.h. es scheint sich nur ein Teilbereich (vermutlich im Bereich Netzwerk) zu verzögern. Die Ergebnisse vom 13.11er-Kernel poste ich nach dem Reboot.
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
Hallo lubux, ich meinte eben natürlich den 3.11er-Kernel. 😉 Hier nun die Ergebnisse für:
Ubuntu 14.04 LTS, Kernel 3.11.0-19-generic modinfo ath9k
filename: /lib/modules/3.11.0-19-generic/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko
license: Dual BSD/GPL
description: Support for Atheros 802.11n wireless LAN cards.
author: Atheros Communications
srcversion: E3D275FF9E422FF95A78D59
alias: platform:qca955x_wmac
alias: platform:ar934x_wmac
alias: platform:ar933x_wmac
alias: platform:ath9k
alias: pci:v0000168Cd00000036sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000037sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000034sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000034sv000010CFsd00001783bc*sc*i*
alias: pci:v0000168Cd00000034sv000014CDsd00000064bc*sc*i*
alias: pci:v0000168Cd00000034sv000014CDsd00000063bc*sc*i*
alias: pci:v0000168Cd00000034sv0000103Csd00001864bc*sc*i*
alias: pci:v0000168Cd00000034sv000011ADsd00006641bc*sc*i*
alias: pci:v0000168Cd00000034sv000011ADsd00006631bc*sc*i*
alias: pci:v0000168Cd00000034sv00001043sd0000850Ebc*sc*i*
alias: pci:v0000168Cd00000034sv00001A3Bsd00002110bc*sc*i*
alias: pci:v0000168Cd00000034sv00001969sd00000091bc*sc*i*
alias: pci:v0000168Cd00000034sv000017AAsd00003214bc*sc*i*
alias: pci:v0000168Cd00000034sv0000168Csd00003117bc*sc*i*
alias: pci:v0000168Cd00000034sv000011ADsd00006661bc*sc*i*
alias: pci:v0000168Cd00000034sv00001A3Bsd00002116bc*sc*i*
alias: pci:v0000168Cd00000033sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000032sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000032sv0000105Bsd0000E075bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002152bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002126bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00001237bc*sc*i*
alias: pci:v0000168Cd00000032sv00001A3Bsd00002086bc*sc*i*
alias: pci:v0000168Cd00000030sv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Esv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Dsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Csv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Bsv*sd*bc*sc*i*
alias: pci:v0000168Cd0000002Asv*sd*bc*sc*i*
alias: pci:v0000168Cd00000029sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000027sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000024sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000023sv*sd*bc*sc*i*
depends: ath9k_hw,ath9k_common,mac80211,ath,cfg80211
intree: Y
vermagic: 3.11.0-19-generic SMP mod_unload modversions 686
signer: Magrathea: Glacier signing key
sig_key: <<<RKE: REMOVED>>>
sig_hashalgo: sha512
parm: debug:Debugging mask (uint)
parm: nohwcrypt:Disable hardware encryption (int)
parm: blink:Enable LED blink on activity (int)
parm: btcoex_enable:Enable wifi-BT coexistence (int)
parm: enable_diversity:Enable Antenna diversity for AR9565 (int)
parm: ps_enable:Enable WLAN PowerSave (int) mtr -4nr -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})
Start: Sun Jun 15 14:14:27 2014
HOST: RKE-PC Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.100 0.0% 150 1.5 28.1 1.3 2547. 212.2
mtr -4nur -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})
Start: Sun Jun 15 14:19:56 2014
HOST: RKE-PC Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.100 0.0% 150 1.5 3.2 1.2 114.9 9.4 Interessant finde ich die Optionen
parm: debug:Debugging mask (uint)
parm: nohwcrypt:Disable hardware encryption (int)
parm: blink:Enable LED blink on activity (int)
parm: btcoex_enable:Enable wifi-BT coexistence (int)
parm: enable_diversity:Enable Antenna diversity for AR9565 (int)
parm: ps_enable:Enable WLAN PowerSave (int)
aus dem modinfo - das war mir bisher nicht bekannt.
Ich probiere diese auch mal aus, vielleicht stabilisiert sich die Verbindung dann oder ich komme an mehr Informationen. ☺ Danke für deine Unterstützung. Gruß rke
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14246
|
dev-rke schrieb: Ich probiere diese auch mal aus, ...
Versuch mal mit:
echo "options ath9k nohwcrypt=1" | sudo tee -a /etc/modprobe.d/ath9k.conf
sudo modprobe -rfv ath9k
sudo modprobe -v ath9k
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
Hallo lubux, Ubuntu 14.04 LTS, Kernel 3.13.0-29-generic mtr -4nr -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})
Start: Sun Jun 15 15:21:02 2014
HOST: RKE-PC Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.100 0.0% 150 923.5 40.8 1.4 1082. 184.7 mtr -4nur -c 150 -i 2 $(route -n | grep UG | awk {'print $2'})
Start: Sun Jun 15 15:27:38 2014
HOST: RKE-PC Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.100 0.0% 150 1.9 58.9 0.9 1159. 230.6 Ich bin mir nicht hundertprozentig sicher, ob die Hardwareverschlüsselung korrekt ausgeschaltet ist.
Vorhin hatte ich das Problem, dass das manuelle Neuladen des Moduls keine Verbindung zum Accesspoint mehr ermöglichte, weder unter 2,4 noch unter 5ghz.
Daher habe ich das System neugestartet. Die Option ist in der Datei ath9k.conf korrekt gesetzt.
Kann ich irgendwie prüfen, ob die Hardwareverschlüsselung im geladenen Modul deaktiviert ist bzw. ob die Optionen gesetzt sind und das Modul diese tatsächlich entsprechend geladen hat?
Hatte vor zwei Wochen ebenfalls schonmal versucht die Option nohwcrypt zu setzen - allerdings wie gerade eben ohne Erfolg. Mein Eindruck ist, dass es sich um ein Treiberproblem handelt, ggfls. im Zusammenspiel mit dem Kernel.
Allerdings bekomme ich auch mit aktivierter Debug-Option nicht mehr hilfreiche Ausgaben im dmesg.
Weitere Ideen? ☺ Edit: modinfo ath9k liefert mir hier keine Info über zusätzlich aktivierte Optionen des Moduls - das scheinen nur allgemeine Infos zum Modul selbst zu sein, aber
nicht über den Zustand. Gruß rke
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14246
|
dev-rke schrieb: Kann ich irgendwie prüfen, ob die Hardwareverschlüsselung im geladenen Modul deaktiviert ist bzw. ob die Optionen gesetzt sind und das Modul diese tatsächlich entsprechend geladen hat?
Mit:
cat /sys/module/ath9k/parameters/nohwcrypt
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
Gut, dies gibt mir "1" zurück, daher gehe ich dann davon aus, dass die Hardwareverschlüsselung deaktiviert ist.
Weitere Ideen? ☺
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14246
|
dev-rke schrieb: Weitere Ideen? ☺
Wie sind die Ausgaben von:
ifconfig -a
iwconfig
iwlist wlan0 scan
? EDIT: und von:
arp -av
?
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
ifconfig -a wlan1
wlan1 Link encap:Ethernet Hardware Adresse <<<RKE: removed>>>
inet Adresse:192.168.0.100 Bcast:192.168.0.255 Maske:255.255.255.0
inet6-Adresse: <<<RKE: removed>>> Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX-Pakete:57443 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
TX-Pakete:54643 Fehler:0 Verloren:0 Überläufe:0 Träger:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX-Bytes:39112617 (39.1 MB) TX-Bytes:9781766 (9.7 MB)iwconfig wlan1
wlan1 IEEE 802.11abgn ESSID:"<<<RKE: removed>>>"
Mode:Managed Frequency:5.24 GHz Access Point: <<<RKE: removed>>>
Bit Rate=90 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=40/70 Signal level=-70 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:158 Missed beacon:0
iwlist wlan1 scan
wlan1 Scan completed :
Cell 01 - Address: <<<RKE: removed>>>
Channel:48
Frequency:5.24 GHz (Channel 48)
Quality=39/70 Signal level=-71 dBm
Encryption key:on
ESSID:"<<<RKE: removed>>>"
Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=00000116fcce3edc
Extra: Last beacon: 60ms ago
IE: Unknown: 000C4C5A574E784B373570356C6E
IE: Unknown: 01088C129824B048606C
IE: Unknown: 030130
IE: Unknown: 073C4445202401172801172C01173001173401173801173C01174001176401176801176C01177001177401177801177C01178001178401178801178C0117
IE: Unknown: 200100
IE: Unknown: 2D1AEF011BFFFFFF00000000000000000080000000000406E6E70D00
IE: Unknown: 331AEF011BFFFFFF00000000000000000080000000000406E6E70D00
IE: Unknown: 3D16300F0400000000000000000000000000000000000000
IE: Unknown: 3416300F0400000000000000000000000000000000000000
IE: Unknown: DD180050F2020101030003A4000027A4000042435E0062322F00
IE: Unknown: DD0900037F01010000FF7F
IE: Unknown: DD0C00040E010102010000000000
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSKHier erstmal nur mein Accesspoint. Die anderen APs poste ich erstmal nicht mit, da das sehr aufwändig wäre, diese alle zu anonymisieren.
Wenn du es dennoch brauchst, bitte kurz Rückmeldung geben, dann mache ich das natürlich. Ich habe aber gerade mal etwas durchdacht: was passiert etwa alle 100 Sekunden? Scanrefresh!
Die Netzwerkkarte will wissen, was ist denn noch so im Umfeld existiert.
Wenn ich nun einen Ping gegen meinen Router laufen lasse und parallel einen Scan mit
sudo iwlist wlan1 scan
provoziere dann steigt der Ping massiv in die Höhe! Das ist interessanterweise jedes Mal reproduzierbar. Kann ich das automatische Scannen irgendwie deaktivieren?
Warum ist das unter dem alten Kernel bzw. dem alten Treiber nicht passiert?
Ich boote die Kiste mal durch und checke, ob das mit dem alten Kernel auch passiert, wenn ich das manuelle Scannen anstoße. Gruß rke
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
Ok, bin wieder unter Kernel 3.11.0-19-generic unterwegs.
Wenn ich jetzt parallel zum Ping einen Scan laufen lasse, steigt der Ping nicht merklich an - vielleicht mal 10 oder 15ms, aber keine 100 oder gar 1000.
Das Device ist also nicht blockiert. Die Frage ist jetzt also: ist die Ursache jetzt im Networkmanager oder im Kernel oder im Treiber zu suchen? ☺
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14246
|
dev-rke schrieb: provoziere dann steigt der Ping massiv in die Höhe! Das ist interessanterweise jedes Mal reproduzierbar.
Wie ist die Ausgabe von:
iwevent
?
Benutzt Du IPv6? Wenn nicht, dann evtl. mal deaktivieren. Wie ist die Routerkonfiguration betr. "802.11abgn"?
Poste auch die Ausgabe von:
arp -av
Evtl. kannst Du mit: sudo tcpdump -veni any host 192.168.0.100
sehen, was alle 100 Sec. passiert. EDIT: Versuch auch mal im Router nur 2.4ghz, 11g+n und einen der Kanäle 1 oder 6 oder 11 zu benutzen.
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
Hallo lubux, danke, dass ich auf dein Wissen zurückgreifen darf. ☺ Ich habe einen Ping gestartet mit dem tcpdump mitgehorcht und parallel iwevent laufen lassen. iwevent
Waiting for Wireless Events from interfaces...
16:45:44.714878 wlan1 Scan request completed
16:47:44.078627 wlan1 Scan request completed
16:49:43.874699 wlan1 Scan request completed
16:51:44.091961 wlan1 Scan request completed
16:53:43.870599 wlan1 Scan request completed
16:55:44.083319 wlan1 Scan request completed
16:57:44.078607 wlan1 Scan request completed
16:59:44.084553 wlan1 Scan request completed Der tcpdump zeigt korrekte ICMP requests und replys, ab und zu kommen dazwischen die ARP whohas, um die MAC's aufzulösen.
Ich nehme stark an, dass dies nichts mit der WLAN-Schnittstelle (sowohl Router als auch lokale NIC) zu tun hat,
auch nicht mit fremden WLANs, weil ich die hohen Ping selbst durch das Scanning reproduzieren kann und der Fehler nur dann auftritt,
wenn mir iwevent auch einen Scan meldet. Des Weiteren tritt der Fehler wie bereits gesagt nur mit dem 3.13er Kernel auf, mit dem 3.11er keine Probleme,
eine Fehlkonfiguration am Router etc. kann ich also eigentlich ausschließen. Gibt es eine Möglichkeit, ein Changelog von 3.11 zu 3.13 zu kriegen? Wenn ja, wo?
Die offiziellen Linux-Kernel-Changelogs kann ich ja nur eingeschränkt verwenden, weil die Ubuntu-Entwickler für ihren Kernel ja selbst noch eigene Patches einpflegen, richtig?
Wird der ath9k-Treiber eigentlich von den Kernel-Entwicklern gepflegt oder ist das ein eigenständiges, unabhängiges Projekt?
Ich bin mit der ganzen Entwicklungsthematik noch nicht so vertraut.
Ggfls. wäre es ja dann sinnvoll, dies als Bug zu melden.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14246
|
dev-rke schrieb: iwevent
Waiting for Wireless Events from interfaces...
16:45:44.714878 wlan1 Scan request completed
16:47:44.078627 wlan1 Scan request completed
16:49:43.874699 wlan1 Scan request completed ..., weil ich die hohen Ping selbst durch das Scanning reproduzieren kann und der Fehler nur dann auftritt,
wenn mir iwevent auch einen Scan meldet. ...
eine Fehlkonfiguration am Router etc. kann ich also eigentlich ausschließen.
Das mit dem "wlan1 Scan request completed", alle 2 Minuten ist schon seltsam. Dass der Router richtig konfiguriert ist, ist schon klar aber es geht darum, eine andere Konfiguration (z. B. 11n+g oder 11b+g) zu probieren. Evtl. werden dir die Treiberexperten helfen können. EDIT: dev-rke schrieb: ..., ab und zu kommen dazwischen die ARP whohas, um die MAC's aufzulösen.
Ich nehme stark an, dass dies nichts mit der WLAN-Schnittstelle (sowohl Router als auch lokale NIC) zu tun hat,
Das könntest Du auch testen, indem Du einen statischen arp-cache-Eintrag machst. Dann entfallen die "ARP whohas" zum Router. Z. B.:
sudo ip neigh flush all && sudo arp -i wlan1 -s $(route -n | grep UG | awk {'print $2'}) <für-das-WLAN-des-Routers-zuständige-MAC-Adresse>EDIT 2: Evtl. während eines Pings, auch die Ausgaben von:
watch 'dmesg -T | tail'
und
tail -f /var/log/syslog
beobachten.
|
|
dev-rke
(Themenstarter)
Anmeldungsdatum:
14. Juni 2014
Beiträge: 9
|
lubux schrieb: dev-rke schrieb: iwevent
Waiting for Wireless Events from interfaces...
16:45:44.714878 wlan1 Scan request completed
16:47:44.078627 wlan1 Scan request completed
16:49:43.874699 wlan1 Scan request completed ..., weil ich die hohen Ping selbst durch das Scanning reproduzieren kann und der Fehler nur dann auftritt,
wenn mir iwevent auch einen Scan meldet. ...
eine Fehlkonfiguration am Router etc. kann ich also eigentlich ausschließen.
Das mit dem "wlan1 Scan request completed", alle 2 Minuten ist schon seltsam. Dass der Router richtig konfiguriert ist, ist schon klar aber es geht darum, eine andere Konfiguration (z. B. 11n+g oder 11b+g) zu probieren. Evtl. werden dir die Treiberexperten helfen können.
Kannst du mir einen Treiberexperten empfehlen, der mich hierbei unterstützen kann?
Was gibt es sonst noch für Möglichkeiten?
Wie erreiche ich z.B. an die Entwickler vom Netzwerkmanager?
Ich muss zugeben, dass ich mich bisher nicht damit beschäftigt habe und es erschlägt einen bei der Fülle von Informationen
und Kontaktmöglichkeiten - ich weiß leider nicht, wo ich idealerweise anfange, daher habe ich mich mal hier angemeldet und meine Frage hier gestellt.
Wir sind ja auch schon ein ganzes Stück weitergekommen. ☺
EDIT: dev-rke schrieb: ..., ab und zu kommen dazwischen die ARP whohas, um die MAC's aufzulösen.
Ich nehme stark an, dass dies nichts mit der WLAN-Schnittstelle (sowohl Router als auch lokale NIC) zu tun hat,
Das könntest Du auch testen, indem Du einen statischen arp-cache-Eintrag machst. Dann entfallen die "ARP whohas" zum Router. Z. B.:
sudo ip neigh flush all && sudo arp -i wlan1 -s $(route -n | grep UG | awk {'print $2'}) <für-das-WLAN-des-Routers-zuständige-MAC-Adresse>EDIT 2: Evtl. während eines Pings, auch die Ausgaben von:
watch 'dmesg -T | tail'
und
tail -f /var/log/syslog
beobachten.
Leider nichts.
Es gibt zwar eine Fehlermeldung von der USB-Audio-Schnittstelle, die regelmäßig das Log zuspammt, aber daran arbeiten die Ubuntu-Entwickler gerade,
hatte ich zumindest bei Launchpad gesehen.
Wenn ich den USB-Audio-Adapter deaktiviere, kommt gar nichts. Vielen Dank für deine Unterstützung, hätte nicht gedacht, dass wir soviel heute überprüfen. ☺ Gruß rke
|