Schlagwort: Networking (Seite 5 von 12)

Neues Zertifikat für die Homepage von Let’s Encrypt

24. Januar 2017 / Sebastian van de Meer / Keine Kommentare

Tach zusammen,

StartSSL ist ja aktuell einfach tot 🙁 Eine für mich sinnvolle Alternative konnte ich aber nicht finden. Eine Wildcard Zertifikat für meine Domains und dann einfach überall das gleiche *grusel* aber 10000 € ausgeben um sonst meine Wünsche zu erfüllen macht auch keinen Sinn. Tja bleibt Let’s Encrypt…. Gott, ich will nicht alle drei Monate neue Zertifikate bauen. Das ist Käse, vor allem mit TLSA/DANE, HPKP usw. *brech*

Für jetzt bin ich dennoch dazu gezwungen auf Let’s Encrypt zu wechseln. Es wird also ein solches Zertifikat hier geben. Ich hoffe nun einfach darauf, dass StartSSL wieder in die Browser kommt. 01.06.2017 soll es da wohl weiter gehen, hm?

https://bugzilla.mozilla.org/show_bug.cgi?id=1311832

https://startssl.com/NewsDetails?date=20160919

Klar ist jetzt dieser China CA zu vertrauen? Nö… Nur bis zu einem gewissen Punkt und ab dann halt HPKP, TLSA/DANE, DNS CAA. Was mir so gut gefällt ist die Möglichkeit für einen vertretbaren Preis so viele unterschiedliche Zertifikate raus zu hauen, wie ich es für richtig halte.

Also kommt nun Let’s Encrypt als „hoffentlich Übergang“ und dann wieder StartSSL oder jemand von euch hat eine gute Idee für mich?

So long…

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

TLSA verkackt: Wenn man nach dem Zertifikatstausch den DNS-Record vergisst

26. September 2016 / Sebastian van de Meer / Keine Kommentare

Da kommt folgende Mail rein:

Hi,
mein Firefox Plugin und hash-slinger sagen beide, dass dein TLSA Record für
munin.kernel-error.com
kaputt ist.

Gruß
Andreas

Recht hat der Mann. Ich hatte das Zertifikat getauscht (auf Elliptic Curve umgestellt) und vergessen, den TLSA-Record im DNS zu aktualisieren. Klassiker. Der TLSA-Record enthält einen Hash des Zertifikats. Tauscht man das Zertifikat, stimmt der Hash nicht mehr, und jeder Client der DANE prüft sieht einen Fehler.

Passiert schneller als man denkt, besonders wenn man mehrere Dienste auf verschiedenen Subdomains hat. Jeder braucht seinen eigenen TLSA-Record. Zertifikat erneuern, TLSA vergessen, niemand merkt es (weil kaum jemand DANE validiert). Bis jemand wie Andreas mit dem Firefox-Plugin vorbeikommt.

Die Lektion: Nach jedem Zertifikatstausch die TLSA-Records prüfen. Am besten automatisiert, zum Beispiel per Skript das nach dem ACME-Renewal den Hash berechnet und den DNS aktualisiert. Wer TLSA-Records von Hand prüfen will, findet die Anleitung unter TLSA/DANE manuell prüfen. Die Grundlagen zu DANE stehen im Beitrag DNSSEC und DANE. Fragen? Einfach melden.

Debian in einer FreeBSD Jail: Linux-Userland mit iocage und debootstrap

13. November 2015 / Sebastian van de Meer / Keine Kommentare

FreeBSD kann Linux-Binaries ausführen. Das ist nichts Neues. Aber ein komplettes Debian in einer Jail laufen lassen, mit apt-get und allem was dazugehört? Das geht auch. Die Jail nutzt den FreeBSD-Kernel, das Userland kommt von Debian GNU/kFreeBSD. iocage erstellt die Jail, debootstrap installiert das Debian-Basissystem hinein.

Hinweis: Debian GNU/kFreeBSD wurde nach Debian 8 (Jessie) eingestellt. Für aktuelle Setups ist linux_enable="YES" in der /etc/rc.conf mit einer regulären Linux-Jail der bessere Weg. Die hier gezeigte Methode funktioniert aber weiterhin mit älteren Debian-Versionen und zeigt das Prinzip.

Voraussetzungen

iocage muss installiert und konfiguriert sein. Zusätzlich wird debootstrap benötigt:

pkg install debootstrap

Jail erstellen

Die Jail wird mit iocage angelegt. Die entscheidenden Parameter sind exec_start und exec_stop. Statt der üblichen FreeBSD-Init-Skripte werden die Debian-Runlevel aufgerufen:

iocage create -e tag=debian-jail01 \
  exec_start="/etc/init.d/rc 3" \
  exec_stop="/etc/init.d/rc 0"

