Als Kommandozeilentool braucht speedtest-cli keine graphische Umgebung, das Skript lässt sich auch auf einfachen Systemen wie eben dem Raspberry Pi mit etwa Raspbian ausführen. speedtest-cli muss auch nicht zwingend installiert werden, das Skript kann man direkt von Github laden und ausführen. Arch-Linux-User finden speedtest-cli jedoch auch im AUR, so dass sich das Skript ohne weiteren Umstand auf den Rechner laden lässt

$ wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
$ chmod +x speedtest-cli
$ ./speedtest-cli

Wer speedtest-cli öfters braucht, der schiebt das Skript nach ~/bin oder mit Root-Rechten nach /usr/local/bin, so dass es im $PATH steht und von jedem Verzeichnis aus aufrufbar ist — bei der Installation unter Arch landet das Skript sowieso ordentlich im Dateisystem, so dass man sich darum keine Gedanken machen muss.

speedtest-cli kennt neben dem einfachen Aufruf ohne Optionen auch noch eine Reihe von Schaltern. So lässt sich mit etwa mit speedtest-cli --share der Pfad zur Imagedatei mit den Ergebnissen des Leitungstests ausgeben. Oder man ruft mit  speedtest-cli --list die Liste der Speedtest-Server ab, so dass man mit  speedtest-cli --server SERVER einen Testserver gezielt anwählen kann.

$ speedtest-cli --help
usage: speedtest-cli [-h] [--share] [--simple] [--list] [--server SERVER]

Command line interface for testing internet bandwidth using speedtest.net.
--------------------------------------------------------------------------
https://github.com/sivel/speedtest-cli

optional arguments:
-h, --help show this help message and exit
--share Generate and provide a URL to the speedtest.net share
results image
--simple Suppress verbose output, only show basic information
--list Display a list of speedtest.net servers sorted by distance
--server SERVER Specify a server ID to test against

Insgesamt funktioniert speedtest-cli ähnlich gut wie Speedtest.net, allerdings beobachten einige User doch recht schwankende Ergebnisse des Kommandozeilentools. Auch bei mir spuckte speedtest-cli öfters mal Werte aus, die eigentlich nicht sein konnten. Kommen einem die Werte komisch vor, dann sollte man also lieber noch einmal den Test wiederholen, nicht dass man umsonst die Verkabelung nochmal neu macht,

Dazu braucht es kein zusätzliches Add-On und auch keine besondere Einstellung des Browsers. Es reicht, wenn man als „URL“ die Net-Internals des Browsers aufruft und sich die Bandwith-Infos anzeigen lässt. Das funktioniert auf allen Systemen, auf denen man Chrome installieren kann, also natürlich auch Android und Linux.

chrome://net-internals/#bandwidth

Das Interessante ist hierbei nun, dass die Statistiken seit Installation des Browsers bzw. seit Anlegen des Profils geführt werden. Man kann also sehr einfach mitverfolgen, welche Datenmengen man über die Jahre hinweg per Browser ins Netz geblasen hat.

Stellt sich mir nur noch die Frage? Seit wann wird diese Statistik eigentlich geführt? Dies ist leider nicht ganz so einfach herauszufinden, da sich die Konfigurationsordner ~/.config/google-chrome bzw. ~/.config/chromium permanent ändern. So liefert der stat-Befehl nicht wirklich mehr Informationen, als dass sich heute etwas in den Ordnern getan hat.

$ stat ~/.config/google-chrome
  Datei: „/home/toff/.config/google-chrome“
  Größe: 4096      	Blöcke: 8          EA Block: 4096   Verzeichnis
Gerät: 806h/2054d	Inode: 4980809     Verknüpfungen: 8
Zugriff: (0755/drwxr-xr-x)  Uid: ( 1000/    toff)   Gid: ( 1000/    toff)
Zugriff    : 2014-02-11 11:03:01.299531577 +0100
Modifiziert: 2014-02-11 14:53:52.661487565 +0100
Geändert   : 2014-02-11 14:53:52.661487565 +0100

