WLAN-Router Problem

[FabiUnne]

Hallo alle zusammen,

während "normale" Leute in den nächsten Elektrodiscount gehen, und sich ne Fritzdox kaufen, hab ich ihn mir selbst gebaut, naja versuche es.
Im Moment hänge ich bei der WLAN-Infrastruktur. Naja es läuft, aber instabil. Immer, wenn der WLAN-Stick (TP-Link TL-WN821N v3), kunfiguriet mit hostapd, mal wieder meint "Nee, jetz nicht mehr", schaltet er sich ab. Passiert aber nur während der laufenden Verbindung.

Fehlermeldung

Code: Alles auswählen

kernel: [12674.693501] usb 1-1.2: USB disconnect, device number 1
kernel: [12674.789142] ath: Failed to wakeup in 500us
kernel: [12675.101869] usb 1-1.2: ath9k_htc: USB layer deinitialized
---------------------------------------------------
kernel: [12677.453314] usb 1-1.2: new high-speed USB device number 5 using ehci_hcd
kernel: [12677.546061] usb 1-1.2: New USB device found, idVendor=0cf3, idProduct=7015
kernel: [12677.546063] usb 1-1.2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
kernel: [12677.546065] usb 1-1.2: Product: USB WLAN
kernel: [12677.546066] usb 1-1.2: Manufacturer: ATHEROS
kernel: [12677.546067] usb 1-1.2: SerialNumber: 12345
kernel: [12677.650307] usb 1-1.2: ath9k_htc: Transferred FW: htc_7010.fw, size: 72992
kernel: [12677.711525] ath9k_htc 1-1.2:1.0: ath9k_htc: HTC initialized with 45 credits
kernel: [12677.835523] ath9k_htc 1-1.2:1.0: ath9k_htc: FW Version: 1.3
kernel: [12677.835525] ath: EEPROM regdomain: 0x809c
kernel: [12677.835526] ath: EEPROM indicates we should expect a country code
kernel: [12677.835528] ath: doing EEPROM country->regdmn map search
kernel: [12677.835529] ath: country maps to regdmn code: 0x52
kernel: [12677.835530] ath: Country alpha2 being used: CN
kernel: [12677.835531] ath: Regpair used: 0x52
kernel: [12677.836023] ieee80211 phy1: Atheros AR9287 Rev:2
kernel: [12677.836539] Registered led device: ath9k_htc-phy1
kernel: [12677.836541] usb 1-1.2: ath9k_htc: USB layer initialized
kernel: [12678.036841] ADDRCONF(NETDEV_UP): wlan0: link is not ready

Google hat ergeben, dass dies ein Powerproblem ist, also dass der Stick zu wenig Saft bekommt. Nu kann ich aber halt nicht beeinflussen, wie viel mA aus der Buchse kommt. Ich weiß aber, dass USB3 bis zu 900mA erreicht. Laut Kernel will der Stick kein USB3, womit ich wieder bei Null wäre.

Fehlermeldung bei USB3:

Code: Alles auswählen

kernel: [65312.156829] usb 2-2: new high-speed USB device number 2 using xhci_hcd
kernel: [65312.175056] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
kernel: [65312.175556] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
kernel: [65312.176056] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
kernel: [65312.176547] xhci_hcd 0000:03:00.0: WARN: short transfer on control ep
kernel: [65312.176661] usb 2-2: New USB device found, idVendor=0cf3, idProduct=7015
kernel: [65312.176663] usb 2-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
kernel: [65312.176665] usb 2-2: Product: USB WLAN
kernel: [65312.176666] usb 2-2: Manufacturer: ATHEROS
kernel: [65312.176667] usb 2-2: SerialNumber: 12345
kernel: [65312.176746] usb 2-2: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes
kernel: [65312.176749] usb 2-2: ep 0x82 - rounding interval to 32768 microframes, ep desc says 0 microframes
kernel: [65312.176753] usb 2-2: ep 0x5 - rounding interval to 32768 microframes, ep desc says 0 microframes
kernel: [65312.176755] usb 2-2: ep 0x6 - rounding interval to 32768 microframes, ep desc says 0 microframes
kernel: [65312.537419] usb 2-2: ath9k_htc: Transferred FW: htc_7010.fw, size: 72992
kernel: [65312.537518] xhci_hcd 0000:03:00.0: ERROR no room on ep ring
kernel: [65312.541279] usb 2-2: ath9k_htc: Unable to allocate URBs
kernel: [65312.542204] ath9k_htc: probe of 2-2:1.0 failed with error -22

