XMMS2 + ALSA: CPU-Load reduzieren

Ich hatte mich ja gestern beschwert, dass der CPU-Load von XMMS2 zu hoch sei (30%-50%). Hab heute die Lösung (im Internet) gefunden:

XMMS2 stoppen (nicht als root, sondern als ausführender Benutzer)
nickolsen@ocelot:~$ xmms2 stop
Das Output-Plugin auf „null“ umbiegen
nickolsen@ocelot:~$ xmms2 config output.plugin null
Config value output.plugin set to null
XMMS2 wieder starten. Bei mir war der CPU-Load nun auf 0%-5%.
nickolsen@ocelot:~$ xmms2 stop
Output-Plugin wieder auf „alsa“ einstellen
nickolsen@ocelot:~$ xmms2 config output.plugin alsa
Config value output.plugin set to alsa
Dafür als Alsa-Device nicht „default“ sondern hw:0,0 benutzen
nickolsen@ocelot:~$ xmms2 config alsa.device hw:0,0
Config value alsa.device set to hw:0,0
Et voila, CPU-Load schwirrt unter 10% rum. Damit kann ich leben!

Neuer Windowmanager: Enlightenment

Ich hatte testweise auf einer virtuellen Maschine (qemu) mal e16 aus dem Debian Repository installiert (ja, ich weiß, obsolet) und das Ding schnell ins Herz geschlossen.
Heute war dann der große Tag: Windows wurde komplett von meiner Festplatte verbannt!
Diesen Schritt habe ich direkt mal zum Anlass genommen und hab Debian auch direkt neu installiert. Diesmal allerdings mit der Kombination e16 und slim statt wie bisher KDE3.5 und kdm.

Booten tut das Notebook nun etwa 10 Sekunden schneller und auch der Speicherverbrauch ist etwas humaner als unter KDE. Dafür ist das ganze sehr karg und etwas gewöhnungsbedürftig. Und mich nervt, dass xmms meine CPU zu 10% belegt…

Bisher nutze folgende Komponenten:
- X.org X-Server
- e16
- slim
- eterm
- xfe
- powersaved
- Openoffice
- gkrellm2
- xmms2 (inkl. xmms2-scrobbler)
- iceweasel
- alsa
- vim
- xpdf
- openssh-server/-client

Screenshots gibt es bei Zeiten und ich geh nun schlafen

EDIT: Achja, ich hab mir heute in wenigen Minuten einen eigenen Desktophintergrund gebaut.

dpkg: Konfigs gelöschter Pakete purgen

Ich weiß nicht, ob das wirklich Sinn macht… aber, hier ist meine Funktion:

for i in $(dpkg -l | grep ^rc | tr -s "[:blank:]" | cut -d " " -f2); do dpkg -P $i; done
oder
for i in $(dpkg -l | grep ^rc | awk -F ' ' '{print $2}'); do dpkg -P $i; done

Damit werden alle mit rc gekennzeichneten Pakete aus dpkg gepurgt.
rc bedeutet, dass die Pakete gelöscht sind, aber noch eine Konfigurationsdatei vorhanden ist. Bei einer erneuten Installation des Pakets, würde diese Konfig auch verwendet werden. Um das zu verhindern, kann man die Konfigurationsdatei (also den Paketrest) purgen – vollständig entfernen. Normalerweise geschieht dies per dpkg -P <Paketname>.

Achtung: Bei meiner kleinen Schleife, findet KEINE Sicherheitsabfrage statt. Es werden einfach alle rc-geflagten Pakete gepurgt! Benutzung auf eigene Gefahr!!!

Eee schaltet sich nicht ab

Habe mir zu Weihnachten einen gebrauchten Asus Eee 701 [1] gegönnt. Da ich Debian-Fan bin, habe ich das vorinstallierte Xandros [2] direkt mal geplättet und Debian Testing [3] installiert. Dabei fiel mir auf, dass der Eee nach dem Runterfahren nicht ganz aus geht. Das Problem ließ sich bis heute nur durch das Entfernen des Akkus „lösen“.
Heute habe ich allerdings mal ein wenig beim DebianEeePC-Projekt [4] gestöbert und siehe da, es gibt eine (funktionierende) Lösung [5]:

su root
echo rmmod snd_hda_intel >> /etc/default/halt

Des Weiteren funktioniert das Herunterfahren bei niedrigem Akkustand durch kpowersave nicht. Nach einem solchen „Stromausfall“ (bedingt durch den leeren Akku), hat sich direkt die Tastatur verabschiedet… zum Glück gibts bei eBay [6] Neue…

---

[1]: http://www.asus.com/products.aspx…
[2]: http://www.xandros.com/
[3]: http://www.debian.org
[4]: http://wiki.debian.org/DebianEeePC
[5]: http://wiki.debian.org/DebianEeePC/…
[6]: http://www.ebay.de

Praktische nmap-Commands

nmap -sP -n <IP>
Bsp: ocelot:/# nmap -sP -n 192.168.0.15-28
Host 192.168.0.23 appears to be up.
MAC Address: 00:06:XX:XX:XX:XX (Cisco Systems)

Nmap scannt die IPs 192.168.0.15 bis 192.168.0.28 und überprüft ob die Hosts up sind.
-sP: Ping-Scan. Nutzt _ausschließlich_ ein ICMP echo request an Port 80 des Zielrechners (wenn root ausführt, wird noch ein ARP-Request benutzt)
-n: Keine Namensauflösung.

---

nmap -sT -p <Port> -n <IP>
Bsp: ocelot:/# nmap -sT -p 22 -n 192.168.0.1-100 | grep open -B2
Interesting ports on 192.168.0.23:
PORT   STATE SERVICE
22/tcp open  ssh

Im angegebenen IP-Bereich werden alle IPs auf den angegebenen Port gescannt und es wird ausgegeben, welchen Status dieser Port hat. Das grep bewirkt in diesem Fall, dass nur die offenen Ports mit den 2 darüberliegenden Zeilen ausgegeben werden. Erklärungen dazu weiter unten.
-sT: TCP connect scan
-p: Gibt den zu scannenden Port (s/range) an.
-n: Wie oben schon erwähnt bedeutet diese Option, das keine Namensauflösung durchgeführt wird.

---

grep <Expression> -A|B<Zahl>
Bsp: ocelot:/# grep 5 -B2 testfile.txt
Zeile 3
Zeile 4
Zeile 5

Bsp: ocelot:/# grep 5 -A2 testfile.txt
Zeile 5
Zeile 6
Zeile 7

-B: Gibt an, das die angegebene Anzahl Zeilen vor der <Expression>-Zeile mit ausgegeben werden sollen. (B = before)
-A: Gibt an, das die angegebene Anzahl Zeilen nach der <Expression>-Zeile mit ausgegeben werden sollen. (A = after)

Lautes Cisco Catalyst 2924-Switch

Damit ich mich auch nach meinem Praktikum ein wenig mehr um Netzwerke kümmern kann, ist meine neue Errungenschaft ein altes Cisco Catalyst 2924-Switch.

Lautstärketechnisch würde es sich in einem Rack in einem Rechenzentrum wahrscheinlich sehr gut einfügen – für mein Zimmer ist es aber definitiv viel zu laut! Was macht also der findige Informatiker? Richtig, Lüfter abklemmen!

3 Stück sind standardmäßig drin, laufen tut das Switch auch mit einem. Dieser eine ist aber dennoch extrem laut, da er dauerhaft unter „Vollgas“ läuft. Ich hab also kurzerhand mein E-Technik-Equipment meiner alten Ausbildung wieder ausgegraben und ein wenig gemessen und mit Widerständen rumgebastelt.

Dabei konnte ich dann folgende Erkenntnis gewinnen:

100 Ohm vor dem Lüfter machen etwas leiser.

150 Ohm machen noch etwas leiser.

200 Ohm lassen den Lüfter nicht mehr andrehen.