Runlevel 3 startet die Dienste, Runlevel 0 fährt herunter. Den Mountpoint der neuen Jail auslesen:

iocage get mountpoint debian-jail01
# /iocage/jails/19e3594f-.../

Debian installieren

debootstrap holt ein minimales Debian von den Mirrors und entpackt es in das Root-Verzeichnis der Jail. In diesem Beispiel Debian Wheezy:

debootstrap wheezy /iocage/jails/19e3594f-.../root/
# I: Retrieving Release
# I: Retrieving Packages
# I: Resolving dependencies of required packages...
# I: Resolving dependencies of base packages...
# [... ~150 Pakete werden heruntergeladen und entpackt ...]
# I: Configuring adduser...
# I: Configuring apt...
# I: Base system installed successfully.

Das dauert ein paar Minuten. Am Ende steht ein komplettes Debian-Basissystem im Jail-Verzeichnis.

fstab für die Jail

Debian braucht ein paar Dateisysteme die FreeBSD nicht automatisch in Jails mountet. Die fstab der Jail (nicht die im Debian) bekommt drei Einträge:

# /iocage/jails/19e3594f-.../fstab
linsysfs  .../root/sys         linsysfs  rw          0 0
linprocfs .../root/proc        linprocfs rw          0 0
tmpfs     .../root/lib/init/rw tmpfs     rw,mode=777 0 0

linsysfs und linprocfs stellen die Linux-kompatiblen /sys und /proc bereit. Ohne die funktionieren viele Linux-Programme nicht. Das tmpfs für /lib/init/rw braucht Debians Init-System.

Netzwerk und Hostname

IP-Adresse und Hostname setzen:

iocage set vnet=off debian-jail01
iocage set ip4_addr="em0|192.168.1.46/16" debian-jail01
iocage set hostname="debian-jail01" debian-jail01
iocage set host_hostname="debian-jail01" debian-jail01

Die /etc/hosts im Debian-Dateisystem anpassen:

# /iocage/jails/19e3594f-.../root/etc/hosts
127.0.0.1       localhost debian-jail01
::1             localhost ip6-localhost ip6-loopback debian-jail01

Starten und nutzen

Beim ersten Start kommen ein paar Fehlermeldungen wegen mount_unionfs und fehlenden Verzeichnissen. Die sind harmlos und können ignoriert werden:

iocage start debian-jail01
# mount_unionfs: .../: No such file or directory
# mount: .../root/usr/home: No such file or directory
# * Starting 19e3594f-... (debian-jail01)
#   + Started (shared IP mode) OK
#   + Starting services        OK

Konsole betreten:

iocage console debian-jail01
# GNU/kFreeBSD debian-jail01 10.2-RELEASE-p4
root@debian-jail01:~# apt-get update
root@debian-jail01:~# apt-get install mc

apt-get funktioniert, Pakete lassen sich installieren, Dienste starten. Von aussen geht auch iocage exec debian-jail01 uname -a und zeigt den FreeBSD-Kernel mit GNU/kFreeBSD-Userland.

Das Stoppen funktioniert wie bei jeder anderen Jail:

iocage stop debian-jail01

Einordnung

Das hier ist kein Ersatz für eine richtige Linux-VM. Es ist ein Trick: Der FreeBSD-Kernel stellt die Jail-Isolation, Debian liefert das Userland. Nützlich wenn man ein bestimmtes Linux-Tool braucht das es für FreeBSD nicht gibt, oder wenn man testen will wie sich Software unter Debian verhält.

Für produktive Linux-Workloads auf FreeBSD ist heute eher eine reguläre Jail mit dem Linux-Kompatibilitätslayer oder gleich bhyve die bessere Wahl.

Fragen? Einfach melden.

Mal wieder auffällig viele Brute-Force SSH Angriffe….

11. Januar 2015 / Sebastian van de Meer / Keine Kommentare

Seit gestern fällt es irgendwie auf… Da rattert wieder etwas über die Systeme.

Probiert werden die User:

– root
– admin
– mail
– Alphanetworks
– MANAGER
– test
– Factory
– vodafone
– telecomadmin
– draytek
– super
– FIELD
– ADVMAIL
– WP
– HELLO
– citel
– SPOOLMAN
– comcast
– wlseuser
– OPERATOR
– PCUSER
– MGR
– patrol
– netadmin
– anonymous
– craft
– websecadm
– netman
– MD110
– supervisor
– tiger
– manuf
– PBX
– NETWORK
– MDaemon
– readonly
– davox
– scout
– blank
– coress
– usw. usw. usw…..

Spannenderweise mit immer neuen Adressen aus verschiedenen großen Netzen. Im groben lässt es sich „eindampfen“ auf:

