Jailing the Zoom Client

While there are many Open Source solutions for browser-based videoconferencing and online meetings, like BigBlueButton or Jitsi, I am still forced to use zoom in a lot of contexts.

But the zoom web client lacks a lot of functionality and generally does not work well in my experience.

On the other hand I absolutely distrust the zoom client. Just inspect the strings that appear in the binary of the launcher…

$ strings /opt/zoom/ZoomLauncher | grep grep
pacmd list-sinks |grep 'name:\|module:'

Yes, they are using a lot of shell commands in their compiled binaries.

Firejail to the rescue!

In short, Firejail is a wrapper that allows to limit what a process is allowed to to with regards not only to the filesystem but also all other aspects of your system.

A profile is used to define the permissions and view on the filesystem, then the binary is called via the Firejail wrapper.

This approach allows me to always use the latest published version of the client, provided as .deb by zoom and install it directly on my system. Which makes updating really easy.


I created two directories in my home, zoom.back and zoom.data to store Images to use for virtual backgrounds in the first and to store recordings or files downloaded via zoom client in the other.

The Profile

You probably have to tune the profile file below, according to your needs, with regards to filesystem access and mounted directories. It can probably be improved additionally but below profile works for me.

include /etc/firejail/disable-common.inc 
include /etc/firejail/disable-passwdmgr.inc

include /etc/firejail/disable-interpreters.inc
include /etc/firejail/disable-xdg.inc
include /etc/firejail/disable-exec.inc
include /etc/firejail/disable-devel.inc


read-only ~/

whitelist ~/zoom.back
read-write ~/zoom.back

whitelist ~/zoom.data
read-write ~/zoom.data

whitelist ~/.zoom
read-write ~/.zoom

whitelist ~/.config/zoomus.conf
read-write ~/.config/zoomus.conf

private-etc group,hostname,passwd,profilem,bash.bashrc,fonts
blacklist /mnt
blacklist /data
blacklist /media
protocol inet,inet6,netlink,unix
caps.drop all
# needed by zoom: memory-deny-write-execute
shell none
dbus-user none
dbus-system none

My startup script

As a bonus I am checking if my camera is attached and enable the microphone profile on my headset before starting zoom. The important line is the last command, make sure when copy pasting to have no trailing whitespace after the backslashes.


# switch the audio profile of my headset
~/bin/headset meeting

# check if my external camera is attached, as
# firejail will only show devices already present

lsusb -d 046d:0825
if [ ! "$?" -eq 0 ]; then
  # wait until ok is pressed
  xmessage "Turn on camera!"

# call zoom in the jail, write a trace file to inspect
# afterwards if it crashed or throws errors

firejail --trace=~/.zoomtrace \
    --profile=~/.firejail-zoom-profile \
    /usr/bin/zoom $@

The Result

The zoom client and all it’s client processes should now not be able to access your home directory or drop files somewhere etc. With that I am somewhat less concerned running that binary on my user account on my main working machine.

Below you see how the dialog to choose a virtual background looks like with that profile.

Software Versions

I am currently running Debian 11.1 and the deb-package versions are zoom, and for firejail and firejail-profiles.





Veröffentlicht unter de, debian, Desktop, IT, Linux, security | Kommentare deaktiviert für Jailing the Zoom Client

Personal Review of Jabra Evolve2 85 and Jabra Link 380

I kept on rambling about my headset and got asked for my personal impressions, I thought this could be reason enough to write a short personal review for my blog. So here it is.

Note that this is my personal view and my personal experience using these devices with Pulseaudio on a Debian/Linux machine, your experience may vary a lot.

The headset is currently using firmware 2.3.8 and the USB Dongle, a Jabra Link 380, is using firmware 1.10.9, both are the latest available at this point.

In general I am happy with the Quality of the Headset and especially with the Jabra Support. I had some questions regarding the SDK they provide and they replied very quickly. However, given the price of these devices I am not completely satisfied with some of the annoyances that I experienced over the last weeks that I am using the device on a daily base for listening to music, watching online Videos, e.g. tutorials, and joining online meetings.

Let’s first take a look at the features of the device.

The headsets comes with a USB-A to USB-C cable and, in contrast to statements in the manual, will not only charge via USB but also be recognized as USB sound card using the cable.

The battery capacity is high enough for me to listen to music the whole day, recharging is fast and it can be charged while in use via Bluetooth as well.

The headset also features ANC, but that’s already one of the parts I am not completely happy with. When enabling ANC I notice a noise floor, that increases and decreases slowly (within 1-2 seconds) depending on outside noise. It is loud enough for me to be heard even with silent music playing. This is quiet (sic) different from the Bose QC that I used before.

A nice feature however is, that I can pair the headset with two devices at once, so I can keep it connected to my mobile phone to change settings, while using it with my PC.
But this also can lead to confusion and frustration. It is not always clear to me, to which device button presses are sent. Sometimes pressing play starts the music on my mobile phone, sometimes it starts the music playing on my PC. Sometimes pressing the center button on the right earpiece enables the Busy light, sometimes the phone starts talking in the bedroom and explains, somewhat loudly, at night, that I need to add some permissions to the Jabra App to enable voice commands.

You may also want to double check if an incoming call on your phone in DNT mode will disconnect you from a running online meeting with your colleagues, while speaking.

Speaking of audio, here comes one of the biggest disappointment, but it is a general issue with two-way audio via Bluetooth.
I made the naïve assumption, that when using the headset together with the provided USB dongle, the audio quality in meetings would be the same as when listening to music for me and comparable to a regular microphone for the other participants when I am speaking. This is sadly not the case.

By using the Jabra Link USB-Interface, which is presenting itself as an USB sound card to the host, I don’t have to rely on the BT stack of my Operating System, but the sound quality still is drastically reduced whenever I switch the profile to enable the microphone. Which is the next annoyance.

