Unfrisiertes

Da in meiner neuen Wohnung der Telefonanschluss denkbar ungünstig liegt, wollte ich alle meine Rechner auf WLAN umstellen (siehe Umzug - Zwischenstand). Nun ist es eine gute und anständige Seite von Linux, den Nicht-Unix-Guru ständig an sein unwürdiges Dasein als DAU zu erinnern und ihm beim Versuch, etwas Neues einzurichten, eine Vorgehensweise nahezulegen, die man auch von buddhistischen Klöstern erwarten würde. Gefragt sind Demut, Geduld und das Hören auf die weisen Worte der Meister.

Man hat, wenn man als Linuxer seinen Rechner per Adapter an ein WLAN anschließen möchte, im Prinzip drei Möglichkeiten:

1. Es gibt einen sog. “nativen” Treiber. Hoffentlich ohne große Beschränkungen.
2. Man probiert, die Windows-Treiber über das freie Tool ndiswrapper zu nutzen.
3. Siehe 2., nur diesmal mit dem kommerziellen Werkzeug “DriverLoader” von Linuxant.

Nun, ich habe alle drei Möglichkeiten probiert (Linuxant offeriert zum Glück eine kostenlose 30-Tage-Lizenz), um meinen stationären Rechner, einen Shuttle XPC, auf dem ein aus Kanotix hervorgegangenes Debian Sid läuft, ans Netz zu bringen. Für 2. und 3. müssen Linuxer allerdings zu Detektiven werden, gilt es doch, den von den jeweiligen Anbietern verwendeten Chipsatz herauszufinden, und nichts scheinen diese lieber zu tun als diesen unter Beibehaltung des Produktnamens ständig auszutauschen.

Mein erster Versuch mit der fummelig einzubauenden Standard-Lösung für Shuttle XPCs, deren Chipsatz Zydas 1211 angeblich von Linuxants DriverLoader unterstützt wird, ging schief. DriverLoader ließ sich nur ein einziges Mal dazu bewegen, die Windows-Treiber zu akzeptieren, zickte dann aber wegen des falschen (=neuen) C-Compilers rum und ließ sich auch nach Lösung dieses Problems nicht in den Speicher zwängen.

Im zweiten Anlauf versuchte ich es mit einem D-Link GW122 USB-Adapter, dessen neuer Chipsatz RT2500 angeblich mit ndiswrapper laufen sollte. Pustekuchen: Zwar erkannte ndiswrapper den Adapter, ließ sich aber nicht als Kernelmodul laden. Dann griff ich zu dem existierenden “nativen” Treiber. Das funktionierte, wenn man denn keine Angst davor hat, englischsprachige README-Dateien zu lesen und notfalls auch mal was zu kompilieren, eigentlich recht gut, bloß wollte sich der Adapter nach “ifup” partout nicht mit meinem Netz, sondern nur mit einem anderen WLAN in der Umgebung verbinden (dass ich da, wenn es mir denn schon aufgenötigt wird, mal kurz als Admin rein konnte, ist eine andere Geschichte). Es konnte nicht an meinem Router liegen, denn mein Ubuntu-Laptop nahm immer wieder freudig mit ihm, und nur mit ihm allein, Kontakt auf, und ich tat alles, um das, was da funktionierte, auf den Shuttle zu übertragen.

Also zum Dritten: Jetzt musste die angeblich narrensichere PCI-Lösung ran. Der entsprechende Steckplatz war noch frei, also her mit Netgears WG311. Der sollte mit ndiswrapper aber nun wirklich problemlos laufen. Es fing gut an: Ndiswrapper beschwerte sich nicht, wenn es als Modul geladen wurde. Es tat allerdings auch nichts, sondern überließ dem im Kernel enthaltenen “nativen” Treiber für den TI-ACX-Chipsatz die Hoheit über den Adapter. Aber auch der wollte partout keinen Kontakt zu meinem Router, immerhin auch ein Netgear-Produkt, aufnehmen. Sogar das andere WLAN verschmähte er. Also wurde er mit Gewalt aus dem Speicher herausgekegelt und der ndiswrapper inthronisiert. Selber Effekt. Alles Basteln mit “iwconfig” und an der “/etc/network/interfaces” half nichts - “ifup” fand keinen DHCP-Server.

Da sich “ifup” aber immer mit der Fehlermeldung beschwerte, ein bestimmtes Modul, das IMHO überhaupt nichts mit meiner Konfiguration zu tun hatte, nicht geladen werden könne, schlug ich den Weg zum Meister ein. Ich tippte in Kanos Board unter “Suchen” den Namen des Moduls ein. Das konkrete Problem konnte ich zwar nicht lösen, dafür streute Kano am Ende des betreffenden Threads ein Skript ein, mit dem er ndiswrapper zu aktivieren pflegte. Das kupferte ich einfach ab und - es lief… Ich habe zwar immer noch keinen blassen Schimmer, warum es mit diesem Skript läuft und nicht mit “iwconfig” und “ifup”, aber das gehört zur Demut eben dazu. Oder funktioniert es, weil ich zwischendurch wegen zweier anderer störender WLANs den Kanal gewechselt und nebenbei auch den WEP-Schlüssel von “automatisch” auf “offen” umgestellt habe?

Was bleibt? Ich habe während der zweieinhalb Tage, an denen ich hartnäckig probiert habe, meinen Shuttle WLAN-fähig zu bekommen, wieder viel über Linux und WLANs gelernt. Ein DAU bleibe ich aber weiter.