Hat von euch irgendjemand ne Idee, oder nne Vorschlag, was ich noch machen könnte?

Zur Hardware:
Debian Wheezy, ath9k_htc, Server Marke Eigenbau, Übriger Kram bind und dhcpd.

[catdog2]

Google hat ergeben, dass dies ein Powerproblem ist, also dass der Stick zu wenig Saft bekommt. Nu kann ich aber halt nicht beeinflussen, wie viel mA aus der Buchse kommt. Ich weiß aber, dass USB3 bis zu 900mA erreicht. Laut Kernel will der Stick kein USB3, womit ich wieder bei Null wäre.

USB<=2 liefert 500mA und in der Praxis liefern die Ports an den meisten Rechnern in der Regel eh schon um einiges mehr, ob es wirklich daran liegt?

Du hast doch bestimmt einen (mini)pci(express) Steckplatz frei? Wenn ja nimm eine entsprechende Karte, wie du selbst merkst sind die USB Teile nicht unbedingt ideal.

[FabiUnne]

naja meinte ich eig auch, aber ich wurde beratten, die Antennen der WLAN-Karte würden durch das Gehäuse zu sehr abgeschirmt werden. Und ich möchte ja erreichen, dass ich auf viel Raum schnell Daten I/O transportieren kann. Deswegen dachte ich an einen Stick, den ich n Meter höher, als den Server gestellt hab.

[catdog2]

naja meinte ich eig auch, aber ich wurde beratten, die Antennen der WLAN-Karte würden durch das Gehäuse zu sehr abgeschirmt werden. Und ich möchte ja erreichen, dass ich auf viel Raum schnell Daten I/O transportieren kann. Deswegen dachte ich an einen Stick, den ich n Meter höher, als den Server gestellt hab.

Kleiner Tipp: Es gibt auch (Antennen mit) Kabel zu kaufen. Sollten zwar wegen Verlust nicht zu lang sein aber 1m sollte nicht das große Problem sein. Dafür sind dann die Antennen besser als die in diesem USB Teil.

[ChoMar]

ALFA baut sehr interessante W-Lan Hardware. Aber nur für Experten, ansonsten betreibt man die dinger gerne mal in nem Illegalen bereich.

[FabiUnne]

okey, jetzt mal zu meinem Problem, denn was "besseres" zu kaufen ist immer einfacher.

Woran liegt das? Wie kann ich es lösen? (Stickwort USB3) Denn es war wirklich Arbeit einen Stick zu finden, dessen Chip mit Linux-Treibern AP fähig ist.

Welche kostengünstige Karten könnt ihr empfehlen, die WLAN-N erreichen, mind. 10 gleichzeitige Verbindungen halten, Full-HD Streams schaffen und so weit wie möglich guten Empfang liefern. PCI-Slot ist egal, bis jetzt is beim Server noch alles frei, weil das meiste sowieso schon auf dem Board zu finden ist.

[FabiUnne]

naja, wenn man sich die Fehlermeldung mal anschaut, ist die endscheidene Stelle eig bei

Code: Alles auswählen

kernel: usb 1-1.2: USB disconnect, device number 1
kernel: ath: Failed to wakeup in 500us
kernel: usb 1-1.2: ath9k_htc: USB layer deinitialized

Also noch genauer bei "Failed to wakeup in 500us". Spontan würd ichs mit: "Fehler beim aufwachen in 500us" übersetzen. Stellt sich die Frage, warm ein Stick in mitten einer Verbindung "nicht aufwacht" (nach dem Motto, wieso ist er eingeschlafen ) und das auch noch in 500us, was mir nichts sagt, und Google auch nicht. Hat jemand n Plan? Kanns vllt am Treiber liegen?

Gerade ist er wieder down gewesen und meiner Wahrnehmung nach kanns auch nicht an der Wärme liegen, weil son Chip ja auch sehr warm werden kann. Also liegt laut Kernel nur an (siehe oben).

Wäre gut, wenn mir jemand weiterhelfen könnte.

[unitra]

Code: Alles auswählen