I usually have to manually switch my audio profile to the Low Quality two-way mode (which still is a lot better than the regular codec using the Linux BT-Audio stack) because especially my browser does not detect the microphone otherwise.

But then people tell my that the microphone in my Webcam sounds better than the Jabra headset. Sad.

While we are at it, the next annoyance, which could be related to Pulseaudio, is that when I by accident switch the USB-adapter to the Bluetooth profile with AC3, I will start to hear very loud buzzing noises from the headphones and its completely unusable.

I wrote myself a rough shell script to quickly switch between profiles, you can find it below, so I will not by accident choose the wrong one again.

But the issue that annoyed me the most recently is the fact that the Jabra Link USB dongle will automatically disable the audio-link to the device, depending on the sound level it sees.

This means that for example when watching a tutorial where the host is pausing the voice track for more than 2 seconds, I will lose the next 3-4 seconds of content, as the dongle turns off the audio link after 2 seconds of ’silence‘, then takes a short period of time to re-activate it and then the headsets starts to slowly fade in again.

I found two ways of working around it: constantly play a sine wave that is quiet enough so I can not hear it while being loud enough for the Jabra Link to stay enabled or use the SDK and manually enable the audio link permanently. (It is not a Pulse Issue, I checked.) I opened a ticket with Jabra, lets see.

Unfortunately this also means that you will not be able to hear any sound notifications from your phone or PC when not already listening to music, as the ‚ding‘ will already be over until the headset has completely faded it.

However, this is of course not the case when the headset wants to inform you at 3 a.m. while coding and listening to some light background music that the BATTERY IS LOW – PLEASE CHARGE. At least I was awake then.

Speaking of Jabra and after I already mentioned the ‚SDK‘ – let’s talk about that.

Jabra is providing SDKs for various operating systems, including Linux, specifically they support Ubuntu and just released a new version of the SDK. However keep in mind, that the ‚SDK‘ is a pre-compiled closed-source .so file that needs to be linked with your software and itself is linked with a LOT of external dependencies in your system:

…/64-bit$ ldd libjabra.so. 
	linux-vdso.so.1 (0x00007fffad5da000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007fd2e30fe000)
	libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007fd2e30d6000)
	libssl.so.1.0.0 => not found
	libcrypto.so.1.0.0 => not found
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd2e30b9000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd2e2eec000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd2e2da6000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd2e2d8c000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd2e2bc7000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd2e2bc1000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd2e2b9f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fd2e3686000)

I was unable to use the previous SDK, as it was linked against an old openssl library (see above), and opened a ticket with Jabra. They responded quickly and helpful and indeed already prepared a new release. They also told me, that the new version is not depending on openssl any more as they are now using libcurl. Well, take a look below to learn what that means – I will not comment any further on that here – but I don’t see a future-proof way of controlling the device from my desktop, e.g., switching audio profiles, ANC, enabling the busy-light and so on.

.../64-bit$ ldd libjabra.so. 
	linux-vdso.so.1 (0x00007ffeb01fd000)
	libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f0f7602b000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f0f75f2e000)
	libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007f0f75f06000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0f75d39000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0f75bf5000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0f75bdb000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0f75a14000)
	libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f0f759e7000)
	libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f0f759c6000)
	librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f0f759a7000)
	libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007f0f75972000)
	libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f0f7595e000)
	libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f0f758c9000)
	libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f0f755d5000)
	libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f0f75582000)
	libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f0f7552c000)
	liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f0f7551b000)
	libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f0f7550d000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0f754ee000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0f754cc000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0f754c6000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f0f76552000)
	libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f0f75344000)
	libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f0f75145000)
	libhogweed.so.6 => /usr/lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007f0f750fa000)
	libnettle.so.8 => /usr/lib/x86_64-linux-gnu/libnettle.so.8 (0x00007f0f750b2000)
	libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f0f75031000)
	libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f0f74f11000)
	libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f0f74e37000)
	libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f0f74e07000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f0f74dff000)
	libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f0f74df0000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f0f74dd6000)
	libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f0f74db9000)
	libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f0f74d96000)
	libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f0f74c60000)
	libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f0f74c4a000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f0f74c24000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f0f74c1d000)
	libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007f0f74c11000)

I really wished to be able to control the Busy light manually, to indicate if I don’t want to be disturbed – while one should be able to use the center button for that, I have not completely understood when the button is controlling the Busy light, when it is starting a voice command on my mobile phone and when it’s just doing nothing.

To wrap up let’s look at some other minor details. One of the comfort features of the device is, that it detects when you wear it. Whenever you take the headset off (of left ear) it will detect that, pause your music and restart it when you put it back on. In a meeting it will mute the microphone, so you will not by accident broadcast your home or office chatter.

Nice feature, if it would work reliably. The first issue is the on-ear detection that suddenly stopped working reliably. I am unable to find any information how it works, only that you should make sure to remove long hair from between the headset cushions and your head/ear. However, the effect was me being suddenly muted in a meeting and music randomly pausing.

Speaking of pausing, the device is sending the pause-event, which unfortunately seems to mean that when I take the headset off my head or turning it off can also start the music on my desktop when I stopped manually before.

Finally I suggest you to try out the device if it fits your head-contours. It seems I have one point at the top of my skull where most of the devices weight is pushing which can make it uncomfortable to wear after some time.
My DT 770 here use a band that sits flush around your head, while the Jabra headset uses a cushion which does not distribute the pressure evenly.

Also moving my head or the headset often results in noise coming from the plastic joints, which is really unexpected looking at the price tag.

And here is the script to quickly switch profiles:


if [ "$1" == "meeting" ]; then

card="$(pacmd list-cards  | sed -n 's/^.*name: <\(.*Jabra_Link_380.*\)>/\1/gp')"