– 117.253.0.0/16
– 109.161.236.0/22
– 189.51.16.0/20

Hier und da noch etwas verteiltes… Indien, Brasilien, Italien, wenn man dem WHOIS trauen kann. Was da wieder los ist? Dann wird wohl bald wieder mehr Spam kommen, hm?

Ich wünsche in jedem Fall ein paar klebrige Finger!

Jan 11 11:42:53 ssh-honeypot sshd[21822]: Invalid user MANAGER from 182.74.23.34
Jan 11 11:42:53 ssh-honeypot sshd[21822]: input_userauth_request: invalid user MANAGER [preauth]
Jan 11 11:42:56 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:42:58 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:01 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:03 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:05 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:08 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2

Siehe auch: SSH-Server absichern mit MFA, SSH Brute Force, Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi, SSH-Brute-Force mit veralteter Implementierung: Angriffsmuster erkennen

Fragen? Einfach melden.

Openfire: 404 Remote Server Not Found bei S2S-Verbindungen mit TLS

19. November 2014 / Sebastian van de Meer / Keine Kommentare

Seit ich für die Server-zu-Server-Verbindungen (S2S) auf meinem Openfire TLS erzwinge, melden sich andere Openfire-Admins: Ihre User bekommen ein „404 remote server not found“. Nachrichten gehen nur in eine Richtung durch. Wenn die Unterhaltung einmal läuft, klappt es für eine Weile. Ein seltsamer Effekt der nicht direkt auf die Ursache schließen lässt.

Das Problem

Das Problem liegt nicht am eigenen Server und nicht am DNS. Es liegt am Java-Keystore auf der Gegenseite. Java 6 und einige Versionen von Java 7 können die Zertifikatskette nicht korrekt aufbauen, wenn das Intermediate-Zertifikat der CA fehlt. Mein Server sendet es zwar mit, aber Java ignoriert es und versucht die Kette allein aus dem lokalen Truststore zu bauen.

Im warn.log des betroffenen Openfire findet man dann:

org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation

Die Lösung: Intermediate-Zertifikat importieren

Der Admin des betroffenen Openfire muss das Intermediate-Zertifikat der CA in den Java-Truststore importieren. Auf einem Debian-System:

cd /etc/openfire/security/
/etc/init.d/openfire stop

# Intermediate-Zertifikat der CA herunterladen
wget "https://example-ca.com/intermediate.crt"

# In den Truststore importieren
keytool -import -keystore truststore -alias ca-intermediate -file intermediate.crt
# Passwort: changeit (Java-Default)

/etc/init.d/openfire start

Das Prinzip gilt für jede CA. Das Intermediate-Zertifikat von der Webseite der CA herunterladen und mit keytool in den Truststore importieren. Falls das Zertifikat bereits vorhanden ist, meldet keytool das und man kann den Import überspringen.

Prüfen ob die Kette stimmt

Mit openssl lässt sich prüfen ob der Server das Intermediate-Zertifikat korrekt ausliefert:

openssl s_client -showcerts -connect jabber.example.com:5222 -starttls xmpp

Entscheidend ist die letzte Zeile der Ausgabe:

Verify return code: 0 (ok)

Steht dort etwas anderes, fehlt ein Zertifikat in der Kette oder das Intermediate-Zertifikat wird nicht mitgesendet. In dem Fall muss der Serverbetreiber seine Zertifikatskonfiguration in Openfire prüfen.

Wer schon dabei ist die TLS-Konfiguration anzufassen: Im Beitrag zu unsicheren Ciphern und Protokollen in Openfire steht wie man die veralteten Algorithmen loswird.

Fragen? Einfach melden.

DNSSEC: KSK auf 4096 Bit aktualisieren und SHA-512 vorbereiten

18. November 2014 / Sebastian van de Meer / Keine Kommentare

Ich habe nach längerem dann mal meinen KSK (Key Signing Key) für DNSSEC getauscht. Der alte war ein 1024-Bit NSEC3RSASHA1. Damit ist auch klar, warum er weg musste: 1024 Bit RSA gilt seit Jahren als zu schwach für langfristige Sicherheit, und SHA-1 steht ebenfalls auf der Abschussliste.

Die neuen Schlüssel

Zwei neue KSKs, beide mit 4096 Bit:

1. NSEC3RSASHA1, 4096 Bit  (primär, abwärtskompatibel)
2. RSASHA512, 4096 Bit     (Reserve, ohne SHA-1)

Die Idee: Der NSEC3RSASHA1 als primärer Schlüssel, weil ihn jede halbwegs aktuelle Software versteht. Der RSASHA512 liegt als Backup bereit, falls SHA-1 irgendwann komplett fällt. Inzwischen sollte jede aktuelle Software mit beiden Algorithmen umgehen können. Wenn nicht, wird es wirklich Zeit für ein Update.