Stößt man den Lüfter bei 200 Ohm mit der Hand an, läuft er – viel leiser! Problem ist dann halt nur, den Anstoss zu geben.

Mögliches Workaround:

Man baut sich einen Schalter, bei dessen Betätigung der Widerstand überbrückt wird. Damit dreht der Lüfter an. Danach kann der Widerstand eingeschliffen werden, so dass der Lüfter langsam weiter läuft.

Oder:

Temperaturgesteuerte Widerstände. Je wärmer das Switch wird, desto schneller drehen die Lüfter. Würde darauf hinauslaufen, dass die Lüfter beim Einschalten des Switches gar nicht drehen, sondern erst ab einer gewissen Temperatur ihren „Anlaufpunkt“ erreichen und nach und nach wieder langsamer drehen, wenn die Temperatur sinkt.

Oder:

Löcher in den Gehäusedeckel bohren und dann einen langsamdrehenden Papst-Lüfter reinschrauben. Dazu dann noch passive Kühlblöcke auf die hitzeproduzierenden Bauteile und Wärmeleitpaste dazwischen und das wars…

Mal sehen, wie ich mich letztendlich entscheide, die optimalste Lösung wäre, ein komplett passiv gekühltes Switch zu haben. Das wird aufgrund der recht starken Hitzeentwicklung der ICs auf der Platine wohl nicht möglich sein – aber leiser als momentan geht es auf jeden Fall.

Edit: Hab gerade einen Lüfter rausgeschmissen und die beiden verbleibenden Lüfter mit 100 Ohm Widerständen versehen… ist schonmal recht leise, kühlt aber weiterhin passabel. Nächste Woche werd ich mir dann vielleicht mal zwei temperaturgesteuerte Widerstände besorgen… schaden kanns auf jeden Fall nicht und sooooo teuer sollten die ja auch nicht sein.

Wenn jemand noch andere Ideen hat, die mein Switch leiser machen, ohne es durchbrennen zu lassen – immer her damit!

VLAN Hopping bei Cisco-Switchen

Im Zuge meines Praktikums habe ich mich in den letzten zwei Tagen ein wenig mit VLAN Hopping [1] beschäftigt.

Es gibt dabei zwei Arten des VLAN Hopping:
1. Man verbindet sich als Trunk mit einem Port eines Switches welcher entweder selber ein Trunk-Port ist, oder auf Auto/Desirable steht und somit vom Switch zu einem Trunk-Port gemacht werden kann. Klappt dies, hat man Zugriff auf andere VLANs und kann munter Frames durch die Gegend schicken.
2. Man baut sich ein Paket, mit sog. double encapsulation. Sprich: Man sendet als ganz normales Endgerät ein Paket an einen Trunk-/Auto-/Desirable-Port eines Switches, in dem bereits zwei VLAN-Tags vorhanden sind. Das Switch liest das Paket ein und entfernt Tag 1 und wirft das Paket ins zugehörige VLAN. Das nächste Switch nimmt das Paket auf, sieht Tag 2, entfernt es und wirft das Paket in das Ziel-VLAN.

Soweit die Theorie! Ich habe mir zwei Cisco [2] Switches besorgt (2940 und 3500XL) und zwei Rechner und habe alles folgendermaßen konfiguriert:
Rechner 1 -> 2940 -> 3500 -> Rechner 2
Dabei war Rechner 1 in VLAN 5 und Rechner 2 in VLAN 7. Es sollte also keine Kommunikation stattfinden können, da die Rechner sich überhaupt nicht sehen konnten und kein Router im Spiel war.

Während des Tests habe ich mehrere ICMP-Pakete fingiert und zwei VLAN-Tags eingefügt (mit Packeth [3]), es ist allerdings kein Paket zum Zielrechner durchgekommen.

Warum? Nun, das ist ganz einfach zu erklären: Diese ganzen tollen VLAN-Theorien werden schlichtweg ausgehebelt, wenn man als Attack-Rechner nicht an einem Trunk-Port hängt. Da bei meiner Konfiguration DTP [4] abgeschaltet war, mein Verbindungsport zum Switch als festeingestellt ein Access Port war, kam kein einziges Paket durch.