pactl set-card-profile "$card"  "$profile"
Veröffentlicht unter debian, en, rant, sound, Technik | Kommentare deaktiviert für Personal Review of Jabra Evolve2 85 and Jabra Link 380


Der letzte Beitrag ist schon eine Weile her, in sofern könnte man diesen Artikel hier auch als eine Art RESET bezeichnen, aber eigentlich soll es darum gehen, wie man bei einem APU-Board einen RESET auf sichere Art und Weise mit einem externen Gerät (zum Beispiel RaspberryPi) auslösen kann, ohne das APU-Board oder andere Komponenten zu gefährden, ohne zufällige Resets zu befürchten und ohne festzustellen, dass der Reset nicht geklappt hat, weil ein Kabel falsch steckt.

Warum das ganze? Bei Freifunk Hochstift  möchte man im Rahmen des Out-Of-Band Managements verschiedene APU-Modelle von einem RaspberryPi aus rebooten können. Da die APU sich bei Einschalten der Stromversorgung automatisch einschalten, muss also nur der RESET-Taster automatisiert werden.

Details dazu gibt’s im Vortrag „Out-of-Band-Management für APU-Boards“ beim FreifunkTag19 – Link folgt.


Ich schlage letztlich vor mit möglichst kurzen Kabeln den Reset-Pin und Masse der APU mit einem Relais zu verbinden und darüber den Reset auszulösen, auch wenn es elegantere Lösungen gibt. Warum will ich im Folgenden etwas ausschweifend beantworten. Das ist keine vollständige Einführung in Schaltungsdesign und sicher auch nicht 100% exakt. Hauptaugenmerk liegt auf einer einfachen Erklärung.

Reset und Power-good – was ist das eigentlich?

Das klingt ja erst mal nach einer einfach zu beantwortenden Frage, aber bei genauerer Betrachtung gibt es hier einen Unterschied, der sich auch im Layout der APU-Boards finden lässt, aber dazu später mehr.

Fangen wir mit dem Reset-Signal an. Oder vielmehr damit, was ein Signal eigentlich ist. Mit einem Signal meine ich letztlich nichts weiter als eine „Leiterbahn“ auf der entweder ein HIGH- oder ein LOW-Pegel anliegt. LOW bedeutet, dass das Signal gegenüber GND (idealisiert) eine Spannung von 0V aufweist, HIGH bedeutet, dass eine (positive) Spannung oberhalb eines definierten Pegels anliegt. Vereinfacht: Der Pin wird mittels Widerstand mit Masse oder der Versorgungsspannung verbunden. Mehr dazu siehe: Logikpegel.

Das Reset-Signal dient wenig überraschend dazu, den Prozessor und ggf. weitere Peripherie wie USB-Interface, PCI-Karten, etc. in einen definierten Zustand zu versetzen. Bei einer CPU würde dies bedeuten, dass alle Register gelöscht und der Programmcounter auf die Startadresse, üblicherweise auch 0, gesetzt wird. Der Reset tut also was man erwartet: Alles beginnt bei 0, es ist tatsächlich wie nach dem Einschalten des Systems, weil beim Einschalten genau das passiert: Üblicherweise wird beim Einschalten der Spannungsversorgung der RESET-Pin oder das RESET-Signal für eine bestimmte Zeit „aktiv“ geschaltet. Aber Achtung – beim RESET# handelt es sich in aller Regel um ein active-low Signal! Das bedeutet, dass es aktiv ist, wenn es LOW ist (ach!) – ein Reset wird also ausgelöst, wenn der Pin ‚auf Masse gezogen‘ ist, also mit GND verbunden wird. In Schaltplänen und Datenblättern wird dies meistens durch einen Strich über dem Namen des Signals kenntlich gemacht, bei den APU-Boards hat man sich für eine Raute (#) hinter dem Namen des Signals entschieden.

Das Power-good-Signal ist hauptsächlich bei der Initialisierung eines Systems, also beim Einschalten der Spannungsversorgung von großer Bedeutung. In der Regel sind auf einer Systemplatine verschiedene Komponenten vorhanden, die unterschiedliche Versorgungsspannungen benötigen. Typische Spannungen sind 1.8V, 3.3V, 5V, etc.. Diese Spannungen stehen aber nicht direkt mit dem Einschalten zur Verfügung, im einfachsten Fall kann man sich das so vorstellen, dass erst verschiedene Kondensatoren geladen sein müssen, bis die Spannungsregler funktionieren und eine stabile Ausgangsspannung zur Verfügung stellen können. Es ist auch keine Seltenheit, dass eine 1.8V Spannung aus den 3.3V abgeleitet wird, also zunächst der 3.3V Rail stabil sein muss.  Man muss kein Experte sein um festzustellen, dass in dieser Phase das System noch nicht benutzbar ist.

Das Power-good Signal kann auch benutzt werden, um das System anzuhalten oder zurückzusetzen, wenn die Betriebsspannung unter eine kritische Marke fällt.


Was passiert also beim Einschalten? Nun, RESET# wird auf Masse gehalten bis die Spannungsversorgung stabil und das Power-good Signal aktiv ist. Man erkennt: beide Signale lassen sich prinzipiell zusammenlegen, weil beide zunächst auf LOW liegen und nach einer kurzen Zeit HIGH gehen sollen. Die APU1 tut auch genau das.

Im einfachsten Fall kann dies über einen Kondensator erfolgen, der über einen kleinen Widerstand aufgeladen wird. Ein Problem kann hier schnelles Aus- und Wiedereinschalten sein – da der Kondensator dann noch geladen ist und kein RESET erfolgt. Wer dazu mehr wissen will sucht nach Schmitt-Trigger und schaut sich die Ladekurve eines Kondensators an.

