BIGtec WLAN USB Stick - Probleme mit dem rt73usb Treiber

Ich habe mir vor einiger Zeit einen WLAN USB Stick von BIGtec/LogiLink gekauft, da ich meinen Rechner per WLAN mit dem Router ins Internet bringen wollte und der von diesem Stick verwendete Ralink Chipsatz sehr "linuxfreundlich" ist. Zum Zeitpunkt des Kaufes gab es ein OpenSource Treiber-Projekt und inzwischen ist der Treiber auch in den Kernel eingezogen, wird also bei jeder modernen Distribution mitgeliefert.

Stick also reingesteckt und siehe da, der Knetworkmanager sagt mir, dass das wlan0 Interface hinzugefügt wurde, super! Beim Versuch, mit dem Router zu verbinden, kommt zwar keine Fehlermeldung, allerdings wird immer "nicht verbunden" angezeigt und ein ping bleibt ohne Erfolg. Mist!

Ein Blick mit dmesg verrät, dass versucht wird, das rt2500 Modul zu laden und dies erwartungsgemäß schiefgeht, da auf dem Stick in Chipsatz verbaut ist, der das rt73usb Modul benötigt. Die Lösung: Das rt2500 Modul - und wenn man schonmal dabei ist, alle "ähnliche" Module, die Ralink Chipsätze ansteuern - blacklisten, so dass es von modprobe nicht mehr geladen wird. Hier der Eintrag in meiner /etc/modprobe.d/blacklist.conf:

#blacklist for rt73usb WLAN stick

blacklist rt2570

blacklist rt2500usb

blacklist rt2x00usb

blacklist rt2x00lib

blacklist rt73

In Zukunft wird nur noch das rt73usb Modul geladen und damit funktioniert der Stick problemlos, schnell und sehr stabil. Mein Stick identifiziert sich übrigens so:

lsusb -v

Bus 001 Device 002: ID 148f:2573 Ralink Technology, Corp. RT2501USB Wireless Adapter

Device Descriptor:

bLength 18

bDescriptorType 1

bcdUSB 2.00

bDeviceClass 0 (Defined at Interface level)

bDeviceSubClass 0

bDeviceProtocol 0

bMaxPacketSize0 64

idVendor 0x148f Ralink Technology, Corp.

idProduct 0x2573 RT2501USB Wireless Adapter

bcdDevice 0.01

iManufacturer 1 Ralink

iProduct 2 802.11 bg WLAN

iSerial 0

bNumConfigurations 1

Wie man sieht, wird unter der ID ein RT2501USB Chipsatz vermutet, was aber wie oben bereits erwähnt nicht richtig ist. Wo hier der Fehler liegt, also ob entweder in den Kernel-Quellen der falsche Chipsatz zu dieser ID eingetragen wurde oder aber tatsächlich WLAN USB Sticks auf dem Markt existieren, die diese Vendor und Device ID tragen und einen RT2501USB Chipsatz verwenden, weiß ich nicht. In letzterem Fall wäre dann die Schuld beim Hersteller.



UPDATE (07.05.09): Laut Ubuntu Bugtracker (siehe Kommentar von Ben Hutchings)liegt es tatsächlich daran, dass der Hersteller Sch... gebaut hat und gleiche IDs bei unterschiedlichen Chipsätzen vorkommen, so dass das geeignete Modul nicht automatisch bestimmt werden kann.



Wer wie ich den Stick an einem stationären PC benutzt, also sowieso immer nur zum gleichen WLAN-Netz verbindet, sollte auf den Knetworkmanager verzichten und die ganze Geschichte vom wpa_supplicant übernehmen lassen.

Dazu als erstes die Pakete network-manager, network-manager-gnome und network-manager-kde entfernen und das Paket wpasupplicant installieren.

Um das Passwort zum Verbinden nicht im Klartext in die Konfigurationsdatei reinschreiben zu müssen, kann es mittels wpa_passphrase MeineSSID MeinSchluessel in Hexadezimalform umgewandelt werden.

Anschließend wird die Datei /etc/wpa_supplicant/wpa_supplicant.conf angelegt (mit root, Rechte-Maske 0600) und gefüllt:

ctrl_interface=/var/run/wpa_supplicant

eapol_version=1

# 0: Der Treiber des Interfaces kümmert sich um das Scannen von Netzen und die AP-Auswahl.

# Dieser Modus sollte benutzt werden, wenn man eine Verschlüsselung auf ein Kabelnetzwerk legt.

# 1: wpa_supplicant kümmert sich um das Scannen von Netzen und die AP-Auswahl.

# 2: Fast wie 0, es wird aber mit Hilfe von Sicherheitsrichtlinien und der SSID zu APs verbunden (BSSID wird nicht unterstützt)

#

# Normalerweise funktioniert entweder Modus 1 oder Modus 2.

ap_scan=1

network={

ssid="MeineSSID" # hier kommt der SSID-Name rein

scan_ssid=1

proto=WPA

key_mgmt=WPA-PSK

#pairwise=TKIP

#group=TKIP

psk=2a6aa # hier kommt der in hex umgewantelte Schlüssel rein

}

Je nach Verschlüsselung müssen einige Optionen angepasst werden.

Getestet wird das Ganze mit wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -d und iwconfig.

Hat alles geklappt, trägt man den wpa_supplicant noch in die /etc/network/interfaces ein, damit die Verbindung bereits beim Systemstart aufgebaut werden kann:

# The loopback network interface

auto lo

iface lo inet loopback

# The primary network interface

auto wlan0

iface wlan0 inet dhcp

wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Von nun an steht die Verbindung auch unabhängig von KDE, was oft von Vorteil sein kann, wenn man z.B. mal im Textmode eine Datei per wget runterladen muss.