03:06.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 02)
Subsystem: Belkin F5D7000 v1000 Wireless G Desktop Card [1799:7000]

Some years ago, this card was working perfectly fine with the bcm43xx module. However, this module became deprecated and got replaced by the b43 and b43legacy modules. My card now had to use the b43legacy module and that’s where the problems started:
The connection speed was very slow and the connection dropped every few minutes. Trying to download a larger file became a pain. dmesg was full of these messages:

b43legacy-phy0 ERROR: PHY transmission error

Pasting that into google showed me that I was not alone with these issues, the only fix that seemed to work was dropping the b43legacy module and using ndiswrapper with a windows driver file. It took me some while to find a 64bit Windows driver file for that specific card [contact me if you can't find one] because it’s quite outdated, but I finally got one.

So I went ahead, installed ndiswrapper and the driver for it…

adi64@tux ~ % sudo ndiswrapper -l
bcmwl5 : driver installed
device (14E4:4320) present

…but wlan0 wouldn’t show up, despite the fact that ndiswrapper found the device:

adi64@tux ~ % sudo rmmod b43legacy
adi64@tux ~ % sudo modprobe ndiswrapper
adi64@tux ~ % iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

There were no errors or any debug info from ndiswrapper in either dmesg or /proc/net/ndiswrapper/debug.

After googling the hell out of keywords like b43legacy, bcm4306, ndiswrapper etc. I found the Comprehensive ndiswrapper troubleshooting guide on the Ubuntu forums which finally helped.
In a nutshell: The ssb module claimed the device although being unable to do anything with it, therefore ndiswrapper couldn’t take control of the device.

Knowing this, the solution is simple. You need to blacklist the b43legacy and ssb modules and tell the kernel to load the ndiswrapper module.
I opened up the new file /etc/modprobe.d/b43legacy_blacklist.conf and pasted in the following:

blacklist b43legacy
blacklist ssb

Then I added ndiswrapper to my MODULES Array in /etc/rc.conf.
Doing a reboot and BAM! The card was working fine. Note however that you won’t be able to do things like Monitor Mode etc. with ndiswrapper as device driver.

During the next time, I will have a bit more free time on my hands than before and therefore I decided to translate most articles and pages. The big articles and pages have highest priority.

Enjoy reading our blog in English!

Ich stell mich mal kurz vor… ich bin ein Kumpel vom Adrian, der in etwa ähnliche technische Interessen hat. Auf der einen Seite hab ich so gut wie keine Zeit dafür, aber auf der anderen programmiere ich dann doch ab- und zu etwas oder mache etwas anderes technisches. Da ich ein Opensource Fan bin, würde ich meine Ergebnisse der Welt gerne zur Verfügung stellen und werde es hier in unregelmäßigen Abständen – eben sobald es etwas nützliches gibt – auch umsetzen

Let’s assume we implemented a ClientRequest-Message which sends certain requests to a server, for example a request to register a new player to the game. The corresponding part in our .proto-file would look somewhat like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

message ClientRequest {
	enum Operation {
		REGISTER_PLAYER = 1;
		[...]
	}
	optional RegisterPlayerParameters register_player_parameters = 3;
	[...]
}
 
message RegisterPlayerParameters {
	required PlayerInfo player_info = 1;
	[...]
}
 
message PlayerInfo {
	required string name = 1;
	[...]
}

Then our snippet to send this to a server would look like that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

using namespace boost::asio;
boost::asio::io_service io_service;
tcp::resolver resolver(io_service);
tcp::resolver::query query(tcp::v4(), “127.0.0.1?, 12345); // host and port
tcp::resolver::iterator iterator = resolver.resolve(query);
 
sock = new tcp::socket(io_service);
sock->connect(*iterator);
 
// Protobuf-Messages
ClientRequest req; // the only one being initialized
RegisterPlayerParameters* rpp; // pointer, will be assigned later throuh req
PlayerInfo* info; // pointer, will be assigned later through rpp
 
req.set_operation(ClientRequest::REGISTER_PLAYER); // set parameter
 
// we want a pointer to the RegisterPlayerParameters-Object !inside! the ClientRequest-Object
rpp = req.mutable_register_player_parameters();
 
// we want a pointer to the PlayerInfo-Object !inside! the RegisterPlayerParameters-Object
info = rpp->mutable_player_info(); // mutable, damit wir es ändern können
 
// Now we can set values
info->set_name(name);
 
boost::asio::streambuf b;
std::ostream os(&b); // Protobuf wants to serialize to a stream (which in turn packs everything into an asio streambuffer which we can send easily)
 
// get a packed version of the req object (remember, this will go to the asio streambuf b!)
req.SerializeToOstream(&os);
 
// Send the content of the streambuffer to our open socket
boost::asio::write(*sock, b);

Mein System lief auf einem 1GB USB-Stick und lief eigentlich ziemlich super. Lief. Ja. Das ist der Knackpunkt: Mein USB-Stick ist ziemlich tot.

Das äußert sich darin, dass plötzlich irgendwelche Befehle nicht mehr tun, ich kryptische Errors um den Kopf geworfen bekomme und das System nicht mehr bootet, weil das ext2-fs so stark beschädigt ist, dass es nicht durch den routinemäßigen Check beim boot repariert werden kann, sondern manuell per e2fsck gefixt werden muss (von einem anderen pc aus).

Die Ursache dafür liegt darin, dass die in USB-Sticks und SD-Karten verbauten Flash-Chips zwar praktisch unendlich viele Lesevorgänge, aber nur ca. 10.000 – 100.000 Schreibzyklen pro Sektor verkraften. Das ist normalerweise absolut kein Problem, wenn man einfach nur “Daten” auf diesen Sticks zwischenspeichert. Außerdem versuchen die Hersteller meist, die Schreibvorgänge auf mehrere Sektoren zu verteilen, um ein Überschreiben von immergleichen Sektoren zu vermeiden. Letzteres kann aber natürlich nicht funktionieren, wenn der Stick quasi voll ist.

Wenn man aber ein Betriebssystem auf dem Stick betreibt, können diese Zyklen relativ schnell erreicht sein, vor allem durch Logfiles, Lockfiles und temporäre Daten. Auf diese Weise hat sich wie eingangs schon erwähnt mein (zugegeben ziemlich billiger und schon länger gebrauchter) USB-Stick verabschiedet.

Da viele Teile dermaßen beschädigt waren, dass das Reparieren verdammt aufwändig geworden wäre, habe ich das System von Neuem hochgezogen. Dabei habe ich mir die Frage gestellt: Wie kann ich vermeiden, dass das System wieder meinen Stick screwed? Als erstes kam mir die Idee, einfach das rootfs read-only zu mounten. Das hat aber zur Folge, sämtliche Schreiboperationen im RAM zu cachen. Da die Dockstar nur 128MB RAM hat, schied diese Möglichkeit aus. Als zweites kam mir die Idee, die ich jetzt auch umgesetzt habe:

Flüchtige Daten in einer Ramdisk halten

Das heißt, ich mounte mir einen Teil des spärlich vorhandenen RAMs als Datenträger und mappe ihn als Ersatz für die Verzeichnisse

• /var/log (Logfiles)
• /var/lock (Sperr-Files)
• /var/run (Daemon-PIDs)
• /var/tmp (Temporäre Dateien)
• /tmp (Temporäre Dateien).

Dadurch fange ich fast alle Schreibzugriffe ab, welche im Dauerbetrieb eben anfallen. Änderungen an Configfiles etc. werden aber immernoch sofort auf den Stick geschrieben. Falls das System sich aufhängt, abstürzt oder ähnliche Scherze passieren, ist der “zusätzliche” Datenverlust also gering (nur die neueren Logfiles). Trotzdem: Hier werden einige Dateien nur im RAM vorgehalten. Wenn das System crasht oder die Daten vorm Ausschalten nicht von der Ramdisk auf den Stick gesichert werden, sind sie weg!

Bevor ich mit der Anleitung beginne, sei hier die Seite cat brain.stuff > wordpress als Quelle genannt, da fast alle Informationen von dort stammen. Ich habe es lediglich zu Arch Linux / Plugbox Linux “geportet” und an meine Bedürfnisse angepasst.

Anlegen der Verzeichnisse

mkdir /var/log-bak

mkdir /var/lock-bak

mkdir /var/run-bak

mkdir /var/tmp-bak

mkdir /tmp-bak

mkdir /run-bak

mkdir /mnt/ramdisk

Den Daemon anlegen

Die Datei /etc/rc.d/ramdisk erstellen und folgendes hineinpasten:

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

case “$1″ in
start)
stat_busy “Copying files to ramdisk”