In der Praxis überlässt man das daher meistens einem designierten Chip, der die Spannungsversorgung überwacht und ein Reset verlässlich auslöst, auch wenn die Spannungsversorgung nur kurz unterbrochen wird oder es zu einem Absinken (Brown-out) der Betriebsspannung kommt. Einige CPUs, gerade im Embedded Bereich, haben Funktionen für den RESET aber auch eingebaut, ansonsten ist das die Aufgabe des Powermanagements.


APU-Board Designs

Im Folgenden betrachte ich jeweils Auszüge aus den Schaltplänen der APU1C/1D und APU2C/2D.

Hinweise zum Lesen: Die Schaltpläne sind auf mehrere Seiten verteilt, daher ist es üblich die Signalnamen zu annotieren und durch die Pfeilrichtung anzudeuten, ob es sich um ein eingehendes oder ausgehendes Signal handelt. Neben dem Signalnamen sind dann noch die Seiten im pdf angegeben, auf denen das Signal noch vorkommt.

APU 1 Reset schematic

APU1C Reset schematic

Man erkennt  im ersten Schaltplan (APU1C), dass der Reset-Button an einer 4×1 Pinleiste J2 auf Pin3 lieg. Der Reset soll wohl durch einen Taster erfolgen, der Pin3 und Pin4 verbindet.

Um zu verstehen was dabei passiert, muss man aber auch auf Seite 15 nachsehen. Das Signal ist nämlich nicht nur mit dem RESET# Eingang der CPU der APU verbunden, sondern auch mit dem Power-Good Kreis. Wir sehen, dass das Reset-Signal über die (doppelte) Diode D21 geleitet wird (Erinnerung: wird auf Masse gezogen!) und auf den Eingang des Schmitt-Triggers U39 läuft. Dazwischen ist ein 10kΩ Pull-Up Widerstand zu erkennen (R284). Dieser sorgt dafür, dass bei Vorhandensein einer Versorgungsspannung das PWRGD_FC Signal auf Versorgungsspannung gezogen wird. Gleichzeitig werden über die Dioden aber auch alle anderen verbundenen Signale auf etwa 3V gebracht, auch unsere SYSRST# Leitung. (Über der Diode fallen laut Datenblatt etwa 0.3V ab.)

Der Schmitt-Trigger (Wikipedia) U39 auf der rechten Seite sorgt dafür, dass aus dem Signal PWRGD_FC wieder ein sauberes Logiksignal PWRGD_FCH wird. Das ist wichtig, weil über die Dioden D2, D4 und D21 verschiedene Signale gemischt werden und zwischen 0.8V und 2V nicht definiert ist, ob es sich um HIGH oder LOW handelt. Siehe nochmal  Logikpegel zur Verdeutlichung, mehr dazu auch gleich nochmal.

Schauen wir also, was im Fall eines (manuellen) Resets passiert: Nehmen wir also an, Pin3 und Pin4 an J2 sind verbunden. Dann wird der Kondensator C162 über den 47Ω Widerstand R135 entladen. Dies löst unmittelbar einen Reset der CPU aus, da SYSRST# direkt am Prozessor anliegt. Über die Diode D21 wird außerdem das PWRGD_FC Signal auf Masse gezogen, das vorher von R284 über 10kΩ mit der Eingangsspannung V3A verbunden ist. Damit ist dann auch PWRGD_FCH auf LOW. Hinweis: Es können hier knapp 70mA durch den Taster fließen, bei 3.3V und 47Ω, wenn auch nur kurz!

Wird der Taster losgelassen, so lädt sich der Kondensator C162 über die Diode D21 und den 10kΩ Widerstand R284 wieder auf und sobald die Schwelle des Schmitt-Triggers erreicht ist wird auch PWRGD_FCH wieder HIGH und das Board startet. Der RESET# Eingang der CPU wird in der CPU auch auf einem Schmitt-Trigger enden, so dass die CPU dann auch wieder startet. Ein Problem kann dabei sein, dass auf Grund der Diode D21 die Spannung am SYSRST#-Pin um etwa 0.3V unter der Spannung am Schmitt-Trigger der Power-good Schaltung liegt. Es kann also eventuell sein, dass die CPU schon läuft, während Speicher und Co noch außer Gefecht sind.


APU 2 Reset schematic

APU2 Reset schematic


Ein Blick in den Schaltplan der APU2 Reihe zeigt nun witzigerweise, dass SYSRST# und SYS_PWRGD nicht mehr miteinander verbunden sind – es gibt einen nicht bestückten Widerstand R357. Der Taster ist immer noch über einen Kondensator nach Masse entprellt, aber der Widerstand wurde auf 150Ω erhöht. Das begrenzt den Entladestrom über den Taster auf etwa 23mA.

Falls mir jemand erklären kann, warum sie bei den neuen Boards eine Brownout-detection einbauen und mit dem PWRBTN# Eingang des SOC verbinden und nicht mir PWRGD oder SYSRST#, würde ich mich freuen.

Externer Reset

Kommen wir nun zum eigentlichen Thema des Blogposts. Ich hatte ja angedeutet, dass ich etwas ausholen werde.

Es gibt mehrere Rahmenbedingungen, die beachtet werden müssen. Zum einen der Logikpegel des Geräts, mit dem der Reset ausgelöst werden soll, aber auch Robustheit gegen Störungen und versehentliche Fehlbedienung und elektrische Sicherheit – man will ja nicht dass die APU in Rauch aufgeht.

Zunächst sollte man sich klar werden, dass man eine galvanische Trennung zwischen APU und dem auslösenden Gerät erreichen will. Nur wenn beide Geräte am selben Netzteil und idealerweise im selben Gehäuse untergebracht sind, würde ich darauf verzichten. Schon weil ein Defekt an einem Gerät nicht gleich das andere ins Jenseits befördern soll, auch Masseschleifen können Probleme verursachen.

