Ich erhalte WLAN-Zeitüberschreitungen mit dem Treiber rt2800usb


10

Ich verwende den rt2800usb-Treiber (mit einem RT5370-USB-Dongle) und konfiguriere meinen Raspberry Pi als WiFi-Hotspot mit Hostapd. Das Problem ist, dass ich regelmäßig Timeouts bekomme (siehe Beispiel). Dies wäre kein Problem, wenn ich mein RPi nicht als Fernbedienung für einen Quadcopter verwenden würde. Es scheint unabhängig davon zu sein, wie ich mein RPi mit Strom versorge, und es passiert mit allen Ralink-WLAN-Dongles dieses Typs, die ich habe.

Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Zeitüberschreitung der Anforderung.
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.42.1: Bytes=32 Zeit=1ms TTL=64

dmesg Ausgabe:

[ 2606.960813] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
[ 2606.960897] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
[ 2606.960925] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
[ 2606.961001] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 2606.961052] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 8 in queue 2
[ 2606.961093] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2
[ 2606.961133] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 10 in queue 2
[ 2606.961174] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
[ 2608.352291] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.352524] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.352766] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.353014] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.353262] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[ 2608.353511] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Ich habe eine kleine Grafik als Illustration vorbereitet. Ich habe meine eigene Ping-Funktion implementiert (mit variablen Timings aus Testgründen) und sehe alle ~ 12s eine Zeitüberschreitung (rot durch eine kleine Lücke gekennzeichnet). Ich glaube, der normale Benutzer wird diese Zeitüberschreitungen nicht bemerken, wenn er nur im Internet surft.

Geben Sie hier die Bildbeschreibung ein


Sie sagten, es scheint unabhängig davon zu sein, wie Sie den Pi antreiben. Bedeutet das, dass Sie mehrere verschiedene Netzteile ausprobiert haben?
AwesomeUser

Das heißt, ich habe versucht, direkt über das RPi und über den USB-Hub mit Strom zu versorgen. Alles gleich. Es scheint entweder ein Fehler von hostapd (unwahrscheinlich), rt2800usb oder der Firmware (rt2870) zu sein.
Grat

Haben Sie versucht, den Pi anders mit Strom zu versorgen?
AwesomeUser

Ja, das Problem hängt nicht mit der Stromversorgung zusammen. Ethernet funktioniert auch ohne Probleme.
Grat

Antworten:


7

Es scheint ein bekanntes Problem zu sein. Nach allem, was ich gefunden habe, können wir nur Folgendes tun:

# disable power management (may need to be done periodically?)
iwconfig wlan0 power off 

und deaktivieren Sie die Hardware-Verschlüsselung (so wird dies in der Software durchgeführt). Bearbeiten oder erstellen Sie /etc/modprobe.d/rt2800usb.conf:

options rt2800usb nohwcrypt=1

Vergessen Sie auch nicht, /lib/firmware/rt2870.bin gemäß diesem Artikel http://www.raspberrypi.org/forums/viewtopic.php?t=22623 von der MediaTek-Website zu aktualisieren !

Firmware-Versionen als Referenz:

md5:36c944c3138125605d28c0a3a1338be9 version 0.29 from Raspian base install
md5:ac4f6d8b679945208a978e397c016aa7 version 0.33 from DPO_RT5572_LinuxSTA_2.6.1.3_20121022 (MediaTek website)

Die Firmware-Version wird beim Booten auf dmesg in der folgenden Zeile gedruckt:
rt2x00lib_request_firmware: Info - Firmware erkannt - Version:


Warnung: Wenn Sie die HW-Verschlüsselung deaktivieren, wird Ihre CPU stärker belastet.
Martinlbb

Für meinen D-Link scheint die Firmware 0.33 hilfreich zu sein. Da es
heutzutage

0

Nach dem Update auf den neuesten Kernel habe ich 4 Stunden gebraucht, ohne fast so viele dieser Fehler zu machen. Verwenden Sie rpi-updatediese Option, um Ihren Kernel zu aktualisieren.

Als Referenz ist mein uname -a:

Linux boat-pi 3.12.28+ #713 PREEMPT Fri Sep 19 16:43:32 BST 2014 armv6l GNU/Linux

Ich bekomme immer noch rt2800usb_entry_txstatus_timeoutgelegentlich Fehler, aber es füllte mein dmesg. Ich bekomme die Got TX status for an empty queueFehler nicht mehr .

Aktualisieren:

Sprach zu früh. Mein Pi war 7 Stunden lang viel besser und bekam dann wieder eine Flut von Fehlern. Ich konnte nicht herausfinden, was die Fehlerfluten auslöst. Das Problem scheint nicht auf Raspberry Pi beschränkt zu sein (auch auf OpenWRT , Fedora , Kernel.org ). Es scheint, als würden einige Leute berichten, dass für eine bestimmte Zeit alles normal ist, bevor die Fehler auftreten.


0

Ich habe heute Morgen den Kernel aktualisiert (von Linux alarmpi 3.12.26-2-ARCH auf Linux alarmpi 3.12.28-2-ARCH) und seitdem mein Tagebuch mit gefüllt

rt2800usb_entry_txstatus_timeout: Warnung - Zeitlimit für TX-Status für Eintrag 6 in Warteschlange 2

Möglicherweise keine saubere Lösung, aber durch das Herabstufen des Kernels auf die vorherige Version funktionierten die Dinge wieder (mehr als 7 Stunden später).


0

Ich benutze ein Himbeer B +, Linux 3.12.32+, mit Wipi Wifi-Dongle. Der Pi befindet sich in einem Audio-Vorverstärker, wobei der WLAN-Dongle von außen über ein Verlängerungs-USB-Kabel (Typ A an der Schalttafel) angeschlossen ist. Es ist wichtig, dass die USB-Kabelmasse fest mit dem Gehäuse des Vorverstärkers verbunden ist. Andernfalls erhalten wir genau die in der Frage gezeigten Fehlermeldungen. Ich habe keine Verbesserung mit neueren rasbian oder aktualisierten Versionen von rt2870.bin (getestet v0.36) gesehen. In einigen Umgebungen können die dmesg-Fehlermeldungen auf Funkverschmutzung in unmittelbarer Nähe des WLAN-Funkgeräts zurückzuführen sein (Motoren erzeugen Frequenzen, die Funkgeräte stören können). Versuchen Sie, den Abstand zwischen dem Radio und der Störung zu maximieren und / oder die Funkabschirmung zu verbessern.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.