In meinem Haushalt werkeln zwei Raspberry Pi 2 Model B vor sich hin und erledigen Aufgaben zur Heimautomatisierung. Dabei halten mich die beiden Helfer im Normalfall per E-Mail über ihre Befindlichkeiten auf dem Laufenden. Es wäre praktisch, dachte ich mir, wenn es einen alternativen Kommunikationsweg als Fallback-Lösung gäbe, falls das heimische Netzwerk einmal aus irgendeinem Grund nicht erreichbar ist.

Eine Kommunikation per SMS ist vergleichsweise günstig zu realisieren und praxistauglich für unterwegs. Stand-alone zu betreibende GSM-Modems in der Art von Falcom Twist oder Siemens TC35i/M35i sind schick und zuverlässig, aber für meinen Einsatzzweck zu sperrig. Es sollen schlanke Module (Platinen) sein, die huckepack zu montieren sind und sich an der vorhandenen Stromversorgung des Raspberry nähren können.

Bei www.roboter-bausatz.de ist unter der Artikelnummer RBS10504 ein „GSM Modul Kit für Arduino“ zum Preis von 9,90 Euro erhältlich. Es basiert auf dem GSM-Modul Neoway M590E und kommt als Bausatz mit nur wenigen zusätzlichen SMD-Bauteilen zum Selberlöten daher. Begibt man sich auf eine Suche im Netz, stellt man fest, dass dieses Kit sehr populär zu sein scheint und allerorten angeboten wird — bei chinesischen Anbietern zuweilen für unter 2 Euro das Stück. Da stellt sich die Frage: Saugt das oder taugt das?

Das Kit

Geliefert wird das Kit in einem verschweißten Antistatik-Beutel. Darin enthalten: Platine, Antenne, GSM-Modul, SIM-Kartenhalter sowie eine handvoll Kleinkram und SMD-Krabbeltierchen. Die Platine macht einen guten Eindruck, einige andere Bauteile sehen irgendwie gebraucht aus: Das Etikett abgewetzt, die Kontakte verzinnt, der SIM-Kartenhalter teilweise mit Zinnresten überzogen. Man muss annehmen, dass es sich hier um gebrauchte Komponenten handelt oder um solche, die zur Wiederverwendung von anderen Baugruppen „geerntet“ wurden.

Ein Beutel enthält zwei LEDs in unterschiedlichen Bauformen, obwohl nur eine benötigt wird. Im anderen Beutel fehlt der (einzige) SMD-Elko, stattdessen enthält dieser eine (nicht benötigte) SMD-Diode. Vor meinem geistigen Auge sehe ich arme Lohnknechte, die unter schwierigen Bedingungen Tüten packen, und fühle mich schuldig. Apropos „nicht benötigt“: Eine Aufbauanleitung liegt nicht bei; was wohin zu löten ist, muss man selbst herausfinden. Dank des Internets und des herunterladbaren Entwurfshandbuchs zum M590E ist diese Herausforderung zu meistern.

Das Entwurfshandbuch gibt zahlreiche Empfehlungen für ein gutes Schaltungs- und Platinendesign, welches Störungen vermeiden und einen stabilen Betrieb fördern soll. Die Entwickler der Platine, so scheint es, haben sich davon nicht verrückt machen lassen und sind ihren eigenen Weg gegangen. Beispiele:

DO NOT USE SERRIES diodes to directly step-down the voltage.

Hier wird dennoch eine Diode in Serienschaltung als Verpolungsschutz und zum Absenken der Versorgungsspannung verwendet. Der M590E arbeitet mit 3,3 V bis 4,8 V, wobei 3,9 V der empfohlene Wert ist. Das entspricht ungefähr dem Niveau einer Lithium-Zelle. Für den Betrieb an 5 V ist es natürlich zu verlockend, sich an dieser Stelle mit einer Diode zu behelfen. Ich habe diese auch eingelötet und ziehe mir provisorisch die 5 V vom Raspberry herüber.