Dann muss man schauen, welchen Logikpegel das auszulösende Gerät hat. Einige Arduino arbeiten mit 5V Pegeln auf den GPIO Pins, andere ebenso wie der RasperryPi mit 3.3V.

Und schließlich ist noch die Robustheit der Lösung zu bedenken. Wenn das Kabel an der APU verdreht wird oder ein neues APU-Modell auf den Markt kommt, sollte die Lösung immer noch funktionieren. Und das ist letztlich der Hauptgrund, warum ich die Lösung mit einem Relais vorgeschlagen habe. Das Relais verhält sich gegenüber der APU wie ein Taster, es ist verpolungssicher, man bekommt es sehr günstig fertig aufgebaut mit einem 3.3V oder 5V Eingang und man kann es leicht erweitern für mehrere APUs oder um den Power-Button ebenfalls zu steuern.

Im Detail

Welche Möglichkeiten gibt es nun also, einen Reset extern auszulösen, also den RESET Pin auf Masse zu ziehen?

  1. MOSFET oder Bipolar Transistor
  2. Optokoppler
  3. Relais
  4. Taster der durch ein Servo betätigt wird (nur der Vollständigkeit halber)


Eine mögliche Schaltung ist ein bipolarer npn-Transistor, bei dem der Kollektor an den RESET-Pin und der Emitter an GND angeschlossen wird. Über einen Widerstand wird der Strom in die Basis begrenzt und je nach Logikpegel und Transistortyp muss dieser berechnet werden. Nachteile sind: der Eingang ist empfindlich gegen statische Aufladung, man sollte ihn also mit einem Kondensator und Pulldown Widerstand sichern, um nicht versehentlich einen Reset auszulösen. Verwendet man einen MOSFET ist dies noch kritischer, da hier keine Ströme ins Gate fließen müssen um zu schalten.

Nachteile sind außerdem die fehlende galvanische Trennung und dass bei einem Verpolen des Steckers kein Reset erfolgen kann, da die Transistoren wie eine Diode nur in einer Richtung Strom fließen lassen. Ein Brückengleichrichter löst das Problem wegen des Spannungsverlustes über den Dioden übrigens nicht, man kann aber möglicherweise mit 2 FET eine Lösung finden, muss man aber auch ausrechnen und testen.

Hinweis: Der Transistor muss im Fall der APU1 sicher 70mA aushalten können die kurzzeitig aus dem Kondensator fließen können!

Ob die Lösung mit einer neueren APU oder einem anderen Gerät funktionieren wird: muss man im Einzelfall sehen.


Ein Optokoppler bietet galvanische Trennung, ist unempfindlich gegen statische Aufladung oder offene Eingänge, allerdings ist er ebenfalls nicht verpolungssicher und man muss auch hier je nach Logikpegel den Vorwiderstand ausrechnen. Wäre in meinen Augen die sauberste Lösung, hat nur den Nachteil mit dem Verpolen – und nichts ist ärgerlicher als festzustellen, dass der remote-Reset nicht funktioniert und aus einer Lapalie wie kernel-update eine Rettungsmission mit 30 Minuten Anfahrt wird. Es sollte möglich sein zwei Optokoppler antiparallel zu schalten um eine Lösung zu finden die Verpolungssicher ist.

Aber auch hier gilt: Man muss passende Optokoppler finden, die Vorwiderstände berechnen und mit der APU testen. Bis zu 70mA sind kurzzeitig zu bewältigen und wenn andere Geräte angeschlossen werde sollen muss man gegebenenfalls wieder in die Designphase.

Taster und Servo

Für die ganz paranoiden – was als Druckluftschnellschalter in der Hochspannungstechnik existiert kann für uns nicht verkehrt sein oder so… Nein, einfach nur nein.


So sehr es mich wurmt, unter den gegebenen Voraussetzungen ist eine Lösung mit einer fertigen Relais-Platine mit Jumper um von 3.3V zu 5V Eingang umzuschalten die einfachste, robusteste und billigste Lösung.

Es ist kein Verpolen möglich, die APU wird wie vorgesehen von einem Taster in Form der Relaiskontakte zurückgesetzt, man kann auch andere Geräte damit zurücksetzen ohne vorher den Schaltplan zu studieren und ganz wichtig: die Platinen gibt es schon fertig für sehr kleines Geld zu kaufen.


Nicht jede Lösung ist elegant, wenn sie robust sein muss – und manchmal sind 80% Lösungen die in 100% der Fälle funktionieren besser, also 100% Lösungen.



Veröffentlicht unter de, Elektronik, hardware | Kommentare deaktiviert für Howto RESET


Heute ist mir hier wieder einmal ein Stück Hardware in die Finger gefallen und hat sich dort spontan desintegriert – das Gehäuse war aufgeplatzt, also habe ich einen Blick in das Innere gewagt.

Es handelt sich um ein Netzteil mit 12V/2A – wenn man dem Typenschild glauben schenken mag. Gekauft hatte ich es vermute ich mal als Ersatz für eine externe Festplatte aber bisher noch nicht benutzt. Und das war vielleicht auch gut so.

Auf die inneren Werte kommt es an!

Hier also meine Eindrücke vom ‚Teardown‘ – Vorab: Ich wundere mich wirklich, warum es nicht häufiger zu Wohnungsbränden oder Stromschlägen kommt.

Das Typenschild lässt schon einmal nichts gutes erahnen. Bei der Stromaufnahme ist das Ampere klein geschrieben, und rechnet man nach kommt man auf 40 Watt (100*0.4A) maximale Leistungsaufnahme – für 24 Watt am Ausgang.  Die Annahme dabei ist, dass 0.4 der maximale Strom sind und der tritt bei der geringsten Betriebsspannung auf. Aber gut, als maximum rating geht das von mir aus durch. Viel wichtiger aber ist: Es sind keinerlei Prüfzeichen vorhanden, einzig CE – auch ‚China Equipment‘ genannt – doch das bringt der Hersteller selbst an.