KSK-Rollover

Ein KSK-Tausch ist kein Schalter den man umlegt. Man muss den neuen Schlüssel veröffentlichen, warten bis sich der DS-Record bei der übergeordneten Zone (also bei DENIC, Verisign etc.) verbreitet hat, und erst dann den alten entfernen. Dazwischen signiert man mit beiden gleichzeitig. Das dauert je nach TTL einige Tage.

Das Ergebnis auf DNSViz sieht sauber aus. Alle drei Zonen validieren korrekt:

Wer DNSSEC von Grund auf einrichten will, findet die Anleitung unter DNSSEC einrichten mit BIND. Fragen? Einfach melden.

Alternative SPF-RECORDS im DNS

2. November 2014 / Sebastian van de Meer / Keine Kommentare

Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 als deprecated eingestuft. SPF wird ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.

Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.

Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem. Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir.

So long

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

17. Oktober 2014 / Sebastian van de Meer / Keine Kommentare

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

Raspberry Pi als FM-Radiosender mit PiFM

30. September 2014 / Sebastian van de Meer / Keine Kommentare

Kinder sind etwas Wunderbares, so auch meine beiden. Die Größere hört zum Einschlafen gerne ein Hörspiel, beim Spielen hören und tanzen beide zu Kindermusik. Klar haben sie eine kleine Kompaktanlage im Kinderzimmer. Aber Kinderhörspiele gibt es kaum noch auf Kassette — fast nur noch auf CD oder als MP3. Keine Ahnung wie es bei euren Kindern ist, bei uns leben CDs nicht sonderlich lange. Ich grille in der Woche 3 bis 4 Stück. Noch schlimmer: Die Lieblings-CD trifft nach 38 Minuten auf einen Kratzer und macht nur noch unverständlichen Lärm.

MPD als CD-Ersatz

Ich hatte noch einen Raspberry Pi herumliegen. Den zusammen mit dem Music Player Daemon (MPD) als Musikspieler nutzen — die gekauften MP3-Alben liegen eh auf dem Server und lassen sich per NFS mounten. WLAN ist im ganzen Haus, und wir Eltern steuern alles per Android-App. Das Projekt war in anderthalb Stunden erledigt, getestet und von den Kindern abgenommen.

Seitdem fristet der CD-Spieler ein ungenutztes Leben. Nur das Radio läuft hin und wieder am Abend. Radio… irgendwo hatte ich doch im Zusammenhang mit dem Raspberry Pi etwas zu FM-Radio gelesen.

PiFM — FM-Sender über GPIO

PiFM (mittlerweile weiterentwickelt als rpitx) nutzt den GPIO-Pin 4 des Raspberry Pi, um ein FM-Signal zu erzeugen. Eine ca. 15 cm lange Antenne — ein Stück Draht — reicht. Der Pi generiert per DMA ein Taktsignal auf dem GPIO, das direkt als FM-moduliertes HF-Signal abstrahlt. Kein zusätzlicher Sender-IC nötig.

Eine WAV-Datei auf 90,0 MHz senden:

sudo ./pifm musik.wav 90.0

Einen Web-Stream — zum Beispiel einen Kinderradiosender — per sox umwandeln und direkt an PiFM pipen:

sox -t mp3 http://stream-url -t wav -r 22050 -c 1 - | sudo ./pifm - 90.0

MPD kann auch streamen — so lässt sich die gesamte Musikbibliothek per FM ins Kinderzimmerradio schicken.

Verstärkerschaltung

Das reine GPIO-Signal ist schwach. Um es etwas zu verstärken und sauber zu filtern, habe ich eine kleine Schaltung gebaut — den handgezeichneten Schaltplan mit Bauteileliste findet ihr in den Bildern unten. Mit der Schaltung reicht das Signal für das ganze Haus inklusive Garten.

Rechtliches

In Deutschland darf man im FM-Band senden — aber nur mit extrem geringer Leistung. Die Bundesnetzagentur erlaubt ohne Genehmigung Sendeanlagen mit wenigen Nanowatt, was in der Praxis etwa einen Meter Reichweite ergibt. Der Raspberry Pi mit Verstärkerschaltung überschreitet das deutlich. Dieses Projekt bleibt deshalb ein einmaliger Versuchsaufbau.

Schade eigentlich — der WDR-Kinderkanal MausLive (ehemals KiRaKa) ist nur per DAB+ oder Internet-Stream zu empfangen. Per PiFM könnte man den Stream als FM-Signal im Haus verteilen und die Kinder könnten überall mit einem einfachen Radio hören. Aber so ist die Rechtslage.

Bilder vom Projekt — Platine, Schaltplan mit Bauteileliste und das Ergebnis auf dem Radio: