WLAN mit Ubuntu 12.04 so einfach?! (Update)

Vor einiger Zeit war WLAN unter Linux wirklich ein Drama … Ich hab es seitdem vermieden, wo es nur ging.

Ich hab hier ein altes Netbook mit Atheros Chipsatz, den ich vor ein paar Jahren schonmal zum Laufen bringen wollte. Es ging so halb, aber zuverlässig mit dem Systemstart war der nicht in Gang zu kriegen.

Dieses Netbook wollte ich jetzt als Low-Power Mail-Server verwenden, der mir alle POP3 und IMAP-Konten und RSS-Feeds aggregiert. Der Server soll 24/7 laufen, weshalb er möglichst Stromsparend sein soll.

Meine bisherige Lösung schluckte um die 85W, was viel zu viel ist – das Netbook braucht um die 15W.

Nun stellte sich mir aber wieder das Problem mit dem WLAN. Erstaunlicherweise fand ich diesmal die Lösung ziemlich schnell:

– in die /etc/networking/interfaces folgendes eintragen:

auto wlan0 
iface wlan0 inet dhcp
     wpa-driver wext
     wpa-ssid MYSSID
     wpa-ap-scan 1
     wpa-proto RSN
     wpa-pairwise CCMP
     wpa-group CCMP
     wpa-key-mgmt WPA-PSK
     wpa-psk "MYPASSWORD"

und mit

/etc/init.d/networking restart

neu starten und unglaublich, es hat sofort funktioniert!

Quelle: http://wiki.ubuntuusers.de/interfaces

*Update*: Bei Linux gibt es immer irgendwelche versteckten Fallen – so auch hier.

Ich hab einige Zeit gesucht, wieso mein Netbook langsam ist und rsync über nfs austimed. Irgendwann hatte ich es auf WLAN geschoben und das Gerät direkt per Lan-Kabel an meiner Fritzbox angeschlossen. Das Problem wurde dadurch aber nicht besser.

Irgendwann hatte ich mein NAS in Verdacht, da es mit zwei Interfaces ausgerüstet ist. WLAN0 wird verwendet, wenn der Rest meines Netzwerks ausgeschaltet ist (per Master-Slave-Steckdose an meinem großen PC).

Tatsächlich war hier das Problem zu finden. Mein NAS verwendet auch den ath9k-Treiber, über den es viele Problem-Threads bei google gibt. Man muss eine Option deaktivieren, dann rennt das ganze. Einfach

options ath9k nohwcrypt=1

in die /etc/modprobe.d/ath9k.conf eintragen und die Performanceprobleme sind gelöst.

DD langsam wegen Block-Size

Vor ein paar Jahren schon hab ich festgestellt, dass DD mit eines Default-Block-Size von 512Byte arbeitet.

Dies führt dazu, dass Kopiervorgänge unendlich langsam sind. Egal, ob man kopiert, ein Device mit 0 überschreibt oder ein Image auf SD-Card schreibt.

So sieht es dann aus:

116713+0 Datensätze ein
116713+0 Datensätze aus
59757056 Bytes (60 MB) kopiert, 99,4396 s, 601 kB/s

Und so sieht es aus, wenn man zusätzlich den unscheinbaren Parameter bs=1M anfügt:

390+0 Datensätze ein
390+0 Datensätze aus
408944640 Bytes (409 MB) kopiert, 37,1079 s, 11,0 MB/s

Ich frag mich, wieso das nicht mal by default geändert wird … Ich fall da immer noch drauf rein und das, obwohl ich das schon seit ein paar Jahren weiß!

 

Lokale Mails ins Maildir

Erzeugt ein cron-Job, der über die crontab gestartet wurde, eine Konsolenausgabe, wird standardmäßig eine lokale Mail an den Benutzer verschickt. Diese landet normalerweise in /var/mail/${username}

Bei mir ist es so, dass jeder Benutzer ein Maildir in seinem Homeverzeichnis hat. Möchte man die Mail dorthin bekommen, muss man die /etc/postfix/main.cf mit

home_mailbox = Maildir/

erweitern und Postfix neu starten.

Das war’s 🙂

Screencasts mit AVCONV (FFMPEG)

Nach ziemlich vielen Versuchen hab ich endlich ein kleines Script, mit dem man Screencasts erstellen kann. Wie ich in einem vorherigen Posting schon geschrieben habe, ist ffmpeg deprecated und wurde durch avconv ersetzt, das aber wieder andere Schalter kennt.

Viele Versionen, die ich im Internet gefunden habe, hatten massive Probleme mit der Audio/Video-Synchronisation. Keine Ahnung wieso … Ein simpler Audio-Shift wäre ja nicht das Problem gewesen (obwohl es nervig ist, das Delay später zu bestimmen), aber dass das Audio um einen Faktor von 0,15 schneller ist als das Video geht nunmal wirklich garnicht.

Zuerst dachte ich, meine Frame-Rate für das x264-Live-Capturing wäre zu hoch gewesen und dadurch stimmt die Framerate nicht. Nach ewigen Versuchen stellte ich fest, dass es an der Codec-Kombination x264 und mp3-lame liegt. Mit XVID funktioniert es erstaunlicherweise synchron.

Hier mein kleines Script, das ich dafür verwende:

#!/bin/bash
avconv \
-f x11grab -r 15 -s 1920x1080 -i 0:0  \
-f alsa -i default \
-vcodec mpeg4 -vtag xvid  \
-acodec libmp3lame -ab 128k -threads 4 \
-y $@

Ein anderes Problem war der Alsa-Treiber. Mit Pulse-Audio funktionierte nur -i default, ohne pulseaudio funktionierte -i plughw:0,0. Die Option -i pulse funktionierte bei mir überhaupt nicht, obwohl ich das auch oft ergoogelt hatte.

Ich werde das Script demnächst noch mit einer besseren Bitrate tunen … Die Qualität ist mir mit default-Bitrate zu schlecht …

Gestartet wird die Aufnahme simpel mit ./record.sh recording.avi

Hierbei ist zu beachten, dass die Extension .avi sein muss, da sonst ffmpeg nach dem Start mit einer Fehlermeldung abbricht.

Zum Reencoden, Filtern und Schneiden verwende ich immer avidemux, das wirklich hervorragend funktioniert.