roothausen

Eigentlich bin ich gerade beim Ueberarbeiten meines Artikels ueber die verschluesselte Backup-Festplatte aber da ich fuer weitgehende Automation ein festes Device brauche, schiebe ich hier etwas udev-Kram ein.
Mit udev ist es moeglich bestimmten Geraeten feste Devices zuzuweisen um diese fest ansprechen zu koennen. Bei USB- Festplatten und Sticks entscheidet zum Beispiel die Reihenfolge in der die Geraete eingeteckt wurde welches Device sie bekommen. So koennte die USB-Platte /dev/sda, /dev/sdb etc. sein.
Um einen Vorgang aber komplett zu automatisieren ist es notwendig ein festes Device zu kennen das man ansprechen kann. Soll so zum Beispiel ein Script die Festplatte automatisch mounten um ein Backup auszufuehren, sollte man das Script nicht jedes mal umschreiben muessen wenn sich das Device geaendert hat. Solche Regeln kann man mit udev recht einfach erstellen.
Um eine Regel zu erstellen, werden ein paar Infos zum Geraet gebraucht. Um es eindeutig identifizieren zu koennen wird eine ID gebraucht. Diese erhaellt man mit diesem Befehl:
udevinfo -a -p udevinfo -q path -n /dev/sdb | grep ATTRS{serial} ATTRS{serial}=="1234567898253894C400000123456789"
Wobei /dev/sdb das derzeitige Device der Festplatte ist. Die Seriennummer wurde absichtlich verfaelscht.
Weitere Infos, die man nutzen kann waeren zum Beispiel die Produktbezeichnung:
udevinfo -a -p udevinfo -q path -n /dev/sdb | grep ATTRS{product} ATTRS{product}=="USB TO IDE" ATTRS{product}=="EHCI Host Controller"
Ich nutze hier nur die Serial. Damit lassen sich nun lustige Regeln erstellen.
Da ich das urspruengliche Device behalten will und nur einen Link darauf moechte, habe ich die Datei /etc/udev/rules.d/00.rules mit folgendem Inhalt erstellt:
# pfleidis own Rules BUS=="usb", ATTRS{serial}=="1234567898253894C400000123456789", KERNEL=="sd?1", NAME="%k", SYMLINK+="ext/usbhdd", GROUP="storage"
Hiermit sollte beim Einstecken ein Symlink /dev/ext/usbhdd erstellt werden, der auf das urspruengliche Device zeigt. Nun wird die Platte ausgesteckt und wieder eingesteckt und siehe da:
ls -la /dev/ext/usbhdd lrwxrwxrwx 1 root root 7 2007-05-30 20:53 /dev/ext/usbhdd -> ../sdb1
Nun kann man die USB-Festplatte dauerhaft mit /dev/ext/usbhdd ansprechen, ohne dass man das eigentliche Device kennen muss. Das macht auch die Automation fuer Backups etc. sehr viel einfacher, da man hier in Scripten mit einem festen Device arbeiten kann. Das selbe gillt nun natuerlich auch fuer die /etc/fstab. Spaeter werde ich dann noch Regeln erstellen um die Platte automatisch per Keyfile zu entschluesseln und einzuhaengen. Somit kann man diesen Vorgang komplett automatisieren.
Erklaerungen zu den Befehlen oder weiterfuehrende Optionen koennt ihr aus den folgenden Links und den Manpages entnehmen. Da ist das ganze etwas genauer erklaert.
Weiterfuehrende Links: http://de.gentoo-wiki.com/UdevRules http://wiki.archlinux.org/index.php/Udev http://www.linuxforen.de/forums/showthread.php?t=178406 http://wiki.archlinux.org/index.php/Usingudevtomapmultipleentriestoa_device

Mein Thinkpad besitzt einen Intel Wlan Chip. Genauer gesagt einen IPW3945. Hierbei hatte ich in letzter Zeit haeufig in Verbindung mit WPA das Problem, dass die Verbindung teilweise einfach abgebrochen ist und ich musste das Interface runter und dann wieder hoch fahren. Das nervt, auch wenn es selten passiert.
Nach durchsehen der Logfiles und mit Hilfe des Befehls "dmesg" habe ich folgende Eintraege gefunden:
/var/log/kernel.log.2:May 16 12:16:53 burgr TKIP: ICV error detected: STA=XX:XX:XX:XX:XX:XX /var/log/kernel.log.2:May 16 12:28:14 burgr TKIP: ICV error detected: STA=XX:XX:XX:XX:XX:XX
Nach einer kurzen Suche habe ich ein paar Sachen gefunden. Soweit ich gelesen habe, handelt es sich um ein Problem, dass nur bei Multiprozessorsystemen (SMP), wie zum Beispiel bei meinem Core2Duo, auftritt.
Bisherige Loesung des Problems: Den alten ieee80211-Stack entfernen und die aktuelle Version installieren.

A generic ieee80211 networking stack for the Linux kernel. To use, simply download one of the tarballs from the downloads section, untar it, and follow the installation instructions (for example): % tar xzvf ieee80211-VERSION.tgz % less ieee80211-VERSION/INSTALL

Einfach den Anweisungen im INSTALL-Dokument folgen, die alten Module entfernen und den WLAN-Stack neu bauen. Dann klappts auch mit WPA. Bis jetzt zumindest
Was ich allerdings nicht nachvollziehen kann, ist wieso das Problem immer noch auftaucht, obwohl der Fehler seit August 2006 im ieee80211-Stack bereinigt ist. Komische Sache das.

Update: Mittlerweile tauchen wieder solche Eintraege in den Logs auf, aber die Verbindung bricht nicht ab. Vielleicht handelt es sich auch um Fehler, die durch den sehr schlechten Empfang, den ich momentan in der Wohnung habe, verursacht werden. Ein Stockwerk tiefer tritt so etwas naemlich nicht auf.
Was mir allerdings Sorgen macht ist folgendes:
Tx excessive retries:0 Invalid misc:24406 Missed beacon:0