Betrachtet man dann die Platine wie sie im Gehäuse liegt fällt sofort auf, dass sie offenbar für etwas anderes gebaut wurde – sie ist viel zu klein und es ist ein Westernstecker verbaut für den keine Öffnung im Gehäuse existiert. In Position gehalten wird das ganze von Schaumstoff, der zwischen Deckel und Platine geklemmt ist und diese auf das Plastik pressen. Die Kabel verschwinden auf der Unterseite und das lässt nichts Gutes erahnen.

Und richtig, dreht man die Platine um offenbart sich das ganze Grauen. Die Netzspannung wird über zwei sehr dünne Drähte mit nur wenigen Kupferadern die schnell brechen zur Platine geführt, es gibt keine Isolierung auf der Unterseite, zu lange Drähte von der Platine können die Pins des Steckers direkt berühren. Löst sich einer der Anschlussdrähte kann die Netzspannung über das lose Ende direkt auf den Sekundärteil gelangen. Zudem sind die beiden blauen Drähte so lang, dass sie unter dem Sekundärteil verlaufen. Da die Platine vom Schaumstoff unter Druck gehalten wird, werden die beiden Zuleitungen direkt auf die Ausgangspins des Übertragers gedrückt. Doch damit nicht genug.

Bei näherem Hinsehen kann man erkennen, dass die Kabel für die 12 V auf die Pins des Ausgangskondensators gelötet wurden. Dabei sind sie so lang dass sie überstehen, die 12V Leitung kommt einem SMD Widerstand bedenklich nahe und kann diesen leicht berühren – damit landen dann 12V irgendwo. Mechanisch stabil ist das ganze natürlich auch nicht – die Drähte sind nicht durch die Platine geführt, die Löststellen schlecht ausgeführt.

Die Highlights habe ich auf den letzten beiden Bildern markiert – offenbar musste ein Bauteil gebrückt werden um die 12V zu bekommen, auf dem Western Stecker liegt die Ausgangsspannung immerhin über eine Sicherung an. ein anderer SMD Widerstand wurde mit einem zweiten Huckepack gebrückt und es gibt einzelne Lotperlen die zu Kurzschlüssen führen können.

Eine Sicherung auf der Primärseite habe ich in dem Netzteil nicht gefunden, nur einen 10 Ohm Lastwiderstand am Eingang, der etwa 1.5 Watt an Leistung verbraten kann.

Ich bin immer wieder erschrocken, wenn ich daran denke wie viele von diesen Geräten irgendwo unter Schreibtischen im Dauerbetrieb sind.

Fazit: Finger weg von billigen Netzteilen!

Das Fehlen von VDE, TÜV und sonstigen Prüfzeichen ist in meiner Erfahrung ein starkes Indiz für gefährliches Equipment.

Im vorliegenden Fall hat die Platine selbst ein Prüfzeichen und sie ist bis auf die fehlende Sicherung auch sicher aufgebaut – nur alles drumherum und die nachträglichen Änderungen machen das zunichte. Ich habe derartiges schon häufiger erlebt. Inklusive einem Netzteil, bei dem die alten Anschlusskabel nur abgeknipst wurden und neue darübergelötet.

Es besteht nicht nur die Gefahr dass die daran angeschlossenen Geräte kaputt gehen, es kann auch zu Feuer oder Stromschlägen kommen.

Gibt es da keine Gesetzte gegen?

Doch, die gibt es. Verkauft bzw. in Verkehr gebracht werden dürfte das Gerät in der EU nicht, meist handelt es sich um Importe über das EU Ausland, wo teilweise keine Kontrollen stattfinden.

Das in Berlin zuständige Amt für die Produktsicherheit erklärte mir auf Nachfrage, dass diese Waren z.B. oft über England eingeführt werden und dort werde schlicht nicht auf Produktsicherheit kontrolliert. Von dort kam auch meine LED-Lampe die unisolierte 230V auf der Außenseite anliegen hatte.

Letztlich kommt es auf die Verbraucher an: Wenn man immer nur auf den Preis achtet setzt man sich und seine Umgebung nicht unerheblichen Gefahren aus, produziert unnötigen Elektroschrott und hat auch nur für kurze Zeit etwas von den Produkten.

Veröffentlicht unter chinacrap, de, Elektronik, frust, hardware, Kaputt, leid, Technik | Kommentare deaktiviert für Chinanetzteil

Letsencrypt ohne rootrechte und (halb) automatisiert

Seit einiger Zeit bietet die Initiative letsencrypt.org nun kostenlose SSL-Zertifikate an und nachdem sich die anfängliche Verwirrung über die benötigten Rechte des ACME-Clients gelegt haben, sieht das ganze sogar halbwegs brauchbar aus. Was liegt also näher, das ganze mal auszuprobieren – eigentlich nicht viel.


Veröffentlicht unter apache, de, Linux, server, Software, Tipps | Kommentare deaktiviert für Letsencrypt ohne rootrechte und (halb) automatisiert

GHOST patches for squeeze (Unofficial) – CVE-2015-0235

I did a best-effort backport of the wheezy patches against GHOST (CVE-2015-0235) for Debian GNU/Linux squeeze-lts, as is seems there are not official packages yet available. Use at your own risk!

Ich habe einen ‚best effort‘ Backport der wheezy patches gegen GHOST(CVE-2015-0235) für Debian GNU/Linux squeeze-lts gebaut, da es scheinbar bisher keine offiziellen Pakete gibt:


update: the patches are obsolete – official packages are available now!

Veröffentlicht unter de, debian, en, IT, Kaputt, Linux, security, server, Software, unix | Kommentare deaktiviert für GHOST patches for squeeze (Unofficial) – CVE-2015-0235

Mapping CDNs for fun and profit using DNS