Country alpha2 being used: CN

Der WLAN Router benutzt ein Frequenzband das ist Deutschland nicht zulässig ist.
Das sollte Countrycode DE sein, falls du nicht momentan in China wohnst.

[FabiUnne]

also laut der Conf on hostapd sollte er eig ne von deutschland nutzen. Mal blöd gefragt, wie kann man diese "Country being used" umstellen? Und wieso ist sie überhaupt umgestellt?
Ist das jetz n allgemeiner Bug, oder könnte es mit meinem PÜroblem zusammen hängen? Bogen nochmal auf die ungeklärte Frage meines letzten Posts.

[cirrussc]

USB 3.0, WLAN ... schon mal einen neuen bzw. aktuellen Kernel probiert? Eventuell ändert sich damit schon einiges.
Ist das überhaupt eine x86 kompatible Architektur?

Google hat ergeben, dass dies ein Powerproblem ist, also dass der Stick zu wenig Saft bekommt.

Das kann ich mir beim besten Willen nich vorstellen. Solche Sticks mögen zeitweise zwar viel brauchen, doch darf das nie über die max. Grenzen des jeweiligen VBuses geschehen (<=USB 2.0 500 mA, USB 3.0 900 mA).

[unitra]

also laut der Conf on hostapd sollte er eig ne von deutschland nutzen. Mal blöd gefragt, wie kann man diese "Country being used" umstellen? Und wieso ist sie überhaupt umgestellt?
Ist das jetz n allgemeiner Bug, oder könnte es mit meinem PÜroblem zusammen hängen? Bogen nochmal auf die ungeklärte Frage meines letzten Posts.

http://www.cisco.com/en/US/products/ps6 ... ddd8a.html Übersicht der Frequenzbänder und der Kanäle die pro Land zugeteilt sind für das WLAN. Ob das ein Bug ist, weiss ich nicht. Wenn du keine stabile Verbindung bekommst, könnte das u.A. auch die Ursache für das beschriebene Problem sein.

[catdog2]

http://www.cisco.com/en/US/products/ps6 ... ddd8a.html Übersicht der Frequenzbänder und der Kanäle die pro Land zugeteilt sind für das WLAN. Ob das ein Bug ist, weiss ich nicht. Wenn du keine stabile Verbindung bekommst, könnte das u.A. auch die Ursache für das beschriebene Problem sein.