Im Nachhinein habe ich das ganze dann nochmal über einen Trunk-Port getestet und schon kamen meine Pakete durch. Wer also Switche sicher(er) konfigurieren will, legt selber fest, welcher Port welchen Modus hat.

Konfiguriert man normale Ports als Access-Ports, müsste ein Angreifer schon physischen Zugriff auf das Switch haben, um sich auf einen Trunk-Port zu verbinden und das sollte doch in den meisten Fällen sehr unwahrscheinlich sein.
In diesem Zusammenhang sei noch folgendes angemerkt:
Wenn man die Switches konfiguriert, AUF JEDEN FALL Passwörter setzen.
Wenn man das Webinterface zur Konfiguration nicht benötigt, ABSCHALTEN.
Wenn man das Switch remote Verwalten möchte, SSH [5] statt Telnet nutzen.
Benutzt man SNMP [6], dann bitte nicht in Version 1, sondern Version 3.
Nicht benötigte Ports abschalten.
Wenn möglich, MAC-Filter setzen.

So, das war mal mein Wort zum Samstag.

---

[1]: http://en.wikipedia.org/wiki/VLAN_hopping
[2]: http://www.cisco.com
[3]: http://packeth.sourceforge.net/
[4]: http://en.wikipedia.org/wiki/Dynamic_Trunking_Protocol
[5]: http://en.wikipedia.org/wiki/Ssh
[6]: http://en.wikipedia.org/wiki/Snmp

Vim: Autoindent abschalten

Wer kennt das nicht: Man hat sich ein paar hundert Zeilen in die Zwischenablage kopiert, erstellt mit dem Vim ein neues Dokument, fügt den Inhalt der Zwischenablage ein… und es sieht grauenhaft aus! Jede Zeile ist um ein Tab weiter eingerückt. Wunderbar – besser gesagt: Nicht lesbar!

Doch auch dafür gibt es Abhilfe:
echo set noautoindent >> /etc/vim/vimrc
und schon wird der Inhalt der Zwischenablage sauber formatiert eingefügt!

Ethernet-Bridge DHCP-Paket Analyse

Zugegeben, der Titel klingt spannender als die Arbeit eigentlich war. Aber egal, interessant war es trotzdem!

Vorweg noch ein wichtiger Hinweis: Die im folgenden beschriebenen Arbeiten habe ich ausschließlich in meinem privaten Netzwerk durchgeführt und die gewonnenen Daten dienen auch lediglich der Analyse. Mal davon ab, handelte es sich bei dem ganzen „Projekt“ um eine Hausaufgabe!

So, jetzt gehts los:
Mein Analyse-PC hat vor ein paar Tagen eine zweite Netzwerkkarte spendiert bekommen, weil ich die Pakete, die aus meinem Zimmer Netzwerk in Richtung Router (und damit Internet) gehen, einfach mal sehen wollte.
Oder um es ganz simpel auszudrücken:
Welche Anwendung brüllt was ins Netz?

Schritt 1 (Einbau der zweiten Netzwerkkarte):
Na ja, es sollte jedem klar sein, wie man eine Netzwerkkarte in einen PC bekommt. In meinem Fall war das Ganze mit ein wenig Fummelei verbunden, da mein Test-PC ein Micro-ATX-Board mit nur 2 PCI-Steckplätzen eingebaut hat.

Schritt 1,5 (Installation des Betriebssystems)
Bei mir notwendig, weil ich gleichzeitig noch eine neue Festplatte in den PC gebaut habe.
Debian Testing gabs auf die Platte, zu beachten nichts weiter, außer dass die Installation beide Netzwerkkarten als eth0 und eth1 erkennt und man wählen muss, welches die primäre Netzwerkkarte werden soll.
Das Netzwerk nicht per DHCP konfigurieren lassen, sondern feste IPs vergeben!