In meinem Fall deckt sich die Installation mit Chrome mit der Installation des Systems. Von daher lässt sich das Alter „meiner“ Chrome-Installation recht leicht bestimmen, zum Glück gibt es dafür recht simple Lösungen: Entweder man schaut sich ein Verzeichnis wie etwa /lost+found an, das seit Anfang an praktisch unverändert auf der Platte liegt. Oder man lässt sich ausgeben, wann das letzte mal das Passwort eines System-Users wie „sys“, „bin“, oder „root“ geändert wurde. Dies sollte ebenso mit dem Installationsdatum übereinstimmen.

$ stat /lost+found
  Datei: „/lost+found“
  Größe: 16384     	Blöcke: 32         EA Block: 4096   Verzeichnis
Gerät: 801h/2049d	Inode: 11          Verknüpfungen: 2
Zugriff: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Zugriff    : 2012-10-16 08:51:44.000000000 +0200
Modifiziert: 2012-10-16 08:51:44.000000000 +0200
Geändert   : 2012-10-16 08:51:44.000000000 +0200
 Geburt    : -
$ sudo passwd -S sys
sys L 10/15/2012 0 99999 7 -1

In knapp 16 Monaten habe ich also 92 GByte versurft, ohne dass ich auf dem Rechner viel Videos schaue — Der Traffic von Plugins wird sowieso nicht zu dieser Statistik hinzugerechnet. Ich denke, ich surfe zu viel durchs Netz

Ausgangsbasis für diesen „Hack“ ist die Sonos-Android-App, sie bietet im Gegensatz zur iOS-Variante die Möglichkeit die Zugangsdaten zum WLAN in mit der App bestückten Androiden zu übertragen. Sonos begründet dieses „Android-Only-Feature“ mit der Offenheit von Android: „If Apple decides to open up iOS, we’d love to allow Apple devices to use SonosNet.“ Schön zu hören dann offene Standard zu besseren Features führen, wissen wir eigentlich alle schon lange, durch nur viele Unternehmen meinen immer noch auf ihrer einsamen Insel am sichersten zu leben…

Zurück zum SonosNet, unter Android ist die Einrichtung sehr einfach. Öffnet einfach die Sonos-App, geht in die Einstellungen und öffnet dort die Erweiterten Einstellungen. Dort klickt ihr auf Mit SonosNet verbinden und klickt noch einmal auf den Button Verbindung zulassen. Sonos überträgt daraufhin automatisch die WLAN-Zugangsdaten zum SonosNet in die Netzwerkeinstellungen des Android-Systems, so dass ihr das WLAN der Sonos-Boxen umgehen nutzen könnt.

Anderen Geräten wie eurem Notebook oder einem iPhone/iPad bleibt nun allerdings der Weg ins SonosNet versperrt. Der Name des Netzwerks, dessen SSID nicht in die Welt herausgefunkt wird, ist zwar schnell aus den Netzwerkeinstellungen ausgelesen, aber es fehlt die WPA2-Passphrase, die sich nur mit extremen Aufwand knacken lässt.

SonosNet Passwort auslesen

Hier kommt nun euer gerootetes Android-Handy oder -Tablet ins Spiel. Die gesammelten WLAN-Zugangsdaten sind für Root kein großes Geheimnis. Sie stehen unverschlüsselt in der Datei /data/misc/wifi/wpa_supplicant.conf, normale Android-Apps kommen da nicht ran, Root-Applikationen können die Konfigurationsdatei allerdings problemlos öffnen.

Ich für meinen Teil benutze dafür gerne Solid Explorer, es tut aber auch jeder andere Dateimanager aus dem Android Play Store, der mit Root-Rechten umgehen kann. Navigiert mit ihm ins Stammverzeichnis und öffnet dort dann den Pfad /data/misc/wifi im Dateimanager. Sucht hier schließlich die Datei wpa_supplicant.conf heraus und öffnet sie mit einem langen Fingerzeig in den SE Texteditor. Hier findet ihr jetzt die Zugangsdaten zum SonosNet im Klartext.

Mit den Daten bekommt ihr nun jedes andere Gerät ins SonosNet, es muss allerdings die Option unterstützen ein „verstecktes“ WLAN aufzufinden, was heutzutage eigentlich aber kein Problem sein sollte. Ich habe hier mittlerweile mein Notebook im SonosNet, da mein WLAN-Router am anderen Ende der Wohnung steht, ist über das SonosNet der Datendurchsatz deutlich besser. Störungen bei der Musikwiedergabe der Sonos-Boxen konnte ich trotz ordnetlich Last durch mein Notebook bislang noch nicht feststellen.

//UPDATE: Caschy hat den Beitrag aufgegriffen und bei ihm hat ein Kommentator gefragt, warum man denn nicht einfach InstaWifi zum Auslesen der Zugangsdaten nimmt. Guter Punkt, warum nicht! Ich hatte schon früher mal InstaWifi probiert und mich damals geärgert, dass ich das Passwort zwar sehen konnte, aber nicht per Copy&Paste übernehmen. Das störte bei einem kurzen WLAN-Passwort nicht, beim ellenlangen SonosNet-Schlüssel war mir das Ablesen dann aber doch zu nervig. Wie dem auch sei, mit aktuellen Versionen der InstaWifi-App klappt auch das Kopieren des Schlüssels. Wenn ihr euch den Weg über den Dateimanager ersparen möchtet, dann bietet sie den einfacheren Weg.

Zu Beginn erstmal eine kurze Einführung in die Geräte. Das Siemens WB-011 (Bei mir steht W-011 auf dem Aufkleber) ist ein WLAN-Access Point, der von Alice ausgeliefert wurde, wenn man so um das Jahr 2007 nachträglich eine „WLAN-Option“ zum Anschluss geordert hat. Dieses kleine schwarze Kästchen von Siemens ist baugleich mit dem DWL-2100AP von D-Link (Bei Amazon aktuell rund 57 Euro), mit dem man entweder ein bestehendes LAN um einen WLAN-Zugang erweitern kann, einen bestehenden WLAN-Zugang in seiner Reichweite erweitern (Repeater), oder auch ein kabelgebundenens Netzwerk-Gerät in ein WLAN einklinken kann.

Allerdings hat Alice die Firmware verkrüppeln lassen und bislang auch keinerlei Updates veröffentlicht, so dass die graphische Oberfläche des WB-011 eine Katastrophe ist und es Probleme im Verbindungsaufbau mit WPA2 verschlüsselten WLANs gibt. Man kann allerdings auf das WB-011 die Firmware vom DWL-2100AP einspielen, und hat somit für weniger als 10 Euro (Siehe Ebay, die günstigsten Kaufpreise schwanken zwischen zwei und fünf Euro) ein zum DWL-2100AP identisches Gerät.

Vorbereitung

Um die Firmware des Siemens W-011 zu flashen braucht es einen Windows-PC mit Netzwerkkarte, da es das benötigte Programm nur für Windows gibt. Ob es mit Wine läuft habe ich nicht getestet. Als ersten Schritt würde ich empfehlen die Siemens-Box über den kleinen Button auf der Rückseite zu Resetten. Man muss den Knopf dafür ca. 10 Sekunden gedrückt lassen, dadurch wird das Gerät wieder auf die Werkseinstellungen zurückgesetzt. Nun solltet Ihr euren Rechner mit der W-011 verbinden und eure Netzwerkkarte auf bspw…

• IP: 192.168.1.2
• Subnet-Mask: 255.255.255.0
• Gateway: 192.168.1.1

…einstellen. Wer nicht weiß wie das geht, der findet im Handbuch Hilfen für XP und Co. (natürlich nix aktuelleres…). Danach solltet Ihr über euren Browser und die URL http://192.168.1.100 auf die Weboberfläche der Siemens-Box zugreifen können. Die Zugangsdaten zum Frontend lauten Login: admin und Passwort: admin.