rm -Rf {/var/log-bak,/var/lock-bak,/var/run-bak,/var/tmp-bak,/tmp-bak,/run-bak}

mount –move /var/log /var/log-bak
mount –move /var/lock /var/lock-bak
mount –move /var/run /var/run-bak
mount –move /var/tmp /var/tmp-bak
mount –move /tmp /tmp-bak
mount –move /run /run-bak

mkdir /mnt/ramdisk/var
mkdir /mnt/ramdisk/var/log
mkdir /mnt/ramdisk/var/lock
mkdir /mnt/ramdisk/var/run
mkdir /mnt/ramdisk/var/tmp
mkdir /mnt/ramdisk/tmp
mkdir /mnt/ramdisk/run
mkdir /mnt/ramdisk/run/lock
chmod 1777 /mnt/ramdisk/tmp
chmod 1777 /mnt/ramdisk/var/lock
chmod 1777 /mnt/ramdisk/var/tmp
chmod 1777 /mnt/ramdisk/run

mount –bind /mnt/ramdisk/var/log /var/log
mount –bind /mnt/ramdisk/var/lock /var/lock
mount –bind /mnt/ramdisk/var/run /var/run
mount –bind /mnt/ramdisk/var/tmp /var/tmp
mount –bind /mnt/ramdisk/tmp /tmp
mount –bind /mnt/ramdisk/run /run