Schritt 2 (Ethernet-Bridge bauen)
Dank Werner (Arbeitskollege), der mich auf einen Artikel auf heise.de hingewiesen hat, war das erstellen der Ethernet-Bridge denkbar einfach:
ifconfig eth0 -arp promisc 0.0.0.0 up
ifconfig eth1 -arp promisc 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 -arp promisc 0.0.0.0 up
Funktioniert brctl nicht, muss das Paket bridge-utils nachinstalliert werden. (Das geht aber nur vor den beiden ifconfig-Schritten, wenn man nur über 2 Netzwerkkarten verfügt)
Zu beachten gibt es eigentlich nichts weiter, bei mir hat das alles auf Anhieb geklappt.

Schritt 3 (Pakete analysieren)
Es gibt sicher andere Tools, aber ich habe den Wireshark benutzt. Als capture device einfach br0 angeben und bei Bedarf die Paketauswahl eingrenzen und dann kann es losgehen

Schritt 4 (Fazit):
Einfach und schnell, aber effektiv. So geht der Einstieg in die Netzwerkanalyse gut von der Hand und macht sogar Spaß Quasi etwas für die ganze Familie
Interessant fand ich folgenden Sachverhalt:
Debian-Kommunikation mit dem DHCP-Server:
(Client) Discover -> (Server) Offer -> (Client) Request -> (Server) Acknowledge -> (Client) Release

Windows XP-Kommunikation mit dem DHCP-Server:
(Client) Request -> (Server) Acknowledge -> (Client) Inform -> (Client) Inform
Kein Discover, kein Offer, kein Release… die Frage ist nur: Warum?

So, damit erstmal genug für heute. Mal sehen, es noch so zu entdecken gibt…

EDIT: Wieder was dazu gelernt! Ich weiß jetzt warum Windows weniger DHCP-Pakete durch die Gegend schickt als Debian.
Das Lease für die Windows-IP ist noch nicht abgelaufen, also wird nur geprüft (Request -> Acknowledge) ob die Informationen noch gültig sind. Außerdem wird an dieser Stelle das Lease verlängert.
Bei meinem Debian ist das so nicht möglich, da beim runterfahren ein Release gesendet wird, womit das aktuelle Lease gecancelt und die IP-Adresse wieder freigegeben wird.
Laut RFC2131 sind beide Wege korrekt – der Debian-Weg kostet aber etwas mehr Netzwerktraffic, was sich vor allem in großen Netzwerken bemerkbar machen dürfte.
Im Gegensatz dazu läuft bei einer langen Lease-Time die Range des DHCP-Servers schneller voll, wenn Windows nie ein Release sendet…

ScummVM MIDI-Problem

So, da wollte ich doch mal ein paar alte Klassiker über ScummVM spielen. Zu Anfang sah alles noch recht einfach aus:

apt-get update
apt-get install scummvm
/usr/games/scummvm

Dann ein paar Spiele hinzufügen (die muss man schon selber zur Verfügung stellen – Beneath A Steel Sky und Flight Of The Amazon Queen gibts aber zu Linux dazu).

Und dann gib ihm. Dachte ich.
Using configuration file: ~/.scummvmrc
Looking for monkey
Trying to start game 'The Secret of Monkey Island'
Can't subscribe to MIDI port (65:0) see README for help!

Nach ein wenig googlen fand ich dann die Lösung! Man muss ScummVM auf den Alsa-Port 17:0 umbiegen:
vim ~/.scummvmrc
alsa_port=17:0 einfügen
/usr/games/scummvm

Looking for monkey
Trying to start game 'The Secret of Monkey Island'
Can't subscribe to MIDI port (17:0) see README for help!

Mmh. Weiter googlen! Irgendjemand schrieb dann was von aconnect -o -l

ocelot:/home/nickolsen# aconnect -o -l
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'

Idee: Warum ScummVM nicht auf den vorhandenen Port 14 umbiegen?

vim~/.scummvmrc
alsa_port=14:0
/usr/games/scummvm

Und die Spiele starten… aber leider ohne Sound.

Wieder eine Baustelle…