Tag Archives: HowTo

Running EAGLE 9.6 on Debian 10 (buster)

For some side project I wanted to look at the schematics of the Adafruit PowerBoost 500C, which happened to be made with Autodesk EAGLE.

Having run EAGLE on Debian 9 (stretch) for a while now without great hassle, I did not expect much difficulties, I was wrong. First I downloaded the tarball from their download site. Don’t worry, there’s still the “free” version for hobbyists, however it’s not Free Software, but precompiled binaries for amd64 architecture, better than nothing.

After extracting, I tried to start it like this and got the first error:

There’s no verbose or debug option. And according to the comments on the blog post “How to Install Autodesk EAGLE On Windows, Mac and Linux” the problem also affects other users. I vaguely remembered somewhere deep in the back of my head, I already had this problem some time ago on another machine, and tried something not obvious at all. My system locale is German, looked like this before:

As you can see, no English locale, so I added one. On Debian you do it like this. Result below:

This seems like a typical “works on my machine” problem from an US developer, huh? Next try starting eagle, you’ll see the locale problem is gone, the next error appears:

That’s the problem if you don’t build from source against the libraries of the system. In that case EAGLE ships a shared object libxcb-dri3.so.0, which itself is linked against the libxcb.so.1 from my host system, and those don’t play well together. I found a solution to that in a forum thread “Can’t run EAGLE on Debian 10 (testing)” and it is using the ld_preload trick:

This works. Hallelujah.

Wireshark USB capture setup with groups and udev

Wireshark does not only capture network traffic, but also different things like USB traffic. I needed that today and it needs some additional setup on Linux. There’s something in the Wireshark wiki on that topic, but I consider that not an elegant solution: USB capture setup.

The solution I use is basically one proposed on stackoverflow and uses a separate Linux system group and udev: usbmon (wireshark, tshark) for regular user.

On Debian you can do this:

You have to log off and on again, check if you are in that group with the command id.

Now create a new file /etc/udev/rules.d/75-usbmon.rules and put this into it:

After doing modprobe usbmon your devices /dev/usbmon* should belong to the new usbmon group and you can start capturing things with Wireshark.

HowTo: Debug core dumps with ptxdist 2017.07.0

Debugging for embedded projects is a little harder than for your own computer. In many cases you can not run gdb on the target, and even if you can use gdbserver1 this does not cover all use cases. For post mortem analysis (e.g. after a segmentation fault of your program) you want to examine so called core dumps. Given you successfully found out how to let your target create those2, copied it to your workstation and unpacked it, you still need to know how to analyze it.

With the release of ptxdist 2017.07.0 the handling of debug information changed. Quoting from the release announcement:

The debug symbol handling was reworked. The debug files are now named based
on build-ids and (optional) debug IPKGs can be created. They are not
installed by default but can be installed manually as needed. This is
useful to gdb on the target or with valgrind and perf.

In my BSP those debug info is put to /usr/lib/debug in the root folder from which the target files are copied. This looks like this now:

You can imagine it is not possible anymore to load this manually, the debugger will have to find out by itself. Getting this to work caused me some headaches, but this it how I got it work: Create a file ‘gdb-config’ with the following content:3

Note: the order of the commands is important, it does not work the other way round!

Then load your core dump:

So you run the gdb from your toolchain, load the previously crafted file with gdb commands with -x, give the path to your executable with -e and finally the core dump file with -c and that’s it. You may now have a look at a backtrace and find out what caused the segfault …

Update: I was pointed to an easier possibility to invoke the right gdb with the necessary options in #ptxdist IRC channel (on freenode). The previous call would be like this:

No need to pick the correct gdb and find and configure the right directories, just add the path to your tool and your core file, ptxdist handles everything else. I bet this would also work with older ptxdist versions, where the debug symbols where placed somewhere else, but didn’t try it. This however was also just added with ptxdist 2017.07.0:

There is also a new ptxdist command ‘gdb’ for remote debugging that sets up
the sysroot correctly and a wrapper script that can be used by graphical
development environments.

  1. we already had this topic here: KDevelop: Debuggen von Programmen, die root-Rechte benötigen (German) []
  2. this would be content for another post []
  3. of course you adapt the paths to the ones you use on your machine []

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!

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 []

HowTo: ownCloud mit lighttpd auf Debian Jessie

Der Fortschritt macht nicht halt und dass jemand™ sich jetzt ein Fairphone mit Android drauf gekauft hat, war eine willkommene Gelegenheit sich mal eine eigene ownCloud-Instanz aufzusetzen. Debian Jessie ist zwar derzeit noch »testing« aber schon ganz gut nutzbar und da es dort fertige Pakete für ownCloud 7 gibt und eine passende VM auf dem Server zu Haus bereits lief, fiel die Wahl darauf. Ein lighttpd mit PHP lief auch schon und der Rest war auch so schwer nicht.

Im derzeitigen Stand des Paktes muss man die Datenbank für ownCloud noch selbst anlegen. Ich hab das mit phpmyadmin gemacht, wo das Debian-Paket sich selbst schon einfach in lighttpd integriert. Die Zugangsdaten gibt man später beim Einrichtungswizard vom ownCloud an.

Im ownCloud Paket ist eine Möglichkeit dokumentiert, das Paket mit lighttdp zu nutzen, die automatische Integration wie bspw. bei phpmyadmin gibt es so nicht. Der falsch vorgeschlagene Pfad in der Doku, wurde von mir gemeldet und ich hab noch ein paar Dinge ergänzt:

Der untere Teil ist aus dem Vorschlag vom Paket übernommen, nur der alias-Pfad korrigiert. Der obere Teil ist für den direkten Zugriff über eine andere Subdomain statt über den hostname des Servers und einen Unterordner. An sich steht da aber das gleiche drin. Besonderes Augenmerk sei noch auf die redirects für die sogenannten well-known URLs nach RFC 5785 gelegt, die den Zugriff mit bestimmten Kalenderprogrammen deutlich vereinfachen.

Nachtrag: Dieses Mini-HowTo unterschlägt die Einrichtung von verschlüsseltem Zugriff über HTTPS. Ich habe das weggelassen, weil es a) an anderer Stelle gut beschrieben ist und b) ich hier noch einen nginx als Reverse Proxy vor dem lighty habe, der mit diesem HowTo rein gar nichts zu tun hat. ;-)

JavaMail and TLS: Turn on the security switch!

While talking to Ge0rg about latest issues in Java TLS we stumbled upon the question whether the JavaMail API would have similar problems.

Naturally one would expect that Java’s SSL implementation is secure. However, this is not the case: Special care needs to be taken regarding Man-In-The-Middle attacks: While a certificate may turn out to be valid, you cannot be sure that it has the right origin!

The problem is known for a while and library maintainers are taking steps to avoid it. However, for compatibility reasons those features may need to be turned on.

For JavaMail version 1.5.2 the SSLNOTES.TXT says specifically:

— Server Identity

Check RFC 2595 specifies addition checks that must be performed on the server’s certificate to ensure that the server you connected to is the server you intended to connect to. This reduces the risk of “man in the middle” attacks. For compatibility with earlier releases of JavaMail, these additional checks are disabled by default. We strongly recommend that you enable these checks when using SSL. To enable these checks, set the “mail..ssl.checkserveridentity” property to “true”.

Here is the thing that most examples forget: You need to switch that feature on!

To use SSL at all, you need to turn it on, either by specifying “imaps” in the property mail.store.protocol or by setting mail.imap.starttls.enable to “true”. Replace imap respectively for other protocol suites (e.g. smtp).

Update 2014-08-05: Inserted the Link to Georg’s blog post about latest issues in Java TLS.

HowTo: gitolite auf Debian Wheezy

Das Netz ist natürlich voll von HowTos zum Thema gitolite, in diesem hier nutze ich aber nicht die bleeding edge Version von upstream sondern das Debian-Paket. Eine gewisse Hilfe für’s Verständnis und bei der Installation war die Dokumentation für gitolite 2.x, denn in Wheezy ist Version 2.3 verpackt.

Installation

Geht los mit Installation des Pakets gitolite. Wenn der bei der Installation dpkg nichts konfiguriert haben will, dann gibt man danach nochmal ein:

Dort wird dann ein SSH public key abgefragt für den Admin-Nutzer. In meinem Fall hab ich hier für die Testinstallation auf dem selben Rechner den folgenden Pfad angegeben, ansonsten kopiert man seinen public key ins Eingabefeld:

Damit liegt jetzt hier unterhalb von /var/lib/gitolite1 folgendes:

Da mein public key bereits hinterlegt ist, kann ich direkt zum nächsten Schritt übergehen und das Admin-Repo clonen, welches bei der Installation angelegt wurde:

Wie man sieht, hatte ich den dedizierten Nutzer gitolite genannt, für Produktionsumgebung ist vielleicht git eine bessere Wahl.

Ganz wichtig: beim Ändern der Config muss man stets drauf achten, dass man sich nicht selbst aussperrt. Für das Repository gitolite-admin muss man Schreibrechte für irgendeinen Key behalten, auf den man auch Zugriff hat und der unterhalb von keydir im Repo liegt, sonst hat man keine Möglichkeit mehr ohne große Schmerzen diese Rechte wiederzuerlangen.

Konfiguration

Als nächstes habe ich die Datei /var/lib/gitolite/.gitolite.rc angepasst. Berücksichtigt sind hier bereits, dass ich sowohl git-daemon als auch gitweb einsetzen und die Repos auf einen anderen Rechner spiegeln will. D.h. ich habe folgende Einträge geändert:

Der letzten Zeile ist erhöhte Beachtung zu schenken. Die bereits angelegten Repositories gitolite-admin und testing aus /var/lib/gitolite/repositories müssen nämlich in den geänderten Pfad verschoben werden.2 Damit der Zugriff über gitweb funktioniert, habe ich den Nutzer www-data der Gruppe git hinzugefügt und die Rechte des Repository-Verzeichnisses gelockert:3