Unwahrscheinlich, dass das das Problem ist. Die Tabelle stimmt übrigens nicht, in DE ist Kanal 1-13 erlaubt, die Tabelle sagt 1-11. (http://de.wikipedia.org/wiki/IEEE_802.11#802.11b.2Fg und http://git.kernel.org/?p=linux/kernel/g ... xt;hb=HEAD)

also laut der Conf on hostapd sollte er eig ne von deutschland nutzen. Mal blöd gefragt, wie kann man diese "Country being used" umstellen? Und wieso ist sie überhaupt umgestellt?
Ist das jetz n allgemeiner Bug, oder könnte es mit meinem PÜroblem zusammen hängen? Bogen nochmal auf die ungeklärte Frage meines letzten Posts.

Gleich mal das was iw phy phy0 info unter Frequencies steht (wenn der hostapd läuft) mit http://git.kernel.org/?p=linux/kernel/g ... xt;hb=HEAD ab. Dann siehst du ob du überhaupt ein Problem hast. Achja was du brauchst ist wireless-regdb und crda, damit die Umstellung funktioniert. Siehe auch http://wireless.kernel.org/en/developers/Regulatory/ .
Das einzige Problem was du bei Atheros Chips noch haben kannst ist, dass der Treiber das auf das beschränkt was im eeprom steht aber das CN dürfte >= DE sein im 2.4 Ghz Band.

USB 3.0, WLAN ... schon mal einen neuen bzw. aktuellen Kernel probiert? Eventuell ändert sich damit schon einiges.
Ist das überhaupt eine x86 kompatible Architektur?

Neuer Kernel ist auf jeden Fall was was man probieren sollte (und neuere firmware falls es eine geben sollte) bei solchen Problemen. Der Treiber kann wohl auch erst seit 2.6.30 AP mode(experimentell), der wheezy kernel ist nur 2 Releases später, der Ich gehe mal schwer von x86 aus, wo sonst findest du USB 3.0? Der Stick selbst ist natürlich nur USB 2.0 und wenn ich das richtig verstanden habe tritt das Problem sowohl an einem USB 3.0 Port als auch an einem USB 2.0 Port auf.

okey, jetzt mal zu meinem Problem, denn was "besseres" zu kaufen ist immer einfacher.

Wäre halt nie auf die Idee gekommen das an so einer Kiste mit USB zu realisieren. Gibt ja da kaum Chips mit denen man überhaupt AP Mode hinkriegt. ich vermute mal, dass die vom Hersteller in der Regel überhaupt nicht so wirklich dafür gedacht sind diesen Modus zu unterstützen und schon die Firmware nicht wirklich anständig daraufhin getestet ist. Wäre interessant ob das Problem auch ganz normal im station mode auftaucht.

//edit:

Welche kostengünstige Karten könnt ihr empfehlen, die WLAN-N erreichen, mind. 10 gleichzeitige Verbindungen halten, Full-HD Streams schaffen und so weit wie möglich guten Empfang liefern. PCI-Slot ist egal, bis jetzt is beim Server noch alles frei, weil das meiste sowieso schon auf dem Board zu finden ist.

Atheros Chipsatz ist zu empfehlen, zumindest ist die Treibersituation unter Linux generell mit die beste (wo du wieder bei TP-Link wärst, die verbauen fast nur die). Und dann kommt es halt auch preislich drauf an was du haben willst/brauchst (single band, dual band, 150Mbit, 300Mbit, ...).

[unitra]

http://www.cisco.com/en/US/products/ps6 ... ddd8a.html Übersicht der Frequenzbänder und der Kanäle die pro Land zugeteilt sind für das WLAN. Ob das ein Bug ist, weiss ich nicht. Wenn du keine stabile Verbindung bekommst, könnte das u.A. auch die Ursache für das beschriebene Problem sein.
Unwahrscheinlich, dass das das Problem ist. Die Tabelle stimmt übrigens nicht, in DE ist Kanal 1-13 erlaubt, die Tabelle sagt 1-11. (http://de.wikipedia.org/wiki/IEEE_802.11#802.11b.2Fg und http://git.kernel.org/?p=linux/kernel/g ... xt;hb=HEAD)

Frequenzbänder werden von der Bundesnetzagentur zugeteilt. Wenn man in einem Land wohnt, dann hat man die Frequenzen zu Nutzen die vorgeschrieben werden, und andere nicht zu Nutzen, weil Frequenzen ein knappes Gut sind. Daran müssen sich nicht nur Benutzer halten, sondern auch Hersteller.
Es ist egal ob die Tabelle falsch ist oder richtig, es geht nur darum dass folgende Meldung erscheint:

Code: Alles auswählen

kernel: [12677.835526] ath: EEPROM indicates we should expect a country code
kernel: [12677.835528] ath: doing EEPROM country->regdmn map search
kernel: [12677.835529] ath: country maps to regdmn code: 0x52
kernel: [12677.835530] ath: Country alpha2 being used: CN

[catdog2]

Frequenzbänder werden von der Bundesnetzagentur zugeteilt. Wenn man in einem Land wohnt, dann hat man die Frequenzen zu Nutzen die vorgeschrieben werden, und andere nicht zu Nutzen, weil Frequenzen knapp sind. Es ist egal ob die Tabelle falsch ist oder richtig
Es geht nur darum dass folgende Meldung erscheint:

Trotzdem ist die Tabelle falsch. Auf das wie man das umstellt bin ich eingegangen.

Wobei man sagen muss, dass es in diesem Fall wohl kein Problem ist (im 2.4 Ghz Band):

Code: Alles auswählen

149 country CN:
150         (2402 - 2482 @ 40), (N/A, 20)
151         (5735 - 5835 @ 40), (N/A, 30)

Code: Alles auswählen

199 country DE: DFS-ETSI
200         # entries 279004 and 280006
201         (2400 - 2483.5 @ 40), (N/A, 100 mW)
202         # entry 303005
203         (5150 - 5250 @ 40), (N/A, 100 mW), NO-OUTDOOR
204         # entries 304002 and 305002
205         (5250 - 5350 @ 40), (N/A, 100 mW), NO-OUTDOOR, DFS
206         # entries 308002, 309001 and 310003
207         (5470 - 5725 @ 40), (N/A, 500 mW), DFS

[habakug]

Hallo!

Das Umstellen des Ländercodes haben wir im Wiki [1].

Gruß, habakug

[1] https://wiki.debianforum.de/Ausl%C3%A4n ... _betreiben
Mehr Informationen hier [2]:
[2] http://wireless.kernel.org/en/developers/Regulatory

[catdog2]

Das Umstellen des Ländercodes haben wir im Wiki [1].

Hmm das sollte man mal umschreiben, damit es auf den den debian Paketen basiert, make install… naja.

[FabiUnne]

Erstmal danke für die vielen Ideen. Ich versuche sie jetzt mal zu beantworten.

Die Diskusion um den Countrycode hat mich nicht weitergebracht. Ein Debug von hostapd hat nichts ergeben. Hab daraufhin versucht mit "modprobe ath" den countrycode zu ändern, weswegen ich jetzt ne Fehlermeldung bekomme. Ich kann mir aber nicht vorstellen, dass mein Problem mit dem Frequenzbereich zusammen hängt, also es an der deutschen Landluft liegt. Außerdem müsste es ja dann eine Regelmäßigkeit geben. Und der Stick sag ja manchmal schon nach 2 Minuten nichts mehr, oder funktioniert 2 Tage ohne Probleme.

USB 3.0, WLAN ... schon mal einen neuen bzw. aktuellen Kernel probiert? Eventuell ändert sich damit schon einiges.
Ist das überhaupt eine x86 kompatible Architektur?

Google hat ergeben, dass dies ein Powerproblem ist, also dass der Stick zu wenig Saft bekommt.

Das kann ich mir beim besten Willen nich vorstellen. Solche Sticks mögen zeitweise zwar viel brauchen, doch darf das nie über die max. Grenzen des jeweiligen VBuses geschehen (<=USB 2.0 500 mA, USB 3.0 900 mA).

Meine Idee war dazu, dass der Stick zu wenig Saft bekommt, also eigentlich mehr als 500 mA bräuchte. Da USB3 ja mehr als 500 mA liefert, dachte ich, ich könnte dem Stick dann mehr mA zu Verfügung stellen. Wegen dem Kernel bin ich bis jetzt davon ausgegeangen, dass ich den neusten habe. Die Instalation ist jetzt 2 Wochen alt, es läuft Debian Wheezy amd64 - aktualisiert sich der Kernel nicht mit "apt-get upgrade". Ich hab extra drauf geachtet, dass ich möglichst alles neue sofort aktualsiere, auch wegen dem "Testing-Mode" von Wheezy.

Wäre halt nie auf die Idee gekommen das an so einer Kiste mit USB zu realisieren. Gibt ja da kaum Chips mit denen man überhaupt AP Mode hinkriegt. ich vermute mal, dass die vom Hersteller in der Regel überhaupt nicht so wirklich dafür gedacht sind diesen Modus zu unterstützen und schon die Firmware nicht wirklich anständig daraufhin getestet ist. Wäre interessant ob das Problem auch ganz normal im station mode auftaucht.

Naja, ich eigentlich auch nicht. TP-Link gewährleistet aber auf seiner Website ganz offen die AP-Unterstützung was aber auch auf der Verpackung stand. Also es wirklich ein für der AP-Mode gebautes Model. Der verwendete Treiber "ath9k_htc" ist auch als komplett AP-Mode fähig eingestuft.


In der Zwischenzeit habe ich mal den Stick getestet, unter anderem habe ich Windows problemlos eine Infrastruktur bauen können. Auf Debian kann ich den Stick als ganz normalen Managed-Mode benutzen, es muss also an der Software liegen. Was noch sein kann, ist, dass der Stick auf Deutschlang eingestellt war, aber jetzt falsch betrieben wird. Das erklärt aber immernoch nicht, warum der Stick random abbricht. Ich werde auf jeden Fall mal versuchen dieses Problem zu beheben.

naja, wenn man sich die Fehlermeldung mal anschaut, ist die endscheidene Stelle eig bei

Code: Alles auswählen

kernel: usb 1-1.2: USB disconnect, device number 1
kernel: ath: Failed to wakeup in 500us
kernel: usb 1-1.2: ath9k_htc: USB layer deinitialized

Also noch genauer bei "Failed to wakeup in 500us". Spontan würd ichs mit: "Fehler beim aufwachen in 500us" übersetzen. Stellt sich die Frage, warm ein Stick in mitten einer Verbindung "nicht aufwacht" (nach dem Motto, wieso ist er eingeschlafen ) und das auch noch in 500us, was mir nichts sagt, und Google auch nicht. Hat jemand n Plan? Kanns vllt am Treiber liegen?

Gerade ist er wieder down gewesen und meiner Wahrnehmung nach kanns auch nicht an der Wärme liegen, weil son Chip ja auch sehr warm werden kann. Also liegt laut Kernel nur an (siehe oben).

Wäre gut, wenn mir jemand weiterhelfen könnte.

Also endweder hab ichs übersehen, oder es ist noch niemanden etwas dazu eingefallen... Oder kann es sogar sein, dass das auch etwas mit dem Countrycode zu tun hat (was ich nciht glaube)???

[catdog2]

Ich kann mir aber nicht vorstellen, dass mein Problem mit dem Frequenzbereich zusammen hängt, also es an der deutschen Landluft liegt. Außerdem müsste es ja dann eine Regelmäßigkeit geben.

Das ist kaum der Grund für dein Problem ja.

Wegen dem Kernel bin ich bis jetzt davon ausgegeangen, dass ich den neusten habe. Die Instalation ist jetzt 2 Wochen alt, es läuft Debian Wheezy amd64 - aktualisiert sich der Kernel nicht mit "apt-get upgrade". Ich hab extra drauf geachtet, dass ich möglichst alles neue sofort aktualsiere, auch wegen dem "Testing-Mode" von Wheezy.

Wheezy ist im Freeze, der Kernel sogar schon länger. Du hast also dann 3.2, aktuell ist 3.5 in 1-2 Wochen schon 3.6. In experimental gibt es einen neueren, wenn du nicht selber bauen willst http://packages.debian.org/experimental ... runk-amd64 .

[FabiUnne]

*lach*
da der Homeserver im Moment mein Router, NAS und Cloud ist, wäre es unschön, wenn ich ihn kaputt machen würde.
Momentan bin ich auf dem Kernel 3.2.0-3-amd64, das ist soweit auch richtig.
Die Seite, die du mir geschickt hast, zeigt einmal den 3.5 Kernel, aber auch den "Experimentell" Hinweis. Ist der Kernel 3.5 schon so sicher, dass ich ihn auf einem Server richtig verwenden kann, oder kann es dann sien, dass ich zwar nie mehr Probleme mit dem AP hab, aber dafür die Cloud nicht mehr funktioniert??? Gibts ne Anleitung zum einfachen Kernel-update, dann ich glaub nicht das es mit "apt-get install kernel3.5" getan ist

//edit:
okey, ksist ja schon spät.
kann es sein, ich einfahc nur "apt-get install linux-image-3.5-trunk-amd64" ausführen muss. Irgendwie erscheint mir das zu einfach, als das es richtig sein könnte.

[catdog2]

Installiere das Ding einfach mal und teste, der alte bleibt erhalten und du kannst den booten auswählen: https://wiki.debianforum.de/Experimental

Die Qualität der Software in experimental ist sehr unterschiedlich, das geht von wirklich experimentellen Dingen zu stabilen upstream releases, die aus irgendwelchen Gründen nicht in unstable langen wie hier. Der wird halt nicht in der Version gepflegt sondern, wenn der 3.6 kommt wird der halt durch den ersetzt usw.

edit://
Fast siehe wiki.

[FabiUnne]

okey, Kernelinstalation hat ohne Probleme geklappt.
Ich werde jetzt mal bis morgen warten und sehen, ob sichs verbessert hat.

Kommen wir zu den nächstn Problemen:
Fehlerhafte Rechte-Zuweisung und
Fehlerhafe Namensauflösung von einer eigenen Domaintabelle zur internen IP. Wahrschenlich Ursache: Nameserver fühlt sich cniht angesprochen. Wenn es dazu noch Fragen gibt, werde ich mich auf jeden Fall nochmal melden

[FabiUnne]

Soo, da bin ich wieder mit der nächsten Meldung xD

Code: Alles auswählen

kernel: [16604.912913] usb 1-1.2: USB disconnect, device number 3
kernel: [16605.225077] ath: phy0: Failed to wakeup in 500us
kernel: [16605.236514] ath: phy0: Failed to wakeup in 500us
kernel: [16605.382283] usb 1-1.2: ath9k_htc: USB layer deinitialized
kernel: [16607.158038] usb 1-1.2: new high-speed USB device number 4 using ehci_hcd
kernel: [16607.250754] usb 1-1.2: New USB device found, idVendor=0cf3, idProduct=7015
kernel: [16607.250758] usb 1-1.2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
kernel: [16607.250761] usb 1-1.2: Product: USB WLAN
kernel: [16607.250763] usb 1-1.2: Manufacturer: ATHEROS
kernel: [16607.250766] usb 1-1.2: SerialNumber: 12345
kernel: [16607.251180] usb 1-1.2: ath9k_htc: Firmware htc_7010.fw requested
kernel: [16607.368898] usb 1-1.2: ath9k_htc: Transferred FW: htc_7010.fw, size: 72992
kernel: [16607.429952] ath9k_htc 1-1.2:1.0: ath9k_htc: HTC initialized with 45 credits
kernel: [16607.558201] ath9k_htc 1-1.2:1.0: ath9k_htc: FW Version: 1.3
kernel: [16607.558205] ath: EEPROM regdomain: 0x809c
kernel: [16607.558207] ath: EEPROM indicates we should expect a country code
kernel: [16607.558209] ath: doing EEPROM country->regdmn map search
kernel: [16607.558210] ath: country maps to regdmn code: 0x52
kernel: [16607.558212] ath: Country alpha2 being used: CN
kernel: [16607.558213] ath: Regpair used: 0x52
kernel: [16607.558909] ieee80211 phy1: Atheros AR9287 Rev:2
kernel: [16607.558978] cfg80211: Calling CRDA for country: CN
kernel: [16607.559746] Registered led device: ath9k_htc-phy1
kernel: [16607.563156] cfg80211: Current regulatory domain intersected:
kernel: [16607.563159] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [16607.563162] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
kernel: [16607.739320] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
kernel: [16620.014955] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
kernel: [16620.079644] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
kernel: [16623.169381] cfg80211: Calling CRDA to update world regulatory domain
kernel: [16623.173479] cfg80211: World regulatory domain updated:
kernel: [16623.173483] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
kernel: [16623.173486] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
kernel: [16623.173489] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
kernel: [16623.173491] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
kernel: [16623.173493] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
kernel: [16623.173495] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Der Kernel ist jetzt etwas gesprächiger, jedoch kommt immernoch "Failed to wakeup in 500us", was ich immernoch nicht erklären kann. Kernel schön und gut, aber irgendwie bin ich so weit wie vorher...

[r900]

Nach kurzer google-Suche: probier mal das Modul ath9k_htc zu entladen und dann mit der Option "nohwcrypt=1" zu laden.

Oder ist es eventuell ein Problem mit der Energieverwaltung? Also dass nach gewisser Zeit Geräte abgeschaltet werden um Energie zu sparen?

[FabiUnne]

das ist ungefähr so, als würdest du einem Hund sagen "Fahr mal Auto"
Hast dun Link zu? Was meinst du mit endladen? Beenden und dann mit ner anderen Config wieder hochfahren?

An der Energieverwaltung kanns wie gesagt nicht liegen, das es wirklich im laufenden Betrieb passiert. Also mitten im Spiel sagt der Stick "neeeee, ich cniht mehr" und geht offline.

[r900]

das ist ungefähr so, als würdest du einem Hund sagen "Fahr mal Auto"
Hast dun Link zu? Was meinst du mit endladen? Beenden und dann mit ner anderen Config wieder hochfahren?

Achso, ich war davon ausgegangen dass du halbwegs weißt was du tust. Ein Kernelmodul entlädt man (im Sinne von laden<->entladen) mit

Code: Alles auswählen

~# modprobe -r <Modulname>
~# modprobe <Modulname> <Optionen>

Wenn das Modul benutzt wird ist das allerdings etwas komplizierter. Also hier der einfacher zu erklärende Weg:

Code: Alles auswählen

~# echo "options ath9k_htc nohwcrypt=1" > /etc/modprobe.d/ath9k_htc.conf

Dann den Rechner neu starten.