Tag Archives: Linux

Do not change already released files!

tl;dr: Please upstream developers: Do not ever change what you already published, but make an additional version with your fix. This causes less trouble for people building your stuff.

As some of you might have noticed: I’m a little into embedded Linux software and contribute to some of the build systems around, mainly to buildroot (for fli4l) and to ptxdist (at work). This is a very special kind of fun meaning constantly trying to fix things gone wrong. Today is a day where the temperatures outside I’m stuck, because someone else fucked up his stuff.

Last week I built myself an image for testing iperf on a BeagleBone Black with the current buildroot master. This got me a tarball iperf-2.0.9.tar.gz from some mirror server. This worked.

Today I upgraded a ptxdist BSP from some older state, I think 2016.12.0, to the recent ptxdist 2017.06.0 which included an upgrade of the package iperf from 2.0.5 to 2.0.9. This got me a complaint about an invalid checksum. Those embedded build systems contain checksums for tarballs, buildroot uses mostly sha256, while ptxdist still uses md5. This is mostly to ensure transport integrity, but it also triggers when the upstream tarball changes. Which it should not.

So now the checksums in buildroot master from today are still from buildroot changeset 2016.05-1497-g11cc12e from 2016-07-29:

Those are the very same to the file I have locally. Note: both ptxdist and buildroot download archives to the same shared folder here. The md5sum of this file is 1bb3a1d98b1973aee6e8f171933c0f61 and ptxdist aborts with a warning this sum would not match. Well in ptxdist the iperf package was changed on 2016-12-19 last time, also upgrading from iperf 2.0.5 and here the changeset is ptxdist-2016.12.0-10-gd661f64 and the md5sum expected: 351b018b71176b8cb25f20eef6a9e37c. This is the same you can see today on sf.net, but why is it different from the one above?

To find out I downloaded the file currently available on sf.net, which was last changed 2016-09-08, after buildroot included the package update. The great tool diffoscope showed me, a lot of the content between those two archives was changed. But why?

Seems I was not the first one noticing: #20 Release file: iperf-2.0.9.tar.gz changed!!! And the maintainer set it to WONTFIX.

Now this is the point where I’m not sure whether to just get pissed, deeply sighing, or trying to fix the mess for those build systems. The clean way would be upstream releasing some new tarball, either the one or the other or even make a new release, named 2.0.9a or whatever.

What are possible solutions?

  • Wait for upstream to make a clean, new release. (And hope this doesn’t get changed in the future.)
  • Upgrade those hashes in buildroot. This obviously breaks old versions of buildroot.

According to the buildroot IRC channel, they want their package to be updated, even if older releases will break. And they said they have a fallback and use their own mirror, so that’s where my first package may have come from.

Update: buildroot accepted my patch updating those hashes quickly.

Let a LED blink in different frequencies on Linux

There’s an embedded Linux board on my desk, where a LED is connected to some GPIO pin. Everything is set up properly through device tree and with a recent kernel 4.9.13 the usual LED trigger mechanisms work fine, so no problem using heartbeat or just switching the LED on and off.

Now I wanted to have the LED blink with certain patterns and it turns out, this is quite easy given you know how. You have to set LEDS_TRIGGER_TIMER in your kernel config first. Now go to the sysfs folder of your LED, here it is:

Have a look at the available triggers:

Switch to the timer trigger:

Now two new files appear, delay_on and delay_off. Per default both contain the value 500 which lets the LED blink with 1 Hz. Without further looking into the trigger code or searching for documentation I assume those values are the on and off times in milliseconds. So have the LED blink with a certain frequency the following formular could be used:

f_LED = 1000 / ( delay_on + delay_off )

So to set my LEDs to blink at 2 Hz frequency, I set it up like this:

Happy blinking!

C/C++ developers please use -Wcast-align