Ihr müsst/braucht hier erstmal nichts nichts weiter einstellen. Weiter geht es mit einem speziellen Flash-Programm, da sich die D-Link Firmware nicht über das Webfrontend einspielen lässt.

Flashen

Im nächsten Schritt geht es jetzt ans Eingemachte. Der Dank für diese Informationen geht an das Blog stuff that matters und den Kommentator Chuck. Dort finden sich eigentlich alle Infos, wenn auch nicht so ausführlich geschildert.

Holt euch das Flash-Programm FTP Programmer aus dem Netz. Die Vertrauenswürdigkeit dieser Anwendung kann ich schlecht beurteilen, sie stammt von einem russischen Server, ist teils auf russisch und stammt von einem unbekannten Programmierer… Ich hab sie jedenfalls nur auf einem Testsystem installiert.

Neben dem Flash-Programm braucht Ihr noch die D-Link Firmware. Ich habe erst ein Upgrade auf die amerikanische Version 2.13 gemacht und erst danach gesehen, dass es auch eine deutschsprachige Version mit der Nummer 2.50 gibt. Mein Upgrade lief daher in zwei Schritten ab, ich vermute dass man auch direkt auf die 2.50er Firmware gehen können müsste. Die Downloads findet Ihr direkt bei D-Link unter ftp.dlink.com bzw. ftp.d-link.de.

Entpackt das Archiv mit der von euch gewünschten Firmware, installiert den FTP Programmer und startet die Anwendung. Gebt als IP-Adresse die IP ein, die Ihr auch im Browser verwendet, um auf das Web-Frontend der Box zu kommen. Die Zugangsdaten sind ebenfalls die selben wie für das Frontend. Die Option „Discover Device“ hat bei mir nicht funktioniert, was das Flashen aber nicht beeinträchtigt hat.

Über „Write“ ruft Ihr abschließend die Routine zum Flashen auf. Ihr werdet daraufhin nach dem Image gefragt, wählt aus dem entpackten Archiv die tfp-Datei aus und wartet jetzt rund eine Minute. Im Log solltet Ihr sehen was gerade auf der Box passiert.

Am Ende sollte das Flash-Tool einen Neustart eures „jetzt“ D-Link DWL-2100AP im Siemens-Kleid ausführen. Ich würde euch jetzt noch empfehlen abermals die Box auf die Werkseinstellungen zurückzusetzen, den ich konnte mich nach dem Flashen nicht mehr auf der Box einloggen. Das Frontend erschien zwar noch unter der selben IP, doch die Zugangsdaten waren angeblich falsch. Drückt also wieder für ~10 Sekundenauf den Reset-Button auf der Rückseite der Box.

Konfigurieren

D-Link verwendet andere Standardeinstellungen wie Siemens. Daher müsst ihr nach dem Reset eure Netzwerkeinstellungen erneut anpassen. Wählt diesmal zum Beispiel…

• IP: 192.168.0.10
• Subnet-Mask: 255.255.255.0
• Gateway: 192.168.0.1

Auch die Zugangsdaten und die Standard-IP ändern sich mit dem neuen Image. Eure Box solltet Ihr jetzt unter der URL http://192.168.0.50 finden, des weiteren lautet zar der Benutzern nach wie vor „admin“, doch das Passwort könnt Ihr leer lassen, es gibt kein PW.

Nun könnt Ihr das Gerät als „Wireless-Client“ konfigurieren und so ein Gerät mit „normalem“ Netzwerkanschluss ins WLAN bringen. Sucht einfach nach den drahtlosen Netzwerken in eurer Umgebung und übernehmt SSID und MAC-Adresse des Zugangspunktes über einen Klick auf den Radio-Button auf der linken Seite. Natürlich wollen auch noch die Zugangsdaten zum WLAN eingetragen werden.

Geht dann Abschließend noch in die Einstellungen zum LAN-Zugang und tragt dort eine IP der Siemens/D-Link Box aus eurem Netzwerk ein. Nach einem letzten Neustart der Box, solltet Ihr über Sie drahtlos in euer lokales Netzwerk kommen.

Dass die Kanäle nun auch in Europa nicht funktionieren, ist nicht Absicht der Kernelentwickler, sondern wohl eine Konsequenz aus dem globalen Handel. Es scheint so, dass viele Hersteller WLAN-Chipsätze, die eigentlich für den Markt in den USA bestimmt waren, auch für Notebooks verwenden die in Europa verkauft werden. Betroffen sind auf jeden Fall Notebooks mit dem Intel PRO/Wireless 3945ABG Chipsatz. Ich hatte hier beispielsweise ein Dell XPC Notebook vor mir, dass auf einmal mein WLAN nicht mehr fand…

Um nun mit diesem Notebook in mein WLAN zu kommen musste ich wohl oder übel den Kanal des WLANs wechseln. Da hier im Haus rund 15 WLANs wild durch die Gegend funken, geht es darum einen freien Kanal zu finden. Es gilt: Je leerer der Kanal und desto höher der Abstand zu anderen genutzten Kanälen, desto höher ist die mögliche Bandbreite. Bislang habe ich das immer mit dem WLAN-Sniffer Kismet gemacht. Aber warum kompliziert, wenn es auch einfach geht?

Als Router benutze ich einen Linksys WRT54GL mit Tomato als Firmware. Bislang hatte ich der Firmware wenig Beachtung geschenkt, aber beim Umschalten des Kanals, bin ich dann auf eine Funktion gestolpert, die wirklich praktisch ist. Unter Basic -> Network findet man neben der Dropdownbox zur Auswahl des Kanals den Button Scan.

Und siehe da, nach rund 30 Sekunden, sieht man eine wunderbare Übersicht der freien Kanäle und kann so – sehr einfach – den optimalen Kanal auswählen. Kleiner Tipp am Rande: Tomato ist wirklich genial wenn man eine einfache und leistungsfähige Firmware für seinen Linksys WRT54GL sucht. DD-WRT etc. sind sicherlich einen Tick umfangreicher, aber Tomato überzeugt mit einfacher Bedienung und cleveren Funktionen.

Update: Laut diesem Beitrag kann man den das Kernelmodul dazu zwingen sich „europäisch“ zu verhalten. Also die Kanäle 12 und 13 zu erlauben. Dazu muss man die Dateo /etc/modprobe.d/iwl4965 erstellen und die Optionen dazu eintragen. Am einfachsten geht dies mittels des folgenden Kommandos und danach das Kernelmodul einmal entfernen und wieder neu laden. Dann soll es auch wieder mit dem Nachbarn klappen Danke jug!

$ echo options cfg80211 ieee80211_regdom=\"EU\" | sudo tee -a /etc/modprobe.d/iwl4965
$ rmmod iwl4965
$ modprobe iwl4965