USE HIGH VALUE, LOW ESR CAPACITORS, CLOSE TO THE MODULE.

Hier ist genau eine Bestückungsposition vorgesehen für den beiliegenden Tantal-Elko mit 100 μF (C1 laut Entwurfshandbuch). Schöner wären weitere Bestückungspositionen für zusätzliche Kondensatoren (C2 & C3). Bei der Bestückung mit 100 μF können laut Entwurfshandbuch im Sendebetrieb Spitzenströme von bis zu 1,2 A auftreten.

When designing the serial communication interface circuit, a series resistor should be used should the external MCU be operating on a higher voltage – a 200 Ohm resistor should be used if the external MCU is operating on 3.3V. […] A filter capacitor of 100pF should be placed near the module receive pin.

Weder Serienwiderstand noch Filterkondensator sind vorgesehen, müssen also bei Bedarf fliegend oder extern ergänzt werden. Die GPIO-Ports des Raspberry arbeiten mit 3,3 V, die seriellen Ports des M590E mit 2,85 V, aus diesem Grund habe ich zur Entkopplung in die RxD- und TxD-Leitung je einen Serienwiderstand eingesetzt.

Um das Bild abzurunden, bleibt noch zu erwähnen, dass eines der beiden GSM-Module sich partout nicht zur Zusammenarbeit bewegen lassen wollte, also wohl defekt ist. Es bootet nicht trotz testweise nachgerüsteter Pufferkapazitäten, kommuniziert nicht über die serielle Schnittstelle und saugt nur gepulst im Abstand weniger hundert Millisekungen Ströme aus dem Labornetzteil. Zum Glück bekam ich vom freundlichen Shop ohne Diskussionen ein Ersatzmodul nachgeliefert.

Und trotz des ganzen Gemäkels klappt es am Ende mit der Funkerei. Nachfolgend abgebildet mein Testaufbau des GSM-Moduls auf dem Experimentierboard. Damit das Modul gesättigt an der 5-V-Versorgung des Raspberry mitnuckeln kann, habe ich eine Parallelschaltung von 100 nF und 1000 μF Low-ESR-Elko anstelle des einzelnen Tantal-Elkos aufgelötet. Vorteil: Der Spitzenstrom im Betrieb reduziert sich damit auf 0,6 A und das Modul ist gut versorgt. Nachteil: Beim Einschalten muss sich der dicke Elko einmalig vollsaugen, wodurch das Netzteil kurzzeitig stark belastet wird — so stark, dass der Raspberry einen Reboot durchläuft, wenn man das Modul im Betrieb anklemmt. Für einen betriebsfertigen Aufbau werde ich mir also eine robustere Lösung überlegen müssen, notfalls mit zwei getrennten Stromversorgungen.

Erste Kontaktaufnahme per Minicom

Für die serielle Kommunikation verwende ich die Pins GPIO14 (UART0_TXD) und GPIO15 (UART0_RXD) über das Device /dev/ttyAMA0. Ist dieses nicht verfügbar, muss zunächst mittels des Tools raspi-config die standardmäßig auf den Pins aktivierte serielle Login-Shell deaktiviert und die Nutzung als serielle Schnittstelle aktiviert werden:

sudo raspi-config

Interfacing Options
> Serial
  > Would you like a login shell to be accessible over serial?
    <no>
  > Would you like the serial port hardware to be enabled?
    <yes>

Nach einem Reboot sollte das Device nun zur Verfügung stehen:

ls -al /dev/ttyAMA0 
crw-rw---- 1 root dialout 204, 64 Jul 09 18:06 /dev/ttyAMA0

Anschließend kann die erste Kontaktaufnahme zum GSM-Modul über ein Terminal erfolgen. Ich verwende dafür das Programm Minicom.

sudo apt-get install minicom