Die eigentliche Konfiguration erfolgt dann wie bei gitolite üblich über das admin-Repository nachdem man es geklont hat:

Wie man das im Einzelnen macht, kann man in der Doku zu gitolite v2 nachlesen. Das ist nicht Debian-spezifisch.

gitweb mit lighttpd

Für einen schnellen Überblick mit dem Webbrowser ist das Paket gitweb installiert. Als Webserver kann vermutlich irgendein Webserver dienen. Für lighttpd habe ich eine Datei /etc/lighttpd/conf-available/80-gitweb.conf angelegt und mit den für diesen Browser üblichen Mechanismen aktiviert. Der Inhalt sieht so aus:4

Es ist außerdem das Modul 10-cgi.conf zu aktivieren:

In der /etc/gitweb.conf sind auch noch Anpassungen zu tätigen. Hier meine geänderten Zeilen:

Urspünglich war jetzt hier noch eine Beschreibung zum Mirroring, ich verschiebe das auf später und tu es in einen separaten Artikel … O:-)

  1. auch den Pfad kann man beim dpkg-reconfigure angeben. []
  2. Dieser Schritt kann natürlich entfallen, wenn man die Repositories im Standard-Pfad belässt. []
  3. Die Rechte der bei der Installation angelegten Repositories sind allerdings immernoch so restriktiv, dass sie nicht über gitweb angezeigt werden können. Bei <code>gitolite-admin</code> will man das sowieso nicht und statt <code>testing</code> legt man sich vielleicht ein weiteres Testrepository an, um zu sehen, ob das mit den Rechten beim neu anlegen richtig klappt. []
  4. Siehe auch gitweb im ArchWiki. []

Port based VLAN mit Netgear GS108Tv2

Wir bauen im Netz39 gerade das Netzwerk ein bisschen um und wollen dabei auch mehrere logisch getrennte Netze einrichten. Die Routerhardware hat genau zwei Netzwerkkarten und kann nicht mehr bekommen, aber der Switch kann VLAN. D.h. was ich prinzipiell gern aufbauen möchte, ist etwa folgendes:

vlan

VLAN auf dem Router konfigurieren ist mit fli4l kein Problem, aber der Switch in meinem Testsetup1 hat mich grübeln lassen. So ging es dann. Erstmal die VLANs unter VLAN Configuration anlegen, hier mit den IDs 11 und 22:

netgear_vlan_1

Dann kommt sozusagen die Einrichtung des ausgehenden Verkehrs unter VLAN Membership. Hier wollen wir den Netzwerkverkehr aus den VLANs 11 und 22 beide auf dem Port zum Router haben und dort sollen die Tags drin bleiben, damit der Router das auch wieder aufdröseln kann. Deswegen wird Port 2 am Switch für beide VLANs mit T markiert, damit der Verkehr auf dem Port getaggt wird.2 Bisschen umständlich ist es, dass man jedes VLAN einzeln auswählen und dann unten noch die Liste mit den Ports aufklappen und alles einzeln bestätigen muss.3 Für den Netzwerkverkehr zu unseren dummen Geräten, die kein VLAN können oder davon nichts wissen sollen, lassen wir den Switch die Tags entfernen, markieren also die Ports 6 bis 8 mit U wie untag, was aber dennoch heißt, dass der Verkehr aus diesen VLANs über diese Ports rausgeht. Das sieht dann hier so aus:

netgear_vlan_2

… und …

netgear_vlan_3

Jetzt müssen wir uns noch um den eingehenden Verkehr kümmern, also das was ohne VLAN-Tag in den Switch gelangt. Dazu geht man auf Port PVID Configuration und kann dort dann einem Port genau ein VLAN zuordnen:

netgear_vlan_4

Ich hoffe, ich hab das alles richtig verstanden und keinen Quatscht jetzt hier erzählt. Es scheint aber zu funktionieren.

Update: Wenn man sich die PVID-Konfiguration nochmal ansieht, so wird Traffic auf den Ports 1 bis 5, der kein Tag hat, der VLAN-ID 1 zugewiesen. Da per default auf allen Ports U aka untag für die ID gesetzt ist, verlässt also ungetagter Verkehr von allen Ports den Switch auf allen Ports wieder. Was man jetzt vermutlich will: auf den Ports 6 bis 8 das U bei VLAN-ID noch rausnehmen, damit da wirklich nur Traffic des jeweiligen VLANs ankommt, und nicht noch der andere Traffic auch noch.

  1. welches leider nicht der Switch ist, der später auch Verwendung finden wird. []
  2. Das was wir hier mit Port 2 gemacht haben, also Tags von verschiedenen VLANs in den Paketen belassen, wird an einigen Stellen im Netz als VLAN-trunk bezeichnet. []
  3. Wegen so dämlichem UI gibt es solche HowTos … []

Wireshark als normaler Nutzer ausführen

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.