[UPDATE: Dieser Artikel ist veraltet! Sollten Sie über eine Internetsuche auf diesen Artikel gestoßen sein, so schauen Sie sich bitte besser den Artikel VPN der Uni-Karlsruhe mit vpnc (überarbeitet)… an. Dieser enthält die selben Informationen, ist jedoch auf einem aktuellen Stand! [/UPDATE]

#!/bin/bash

## 02uni-ka-vpnc 1.1 by Christoph Langner
## 2008 by Christoph Langner, published under the GPL v3
##
## Changelog
## 1.1: Ermöglicht nun auch den automatischen Aufbau des VPN über WLAN
##      Sollte man eine andere ESSID als "VPN/WEB" nutzen, so passt man dazu
##      die Variable $ESSID_VPN an.
## 1.0: Erstes Release. VPN Zugang nur via Kabel.

## INITIALISIERUNG
#Diese Werte werden vom NetworkManager an das Skript übergeben
INTERFACE=$1
ACTION=$2

## DEBUGGING
# Falls DBG_MODE=1 werden verschiedene Angaben nach $LOG ausgegeben
DBG_MODE=0
LOG=/tmp/dispatcher.log

## ESSID des Universitäts Netzwerkes
# In diesem Fall das VPN WLAN der Universität Karlsruhe
ESSID_VPN="VPN/WEB"

## NETWORKING
#IP des Rechners herausfinden
IP=$(ifconfig $INTERFACE | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://')
IP_START=$(echo $IP | awk -F. '{print $1}')

#ESSID des verbundenen Netzwerks bestimmen
ESSID=$(iwconfig $INTERFACE | grep ESSID | awk {'print $4'} | sed -e 's/ESSID://g' | sed -e 's/"//g')


## DEBUG Funktionen
log() {
if [ $DBG_MODE=1 ]; then
	echo IP: $IP >> $LOG
	echo IP_START: $IP_START >> $LOG
	echo ESSID: $ESSID >> $LOG
fi
}

log_action() {
if [ $DBG_MODE=1 ]; then
	echo ========= >> $LOG
	echo $(date) >> $LOG
	echo ACTION: $ACTION, Device: $INTERFACE >> $LOG
fi
}

#Funktionen durchführen, je nach Aktion eine andere
case "$2" in
    up)
        #vpnc starten, falls im Uni Netzwerk
        log_action
        log
        if [ $IP_START=129 ]; then
                vpnc
        elif [ $ESSID=$ESSID_VPN ]; then
        	sleep 15
         	vpnc
        fi
        ;;

    down)
        #vpnc stoppen
        log_action
        if [ "$(pidof vpnc)" ]; then
                vpnc-disconnect
        fi
        ;;

    pre-up)
        #einen vorher laufenden vpnc stoppen
        log_action
        if [ "$(pidof vpnc)" ]; then
                vpnc-disconnect
                killall vpnc
        fi
        ;;

    post-down)
        #vpnc wirklich stoppen, falls abgestürzt
        log_action
        if [ "$(pidof vpnc)" ]; then
                vpnc-disconnect
                killall -9 vpnc
        fi
        ;;

     *)
        echo $"Usage: $0 {up|down|pre-up|post-down}"
        exit 1
esac

Das Skript habe ich auch zum Download hochgeladen. Via…

$ sudo wget -P  /etc/NetworkManager/dispatcher.d/ http://www.linuxundich.de/static/2uni-ka-vpnc
$ sudo chmod +x /etc/NetworkManager/dispatcher.d/02uni-ka-vpnc

…kann man es herunterladen und ausführbar machen. Spätestens bei einem Neustart wird nun das Dispatcher Skript ausgeführt. Achtung: vpnc muss neu compiliert werden. Das bei Ubuntu aus den Paketquellen installierte vpnc kann sich nicht zu Cisco VPN Router mit hybrider Verschlüsselung verbinden. Daher bitte diesen Artikel VPN der Universität Karlsruhe über vpnc beachten.

Leider war das bei meinen ersten Test mit Ubuntu nicht der Fall. Die Karte lief zwar mit dem mitgelieferten rt2500-Kernel-Modul, doch es funktionierte bei mir keinerlei Verschlüsselung. Sobald ich auch nur WEP aktivierte, konnte ich mich nicht mehr zum Access Point verbinden. Von WPA musste ich erst gar nicht träumen. Aber man ist ja nicht blöd, Treiber werden weiterentwickelt und so auch das Modul für den Chipsatz dieser Karte. Aus dem CVS des rt2400 Projektes bei Sourceforge holt man sich erstmal den Quellcode.

$ cd ~
$ mkdir RT2500
$ cd RT2500
$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rt2400 login
$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/rt2400 co source

Als Passwort einfach einmal Return eingeben. Man brauch kein Passwort, um einfach nur den Quellcode herunterzuladen. Danach muss das Modul compiliert werden.

$ cd ~/RT2500/source/rt2500/Module
$ make

Lief der Vorgang ohne Fehler durch, so muss das Modul installiert werden. Ich mache lieber vorher noch eine Sicherheitskopie des alten Moduls