Damit der Standard-User pi auf die serielle Schnittstelle zugreifen darf, muss dieser zur Gruppe dialout hinzugefügt werden.

sudo adduser pi dialout

Anschließend einmal ab- und wieder anmelden und ausprobieren:

minicom -b 115200 -o -D /dev/ttyAMA0

Die Willkommensmeldung überspringen mit Taste <ENTER>. Dann lokales Echo aktivieren mit Tastenkombination <STRG>+<A> und dann Taste <Z> und dann Taste <E>. Nun Eingabe AT <ENTER> usw.

AT
OK

AT+CPIN="1234"
OK

AT+CPIN?
+CPIN:READY

Verlassen des Terminals mit Tastenkombination <STRG>+<A> und dann Taste <Q> und dann Taste <ENTER>. Die verfügbaren AT-Befehle sind dokumentiert in der Befehlsreferenz des M590E.

SMS-Daemon als Poststelle

Der SMS-Daemon smsd ist im Paket smstools enthalten. Ähnlich wie ein MTA (Mail Transfer Agent) für das Senden und Empfangen von E-Mails, kümmert sich der SMS-Daemon im Hintergrund um das Senden und Empfangen von SMS.

sudo apt-get install smstools

Für eine grundlegende Funktion müssen nur wenige Parameter in der Konfigurationsdatei /etc/smsd.conf eingetragen werden (diese finden sich ganz am Ende der Datei):

[GSM1]
device = /dev/ttyAMA0
incoming = yes
pin = 1234
baudrate = 115200

Anschließend den SMS-Daemon einmal neu starten:

sudo service smstools restart

Damit der Standard-User pi auf die Verzeichnisstruktur des SMS-Daemons zugreifen darf, muss dieser zur Gruppe smsd hinzugefügt werden.

sudo adduser pi smsd

Anschließend einmal ab- und wieder anmelden und via echo-Befehl eine Test-SMS versenden:

cd /var/spool/sms/outgoing
echo -e "To: 491575xxxxxxxx\n\nEine Test-SMS!" > testdatei

Oder via Editor vi, dort ist die erforderliche Leerzeile zwischen der Rufnummerangabe und der Textmitteilung besser erkennbar:

vi /var/spool/sms/outgoing/testdatei

To: 491575xxxxxxxx

Eine Test-SMS!

Innerhalb weniger Sekunden sollte die SMS nun an ihren Empfänger versendet werden. Im Normalfall, wenn es geklappt hat, wird die soeben erzeugte Datei testdatei aus dem Verzeichnis /var/spool/sms/outgoing verschwunden sein und — um ein paar Info-Zeilen ergänzt — im Verzeichnis /var/spool/sms/sent wieder auftauchen:

To: 491575xxxxxxxx
Modem: GSM1
Sent: 17-07-09 19:09:11
IMSI: 24xxxxxxxxxxxxx


Eine Test-SMS!

Ging etwas schief, findet sich die Datei im Verzeichnis /var/spool/sms/failed wieder, ergänzt um einem Fehlerhinweis. Eingehende SMS landen automatisch im Verzeichnis /var/spool/sms/incoming.

Mit ein wenig Skripterei umzu lässt sich also eine einfache Remote-Steuerung des Raspberry per SMS auf die Beine stellen. Eine Auswertung des RING-Signals (für eingehende Anrufe) sowie die Datenkommunikation per GPRS habe ich bisher nicht benötigt und nicht ausprobiert.

SyxLoader Version 1.5 now offers a new preferences dialog to control the event splitting behaviour. This hopefully will be useful for users of USB class-compliant interfaces who experience data loss or corruption on sysex transmissions.

Read more »

The following is a brief example of how to compile a kernel module from the qla2x00-source package to get a QLogic QLA2340 fibre channel HBA working under Debian Sarge. This works well for me using kernel image 2.4.27-3 SMP. Many thanks to the kind package maintainers.

Edit your sources.list and add non-free branch to get qla2x00-source package via apt-get.