cp -a -v /var/log-bak/* /var/log/ >> /var/log/ramdisk_sync.log
cp -a -v /var/lock-bak/* /var/lock/ >> /var/log/ramdisk_sync.log
cp -a -v /var/run-bak/* /var/run/ >> /var/log/ramdisk_sync.log
cp -a -v /var/tmp-bak/* /var/tmp/ >> /var/log/ramdisk_sync.log
cp -a -v /tmp-bak/* /tmp/ >> /var/log/ramdisk_sync.log
cp -a -v /run-bak/* /run/ >> /var/log/ramdisk_sync.log

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced from HD >> /var/log/ramdisk_sync.log
if [ $? -gt 0 ]; then
stat_fail
else
add_daemon ramdisk
stat_done
fi
;;
stop)
stat_busy “Switching off ramdisk, direct hdd write”
rsync -av –delete /var/log/ /var/log-bak/
rsync -av –delete /var/lock/ /var/lock-bak/
rsync -av –delete /var/run/ /var/run-bak/
rsync -av –delete /var/tmp/ /var/tmp-bak/
rsync -av –delete /tmp/ /tmp-bak/
rsync -av –delete /run/ /run-bak/

# Unmount ramdisk bind
umount /mnt/ramdisk/var/log
umount /mnt/ramdisk/var/lock
umount /mnt/ramdisk/var/run
umount /mnt/ramdisk/var/tmp
umount /mnt/ramdisk/tmp
umount /mnt/ramdisk/run

# Unmount move
umount /var/log-bak
umount /var/lock-bak
umount /var/run-bak
umount /var/tmp-bak
umount /tmp-bak
umount /run-bak

# Deleting directories
rm -Rf /mnt/ramdisk/*

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced to HD >> /var/log/ramdisk_sync.log
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon ramdisk
stat_done
fi
;;
sync)
echo “Syncing log and lock files to harddisk”
rsync -av –delete /var/log/ /var/log-bak/
rsync -av –delete /var/lock/ /var/lock-bak/
rsync -av –delete /var/run/ /var/run-bak/
rsync -av –delete /var/tmp/ /var/tmp-bak/
rsync -av –delete /tmp/ /tmp-bak/
rsync -av –delete /run/ /run-bak/

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced to HD >> /var/log/ramdisk_sync.log
;;

restart)
$0 stop
$0 start
;;

*)
echo “usage: $0 {start|stop|sync}”
esac
exit 0

Die /etc/fstab anpassen

Dort eine Zeile hinzufügen à la

tmpfs                   /mnt/ramdisk    tmpfs   size=64m        0       0

Ich benutze hier bewusst tmpfs und nicht ramfs, da tmpfs bei akutem Ram-Mangel auf swap ausweicht, ramfs dies aber nicht tut. Weiterhin limitiere ich die Größe für die Ramdisk auf 64MB. Die Ramdisk wächst aber dynamisch, belegt also nur Platz, welchen sie auch braucht. Die 64MB sind nur ein grob geschätzter Maximalwert.

/etc/rc.conf anpassen

Hier sollte der Daemon als erster gestartet werden, damit so wenige Applikationen wie möglich den (sehr) kurzen Ausfall der oben genannten Verzeichnisse verkraften müssen. Euer DAEMONS-Array könnte also so aussehen:

DAEMONS=(ramdisk syslog-ng network openntpd netfs crond sshd)

Logrotate anpassen

Ein Punkt, der sich erst nach einiger Benutzung als wichtig herausgestellt hat: Die Logfiles können sehr groß werden und damit den RAM füllen. Um das zu verhindern, sollten die Logs in kurzen Zeitabständen rotiert werden.

Dazu passen wir die /etc/logrotate.conf an. Meine sieht so aus:

daily

rotate 3

size 16M

create

compress

tabooext + .pacorig .pacnew .pacsave

include /etc/logrotate.d

/var/log/wtmp {

weekly

create 0664 root root

rotate 1

}

Abschließende Worte

Soweit, so gut. Beim nächsten Neustart sollte euer System also nun den größten Teil der Schreiboperationen im RAM vorhalten. Ganz eilige können auch einfach den Daemon starten, es sollte auch so funktionieren. Was passiert, wenn ein Prozess genau dann der Meinung ist, ein Logfile schreiben zu müssen, wenn der Daemon gerade Verzeichnisse herumschiebt, kann ich absolut nicht vorhersagen.

Wenn ihr Verbesserungsvorschläge, Tipps, Kritik oder sonstigen Senf zum Zugeben habt, immer her damit.

Hätte ich einmal C++ RICHTIG gelernt und nicht alles zusammenklamüsert, wüsste ich sowas wahrscheinlich. Aber da der Grundkurs, den ich besucht habe, etwas arg verpeilt war und außer dem Klassenmodell und iostream kein C++ verwendete, sondern z.B. Speicher grundsätzlich mit “malloc” reservierte, war so etwas eben nicht drin.

Übrigens empfehlen die im “offiziellen” C++ Forum genau das, was ich auch im Hinterkopf hatte: geschachtelte Vektoren. Das wollte ich anfangs auch machen, dachte mir aber, dass es da doch was gescheites für geben müsste… mhja.

Das hier ist also mehr so für google, damit das andere auch finden ;D

http://www.cplusplus.com/forum/articles/7459/

Ich arbeite in der GeneCore-Abteilung und vergleiche verschiedene (kommerzielle und open-source / freie) Programme zur Analyse von riesigen Mengen (we’re talking ~1 TB per run) von RNA-Seq-Daten mit dem Ziel, am Ende eine “beste Lösung” für jedes Anwendungsgebiet zu haben.

Dabei habe ich gemerkt, wie verdammt wichtig eine gute Dokumentation ist. Das Forschungsfeld um RNA-Seq ist noch sehr jung und daher steckt auch die Software noch in den Kinderschuhen. Es ist aber teilweise wirklich unglaublich, wie schlecht Teile der Software dokumentiert sind und wie viel Zeit nur dafür draufgeht, Parameter und mögliche Interferenzen zu “erraten”…

Für mich als Schüler ist die Schnellebigkeit dieses Forschungsfeldes einfach der pure Wahnsinn. Papers zu neuen Erkenntnissen schießen wie Pilze aus dem Boden und referenzieren andere Schriften, die teilweise erst vor unter einem Monat veröffentlicht wurden. Zum Vergleich: In der Schule haben wir in manchen Fächern über 20 Jahre alte Bücher…

Best served in 720p

Ja, wer bei YouTube geschaut hat, hat vielleicht gemerkt, dass das Video nicht August, sondern Mai entstanden ist. Ich wollte das eigentlich schon länger hier auf dem Blog posten, habs aber irgendwie verpennt…