The following text is a blogpost explaining my Diploma Thesis and the paper Exploring EDNS-Client-Subnet Adopters in your Free Time published in 2013.

The article was intended for publication in the corporate blog of one of the CDNs we studied, but after verizon bought the CDN the article never got published. Weiterlesen

Veröffentlicht unter en, lesenswert, Science | Verschlagwortet mit , , | Kommentare deaktiviert für Mapping CDNs for fun and profit using DNS

kernel patch for CX23103 Video Grabber Linux Support

I recently bought a „LogiLink USB2.0 Video Grabber with Snap Shot“ – Model VG0005B v.1.0 – (EAN 4052792002102)

When I bought it I did not realize, that it is officially not supported in Linux (also see http://www.linuxtv.org/wiki/index.php/SilverCrest_USB_2.0_Video_Grabber_SVG_2.0_A2) – because I missed some part of the product name when searching for support.

Kernel fun

After spending the whole day trying to recompile a new kernel, stumbling over various oddities, it finally worked.

I don’t know how such drivers can be published, but the nvidia drivers at first would not compile, stating that my 3.0.x kernel is not compatible (only 2.6 an newer are supported, you know). The reason in pseudo code: if [ major -lt 2 -o minor -lt 6 ]; … yes, thats an OR in the middle and yes, the 0 in 3.0 is smaller than 6.

Also all the version magic included in modules is p.i.t.a. when you try to compile one module for a destirbution kernel – so I recompiled the whole kernel and modules because although my module had been built fine, it failed to load the video grabber module because the version magic did not match.

Getting it to work

My idea was, that there are not many reference designs out there for this chip and that the manufacturer hopefully does not reinvent the wheel in his chips either. And it seems I was right.

What is needed for this to work is a 2 line patch to the cx231xx driver to tell it that the chip is supported and what configuration to use:

So in drivers/media/video/cx231xx/cx231xx-cards.c go to struct usb_device_id cx231xx_id_table[] and add these two lines e.g. at the beginning of the definition:

        {USB_DEVICE(0x1D19, 0x6109),
         .driver_info = CX231XX_BOARD_PV_XCAPTURE_USB},

Here the lucky part is, that the LogiLink people use the exact same design thats used by the board mentioned above. Caveat: I have not tested the audio part.

And yes, I will now try to get that upstream and included into the kernel.

Update: capturing audio crashed my systen…

Veröffentlicht unter en, freude, hardware, Linux, Uncategorized | Kommentare deaktiviert für kernel patch for CX23103 Video Grabber Linux Support

Warum ich FOSS liebe und was sie bedroht

Manchmal gibt es Tage, an denen mir richtig bewusst wird, warum ich seit über 15 Jahren versuche überall wo es möglich ist freie Software einzusetzen, mit allen Vor- und Nachteilen.

Ich habe in der vergangenen Woche gleich mehrere schöne Erlebnisse mit dem Ökosystem gehabt, dass sich rund um Linux und freie Software in den vergangenen Jahren etabliert hat. Und ich wünsche mir, dass dies auch weiterhin so bleibt und noch viele andere Menschen so positive Erfahrungen mit FOSS machen dürfen.


Zum Einen war da ein kleine Problem mit Claws, dem Mailclient den ich derzeit benutze. Man kann claws auf der Kommandozeile so aufrufen, dass ein neues Compose Fenster aufgeht, das eine auf der Kommandozeile übergebene Email samt Anhang enthält. Leider wurde dabei der Account nicht automatisch anhand der Absenderadresse ausgewählt, so dass die Email dann im Sent-Ordner eines anderen Accounts landen konnte.  Im IRC-Channel der Developer dauerte es dann nicht einmal eine halbe Stunde vom Melden des Problems bis ich einen Patch hatte. Nachdem ich diesen getestet hatte, wurde die Änderung auch schon direkt in Claws übernommen und wird im nächsten ist im aktuellen Release enthalten sein. Undenkbar bei proprietärer Software.


Dann gab es da einen Bug in Terminator, den von mir exzessiv genutzten Terminalemulator. Beim De-Maximieren wurde das Fenster bis zur Unkenntlichkeit verkleinert. Dank des öffentlich zugänglichen Debian Bugtrackers und der Möglichkeit per apt-get source den Quellcode zu bekommen, konnte ich zum Einen jemanden mit demselben Problem finden und dann auch noch selbst einen Hotfix bauen, der das Problem erstmal behoben hat. Da ich außerdem selbst im Bug diesen Hotfix beschreiben konnte ist den Entwicklern geholfen und dem anderen Anwender eventuell auch. Undenkbar bei proprietärer Software.


Für eine Webseite suche ich derzeit nach einem neuen CMS mit guter Unterstützung für mehrsprachige Seiten – was sich als gar nicht so kleines Problem darstellt. Ich konnte an einem einzigen Tag 5 verschiedene Systeme installieren und im irc mit dem Entwicklern die Features diskutieren. Und dabei ist es kein Tabu die verschiedenen Systeme direkt zu vergleichen und von den Entwicklern von System A den Hinweis zu bekommen sich doch mal C anzusehen. Und das alles ganz ohne Probelizenzen oder Supportvertrag. Undenkbar bei proprietärer Software.


Schon etwas länger ist es her, als ich zufällig über einen Fehler im Linuxkernel stolperte. Auch hier gab es die Situation, die ich bei Claws oben beschrieben hatte. Nur 4 Stunden nachdem ich den Bug im Ticketsystem geöffnet und mich im irc channel des Projekts gemeldet hatte, gab es einen Fix und er war im nächsten Release des Kernels enthalten. Ihr wisst schon was jetzt kommt: Undenkbar bei proprietärer Software.

Direkter Draht aka Rotes Telefon

Was mich bei alledem am meisten fasziniert ist, dass man per irc und mail eigentlich überall noch direkten Kontakt mit den Entwicklern bekommt. Diese können mit mir als Kunde direkt sprechen und Rückfragen stellen. Vor genau diesem Kontakt aber scheinen andere Angst, ja geradezu Panik zu haben. Ich frage mich woher das kommt.


Kommen wir zum zweiten Teil meines Titels. Was bedroht dieses Ökosystem?

In den vergangenen Monaten kämpfte ich mit einem Storagesystem eines größeren Herstellers und der proprietären Variante von Xen und musste festellen, dass hier doch einiges im Argen liegt.

Warum das proprietäre Xen?

Nun, das ist gewissen Rahmenbedinungen geschuldet, denn natürlich ging dem eine Evaluation voraus, bei der die Mitbewerber aus verschiedenen Gründen ausschieden. Sei es dass nicht verhindert wurde das zwei virtuelle Maschinen auf denselben iSCSI Storage zugriffen und damit das Dateisystem nachhaltig zerstörten oder das die Verwaltungssoftware einfach abstürzte. Beides ist in einer Produktivumgebung auf der alle zentralen Dienste laufen sollen nicht hinnehmbar.

Wir entschieden uns also für das proprietäre XenCenter, von dem es eine kostenlose Lizenz gibt wenn man gewisse Features nicht benötigt. Und ich muss sagen das funktioniert sogar relativ gut alles.

Aber was tötet nun FOSS?

Es sind direkt oder indirekt Firmen wie RedHat und SuSE/Novell. Und hier kommen wir zu einem zweischneidigen Schwert. Denn einerseits fördern beide direkt durch die Finanzierung und indirekt durch ihre Marktmacht die Entwicklung vieler Projekte und machen das Eine oder Andere gerade erst möglich. Schließlich müssen auch die Entwickler von Freier Software jeden Tag etwas essen und ein Dach über dem Kopf ist der Softwareentwicklung im Allgemeinen auch eher zuträglich.

Are you (in) the Enterprise?

Aber dann versucht man mit dem Hersteller eines Storage Systems nachzuvollziehen, warum denn die Performance weit hinter den Erwartungen bleibt. Und alles was diesem Hersteller einfällt ist an einem bestimmten Punkt die Probleme auf das eingesetzte Debian zu schieben – denn man unterstützt nur RedHat Enterprise Linux oder SuSE. Und natürlich keine der kostenlosen Varianten wie OpenSuSE oder CentOS.

Und dann stellt man fest, dass die Webseiten beider ‚Hersteller‘ es einem nicht einfach machen so etwas wie eine Testlizenz zu bekommen – jedenfalls nicht ohne die Eingabe persönlicher Daten und Emailadressen.

Binäres Rauschen

Fatal ist, dass der Hersteller zudem einige seiner Treiber tatsächlich nur für die genannten Plattformen anbietet. In der Praxis sieht das dann so aus, dass Binaries des device mappers ersetzt werden. Diese und die zugehörigen Bibliotheken wandern dann in das System und lassen sich natürlich auf anderen Systemen nicht nutzen. Ob und was der Hersteller an der Software geändert hat ist natürlich auch nicht dokumentiert. Anhand der Copyrighthinweise kann man aber erahnen, dass schlicht nur neuere Versionen des devicemappers auf die teilweise antiken aber voll unterstützten Enterprise-Umgebungen portiert wurden.

Schade ist auch, dass der Hersteller des Storage bei der Unterstützung der Plattformen so engstirnig vorgeht, dass sich sogar die plattformunabhängige Verwaltungssoftware (Java!) nur unter den genannten Betriebssystemen installieren lässt, was nicht nur an der Verfügbarkeit nur als rpm-Archiv liegt. Man könnte also wenn man wollte – man will nur nicht.


Nicht nur als Privatanwender kämpft man immer wieder mit der Ignoranz vieler Hersteller – auch im so genannten ‚Enterprise‘-Markt gibt es massive Probleme mit Herstellern, die keinen offenen und transparenten Entwicklungsprozess pflegen. Das diese Abschottung aber gerade die Vorteile der von den Herstellern genutzten  Plattformen unterminieren ist ihnen scheinbar nicht klar oder schlicht egal. So ist es weder bei  dem Hersteller des Storage noch bei Xen möglich in irgendeiner Form direkt mit Entwicklern zu sprechen, geschweige denn Informationen zu erhalten, die nicht durch den Konzern freigegeben sind.

Und hier lauert im  ‚Enterprise‘-Markt eine Bedrohungen, die uns die kommenden Jahre denke ich noch beschäftigen wird. Die eigentlich offenen und freien Systeme werden vernagelt und verrammelt,  Treiber durch die Hersteller weiterhin nur als binärer Müll weitergegeben und Support für Fremdsysteme verweigert. So kann keine Innovation entstehen.

Schade eigentlich.


Veröffentlicht unter Ärger, de, debian, freude, frust, IT, language, leid, Uncategorized | Kommentare deaktiviert für Warum ich FOSS liebe und was sie bedroht

Bind: update your blackholes

Aus aktuellem Anlass..

Vollmar.net hat ein Netz innerhalb von – warum erwähne ich das heute? Ich betreibe für einige Domains einen seconndary nameserver – und einer dieser Kunden zog gerade zu Vollmar um.

Plötzlich kamen aber nicht mehr alle Zonenupdates durch, die Fehlermeldung lautete:


soa_query: zone xxxx/IN/external-in: dns_request_createvia2() failed: address blackholed

Hintergrund ist, dass der bind dort eine Uralte default blacklist hatte für private Netze, etc.

Eine whois-Orgie später weiss ich nun, das folgende Netze offenbar seit einiger Zeit aktiv sind, und nicht mehr dort hinein gehörten:


Also, updated mal eure bind config 😉


Veröffentlicht unter Bind, de, debian, fail, language, Linux, Software, Technik | Kommentare deaktiviert für Bind: update your blackholes