Did you ever read the GCC documentation part Warning Options? If not, you may know the -Wall option. Yeah well, it enables a lot of options, but not literally all possible warnings. In my opinion setting -Wall should be the minimum you should set in every project, but there are more. You can also set -Wextra which enables even more warnings, but as you now might guess, still not all. Missing is especially one option, this post is about and the following describes why I consider it important to set: -Wcast-align

So what does the GCC doc say about it?

Warn whenever a pointer is cast such that the required alignment of the target is increased. For example, warn if a char * is cast to an int * on machines where integers can only be accessed at two- or four-byte boundaries.

In case you can not imagine what this means, let me explain. For example there are 32bit-CPUs out there which access memory correctly only at 32bit boundaries. This is to my knowledge by design. Let’s say you have some byte stream starting at an arbitrary aligned memory offset and it contains bytes starting from 0, followed by 1, then 2 and so on like this:

Now you set an uint32_t pointer to a non aligned address and dereference it. What would you expect? To help you a little, I have a tiny code snippet for demonstration:

The naïve assumption would be the following output:

Note the last three containing some random bytes from memory behind our buffer! This is the output you get on a amd64 standard PC with little endian format (compiled on Debian GNU/Linux with some GCC 4.9.x).

Now look at this output:

This comes from an embedded Linux target with an AT91SAM9G20 Arm CPU, which is ARM9E family and ARMv5TEJ architecture or lets just say armv5 or older Arm CPU. Here It runs as little endian and was compiled with a GCC 4.7.x cross compiler.

Well those 32bit integers look somehow reordered, as if the CPU would shuffle the bytes of the word we point into? If you’re not aware of this this means silent data corruption on older Arm platforms! You can set the -Wcast-align option to let the compiler warn you, you may try this by yourself with the above snippet and your favorite cross compiler. Note: the warning does not solve the corruption issue, it just warns you to fix your code.

When reading the FAQ by Arm itself on this topic it’s not quite clear what the supposed behavior is, but what is clear is the following: unaligned access is not supported on older Arm CPUs up to ARM9 family or ARMv5 architecture.

Another point is interesting: even if the CPU supports unaligned access, whether it’s hard coded or an optional thing you must switch on first, it will give you a performance penalty. And coming back to my PC: this is also true for other processor families like Intel or AMD, although on recent processors it might not be that bad.

So what could or should we do as software developers? Assuming there are still a lot of old processors out there and architectures you might not know, and you never know where your code will end up: design your data structures and network protocols with word alignment in mind! If you have to deal with legacy stuff or bad protocols you can not change, you still have some other possibilities, have a look at The ARM Structured Alignment FAQ or search the net on how to let your kernel handle this.

If you want to handle it in code, memcpy() is one possibility. Assume we want to access a 32bit integer at offset 2, we could do it like this:

And as said in the topic and above: turn on the -Wcast-align option!

(If you don’t want to be too scared about silent data corruption on your new IoT devices with those cheap old processors and your freshly compiled board support package, you might not want to turn it on on all those existing software out there. You might get a little depressed … )

Update: There’s a chapter on the Linux kernel documentation on this: Unaligned Memory Accesses.

KDevelop: Debuggen von Programmen, die root-Rechte benötigen

Häufig arbeite ich mit KDevelop und dort auch gern mit dem integrierten Debugger bzw. dem entsprechenden Frontend für gdb. Heute hatte ich ein Programm am Wickel, was einen lauschenden Socket auf einem privilegierten Port aufmachen will. Mit KDevelop konnte ich dies nicht direkt mit den nötigen Root-Rechten starten. Um es trotzdem debuggen zu können, kann man stattdessen mit gdbserver und remote debugging arbeiten. Das geht so:

In der bereits angelegten Launch Configuration geht man auf die Einstellungen für Debug und dort kann man unter »Remote Debugging« drei Dateien angeben. Man muss hier tatsächlich zwei bis drei Dateien anlegen und diese mit dem passenden Inhalt füllen. Die erste ist das gdb config script, wo man nochmal den Pfad zum ausgeführten Binary einträgt. Das sollte genau das sein, was auch über das Projekt kompiliert wird (mit Debug-Symbolen drin natürlich):