$ vi /etc/apt/sources.list

[...]
deb ftp://[...]/debian/ stable main non-free
deb-src ftp://[...]/debian/ stable main non-free
[...]
deb http://security.debian.org/ stable/updates main non-free

$ apt-get install bzip2

$ cd /usr/src

$ apt-get install qla2x00-source

$ bzip2 -cd qla2x00.tar.bz2 | tar xf -

$ apt-get install kernel-source-2.4.27

$ bzip2 -cd kernel-source-2.4.27.tar.bz2 | tar xf -

$ ln -s kernel-source-2.4.27 linux

$ cd linux

$ cp /boot/config-2.4.27-3-686-smp .config

$ apt-get install kernel-package

$ make oldconfig

$ make-kpkg --append-to-version=-3-686-smp \
--added-modules=qla2x00 modules_image

$ cd ..

$ dpkg -i qla2x00-modules-2.4.27-3-686-smp_[...]Custom_i386.deb

$ insmod qla2300

Check which device is available (see /var/log/messages) and where to mount preferably, then edit fstab.

$ vi /etc/fstab

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
[...]
/dev/sdb1       /san            ext3    defaults        0       0
[...]

$ mkdir /san

$ /sbin/mkfs.ext3 /dev/sdb1

$ mount /dev/sdb1

$ df -ak

Filesystem           1K-blocks      Used Available Use% Mounted on
[...]
proc                         0         0         0   -  /proc
[...]
/dev/sdb1             51606124     32828  48951860   1% /san

Maybe clean up a little bit.

$ apt-get remove --purge kernel-source-2.4.27

$ apt-get remove --purge qla2x00-source

$ cd /usr/src

$ rm linux

$ /bin/rm -r kernel-source-2.4.27

$ /bin/rm -r modules

A few weeks ago VMware released their free VMware Server Beta virtualization software which I downloaded and installed on my little Debian slave, an AMD Duron 1300 with 512MB RAM. This machine normally holds backups of my main computer and serves as a general purpose Linux box and webserver for me at home. Well, I had to learn that there is still much more that you can do with it.

Every now and then I wished to have more than one Linux box so that I could easily try something out and get rid of it afterwards without touching my default installation. And, yes, very seldom I’d like to have a Windows 98 environment to compile and test an older piece of software. But yet I was neither willing to provide a third computer for that nor to struggle with drive images or multi-boot setups.

And now these wishes become true at no cost with VMware Server. You see, I am excited. So I took the following screenshots to demonstrate how simple a new virtual machine can be brought to life. The shots are taken from VMware Server Console running on my Windows XP main machine to control the Debian slave with VMware Server.

You may complain about the one or another shot being redundant, but my intention is to also produce an authentic impression of this beautiful installation process that we all got to like that much over the years. Of course, the good old Windows 98 startup disk had been prepared and inserted into Debian slave’s disk drive ;-)

Imagine you set up dozens of virtual hosts and want each of them to have an individual default password for a protected area, i.e. a logfile directory being accessible via http://vhost/logs/. Putting .htaccess files into the target directories is step one and fairly simple. Whereas step two, adding the .htpasswd files, may end up unhandily, either juggling with cleartext and encrypted passwords or falling back on system() calls of htpasswd(2).

The example below shows how this can be handled with the modules Apache::Htpasswd and String::Random. Just provide a filename and a username, the subroutine will create the .htaccess file, add the user with a new random password and return the cleartext password to be handed out to your customer.

use String::Random;
use Apache::Htpasswd;

sub DefaultHtpasswd($$) {
  my($Filename,$Username) = @_;

  my $RandomString = new String::Random;
  my $PasswdString = $RandomString->randpattern('nnCcCnCc');

  my $Htpasswd = new Apache::Htpasswd($Filename);

  $Htpasswd->htpasswd($Username, $PasswdString, 1)
  or die($Htpasswd->error);

  return($PasswdString);
}