$ sudo cp /lib/modules/2.6.12-10-k7/kernel/drivers/net/wireless/rt2500/rt2500.ko /lib/modules/2.6.12-10-k7/kernel/drivers/net/wireless/rt2500/rt2500.ko.bak
$ sudo make install
$ sudo depmod -a

Um einen Neustart des Rechners zu vermeiden, sollte man das Kernelmodul mit $ sudo modprobe rt2500 von Hand laden. Abschließend kann man nun in den Gnome Netzwerk Manager wechseln und die Daten zur Netzwerkverbindung eintragen.

Vorbereitung

Um die Treiber kompilieren zu können müssen folgende Pakete installiert sein:

• build-essential
• linux-headers (passend zur Version des Kernels)
• wireless-tools
• pcmcia-source

Außerdem muss man natürlich die aktuellen Treiberquellen herunterladen. Diese findet man auf folgenden Webseiten. Zum Treiber wird auch ein Patch benötigt, falls man einen Kernel neuer als 2.6.5 verwendet.

http://www.xs4all.nl/~bvermeul/swallow/
http://www.its.caltech.edu/~maher/geek.html

Zum Download am Einfachsten einfach ein Terminal öffnen und die Dateien per wget herunterladen (hierbei eventuell noch die genaue Versionsnummer anpassen!)

$ wget http://www.xs4all.nl/~bvermeul/swallow/poldhu-0.3.1.tar.gz
$ wget http://www.its.caltech.edu/~maher/diff-poldhu-0.3.1

Durchführung

Das Archiv mit…

$ tar -xzf poldhu-0.3.1.tar.gz

…entpacken. Danach in das neue Verzeichnis poldhu wechseln und dort eventuell das Kernel Modul patchen.

$ cd poldhu
$ patch -p1 < ../diff-poldhu-0.3.1

Nun kann man den Treiber compilieren. Warnungen, die eventuell auftreten, können ignoriert werden, falls der Treiber fertig compiliert wird.

$ make

Jetzt muss der Treiber an die richtige Stelle kopiert werden. Das Makefile kopiert mit make install den Treiber an die falsche Stelle, also macht man das am besten von Hand

$ sudo cp clients/poldhu_cs.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/

Außerdem fehlt noch die config Datei.

$ sudo cp config/poldhu.conf /etc/pcmcia/

Jetzt muss die Liste der Kernel Module neu aufgebaut werden.

$ sudo depmod -a

Und abschließend nur noch den Treiber einbinden (beim ersten Mal von Hand), danach sollte das Hotplug automatisch übernehmen.

$ sudo modprobe poldhu-cs

Damit der Treiber auch korrekt vom pcmcia Dienst geladen werden kann, solltet man danach diesen Dienst einmal von Hand neu starten.

$ sudo /etc/init.d/pcmcia restart

Beim nächsten Systemstart sollten die Module jetzt automatisch geladen werden.

Konfiguration

Die Karte wird wie jede andere WLAN Netzwerkkarte konfiguriert. Der schnellste Weg führt über die Gnome Netzwerk Verwaltung unter System | Systemverwaltung | Netzwerk.

Fehlersuche

Bei mir stürzte der Rechner beim Einschieben der Karte komplett ab. Dies hat wohl etwas mit IRQ Konflikten zu tun. Der Konflikt lies sich jedoch recht leicht vermeiden, wenn man den Kernel mit der Option noapic nolapic pci=noacpi bootet.

Dauerhaft hinzufügen kann man die Option, wenn man die Datei menu.lst von grub editiert:

$ gksudo gedit /boot/grub/menu.lst

Und im Abschnitt nonaltoption die Option pci=noacpi hinzufügt.

## nonaltoption boot targets option
## This option controls options to pass to only the
## primary kernel menu item.
## You can have ONLY one nonaltoptions line
# nonaltoptions=quiet splash noapic nolapic pci=noacpi

Und schließlich noch grub aktualisieren.

$ sudo update-grub

So viel Spaß mit dem Internet!