Das dritte ist das run gdb script, hier sagt man dem gdb wohin er sich verbinden soll, in diesem Fall wird das ein gdbserver sein, der auf der selben Maschine auf Port 12345 lauschen wird:

Jetzt ist noch die Frage, was kommt bei run shell script rein? Wenn man es leer lässt, muss man den gdbserver von Hand starten, bevor man in KDevelop auf »Debug« klickt, das könnte auf einer entsprechenden Konsole in dem Build-Ordner des Programms so aussehen:

Oder man baut sich noch eine dritte Datei, diesmal ein Shell-Skript, wo man den zuletzt genannten Befehl ausführt. Dieses gibt man dann an zweiter Stelle an. Klappte hier bei mir spontan nicht, weil sudo da noch nach einem Passwort fragt, was ich in KDevelop nicht eingeben kann.

Sometimes I’m in the mood to destruct my devices. Luckily some drivers may have an ioctl for that:

Most devices can perform operations beyond simple data transfers; user space must often be able to request, for example, that the device lock its door, eject its media, report error information, change a baud rate, or self desctruct.

(Linux Device Drivers, Third Edition, by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman, published 2005 by O’Reilly®)

Raspberry Pi automatisch mit dem Freifunk-WLAN verbinden

Ich setze gerade diverse Mini-Knoten auf Raspberry-Pi-Basis auf, die sich für den Internet-Zugang automatisch mit dem Magdeburger Freifunk verbinden sollen.

Anleitungen zur Verbindung mit einem WPA-verschlüsselten WLAN gibt es genug. Nur leider schweigen die zur Frage, was man denn mit einem unverschlüsselten WLAN1 macht.

Schließlich bin ich doch auf Stack Exchange und auf der man page des wpa_supplicant fündig geworden. An dieser Stelle sei die notwendige Konfiguration noch einmal zusammengefasst.

Ich nutze einen USB-WLAN-Adapter von CLS mit externer Antenne; intern ist das ein RTL8191SU 802.11n WLAN Adapter,der direkt unterstützt wird.

In /etc/network/interfaces wird für das WLAN-Device (wlan0) folgendes angefügt:

Der Eintrag in /etc/wpa_supplicant/wpa_supplicant.conf sieht dann so aus:

Durch den Eintrag key_mgmt=NONE , der  meist verschwiegen wird, stellt der wpa_supplicant keine verschlüsselte Verbindung her, sondern nutzt das WLAN unverschlüsselt, wie es für Freifunk notwendig ist. In einem anderen Freifunk-Netzwerk muss natürlich die ESSID angepasst werden.

Nach einem Neustart verbindet der Raspberry Pi sich nun automatisch mit dem Freifunk-Netzwerk, sofern es erreichbar ist.

  1. zum Beispiel einem Freifunk-WLAN []

Nicht mehr mein Betriebssystem

Gerade eben, Büro: Build-Umgebung für Mikrocontroller auf Embedded Device angeworfen. Dort holt ein selbst geschriebenes Perl-Skript die Versionsinformationen aus dem Mercurial und erzeugt daraus eine Datei version.h, die beim Build eingebunden ist, so dass eine Versionsnummer im fertigen Binary landet. Automatisch. Ging immer. Eben nicht.

Es hat mich eine halbe Stunde gekostet rauszufinden, dass nicht mehr wie üblich das von mir installierte Strawberry Perl aufgerufen wird, sondern ein von MinGW mitgeliefertes, dem (mindestens) ein Modul fehlt, welches in meinem Skript genutzt wird.

Abhilfe schaffte die Umsortierung der Einträge in einer der Variablen %PATH% in den Umgebungsvariablen, damit mein Perl vor dem von MinGW gefunden wird. Dass das zusätzliche Perl übrigens bei MinGW dabei war und nicht in einem der anderen Pfade versteckt war, war übrigens nur gut geraten. Vermutlich gibt es noch mehr Perl-Instanzen, die irgendwelche Software hier mitgebracht hat. Unter Windows muss ja jeder immer wieder extra seinen eigenen Scheiß mitbringen.

Mal sehen, an wieviel anderen Stellen das später knallt. Wer den entsprechenden Dialog in Windows XP sofort findet und bei der (unter Entwicklern) üblichen Anzahl von zweistelligen Einträgen auch noch ohne Copy’n’Paste in externen Editor bearbeitet, werfe den ersten Stein.

Bei Linux gibt es ein Perl und in $PATH stehen maximal 5 Ordner.

Links klicken in Icedove Mail

Debian Stable und aktuell Wheezy ist das System, was ich auf meinen Rechnern benutze und die Thunderbird-Variante Icedove ist da auf Version 17.x und damit gibt es ein Problem: Icedove hält sich so gar nicht an eine der üblichen Varianten um einzurichten welche Anwendung sich öffnen soll, wenn man einen Link anklickt, nicht an die KDE-Mechanisem (eigentlich logisch), nicht an die vom System und nicht mal an seine eigenen. Konkret muss man über preferences → advanced → general → config editor an die Innereien ran. In den Optionen network.protocol-handler.app.http[s] steht hier x-www-browser was üblicherweise ein symbolischer Link ist, der auf /etc/alternatives/x-www-browser zeigt und das bedeutet auf Debian-basierten Systemen, dass man das über

einstellen kann. Bei mir steht das auf iceweasel, aber Icedove öffnete alle Links mit Google Chrome. :-(

Ich hatte das vor längerer Zeit mal auf der deutschen Debian User Mailingsliste gefragt, aber die passende Antwort da im Archiv zu finden, ist umständlich und ich stand jetzt auf einem anderen Rechner vor dem selben Problem und hab’s ohne im Archiv zu suchen dann genauso gemacht:

hab ich dann auf true gesetzt und bekam dann einen Auswahldialog. Was ich da auswähle taucht dann in den Preferences unter attachments → incoming auf, wo es vorher jedoch nicht stand. WTF?!

Also ganz ehrlich, egal wer sich das ausgedacht hat bei den Entwicklern, den würde ich gern mal persönlich sprechen! *motz*

Wuff what?

Beruflich habe ich mittlerweile auch mit Linux zu tun und hier in der Firma setzen wir unter anderem ptxdist ein. Wenn man dort screen installiert und die /etc/screenrc von ptxdist installiert, erwartet einen eine lustige Überraschung, wenn die Visual Bell ausgelöst wird. Auszug aus der zuvor genannten Datei:

Also manchmal …

Farben im Midnight Commander von Ubuntu 10.04 Lucid

Wir setzen im Büro Ubuntu 10.04 Lucid auf mehreren virtuellen Maschinen ein. Als Konsolenjunkie ist da selbstverständlich auch der Midnight Commander installiert. Leider krankt das entsprechende Ubuntu-Paket in der Version daran, dass Dateien und Verzeichnisse nicht unterschiedlich farbig dargestellt werden. Im Launchpad gibt es auch einen Bugreport dazu, wo eine mögliche Lösung des Problems angedeutet ist. Einfach die Datei filehighlight.ini ins Verzeichnis /etc/mc kopieren. Nur wo bekommt man die Datei her so auf die schnelle und woher nur die eine und nicht gleich die ganzen Quellen? Ich hab mich dazu im Source Browser auf midnight-commander.org bedient: root/misc/filehighlight.ini – dort ganz unten gibt’s nen Link »Original Format«, wo man die aktuelle Datei aus dem Versionsverwaltungssystem bekommt. Beispiel, um die zu installieren:

Midnight Commander neu starten, freuen.