-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 15 von 45)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2

12. Januar 2018 / / Keine Kommentare

Die QIVICON Home Base vom Telekom SmartHome kann keine Firmware-Updates auf die HomeMatic-Geräte von eQ-3 aufspielen. Bei den älteren HomeMatic-Geräten war das kein Problem, Updates waren selten und betrafen keine kritischen Funktionen. Bei den neueren HomeMatic IP Geräten sieht das anders aus. Die Firmware ändert sich regelmäßig, neue Funktionen kommen dazu und Bugs werden behoben. Ein Zwischenstecker fungiert zum Beispiel erst ab einem bestimmten Firmwarestand als Repeater im Mesh-Netzwerk.

Der Update-Weg über die CCU2

Zum Updaten gibt es zwei Möglichkeiten: Einen Funk-Konfigurationsstick für USB oder die CCU2 Zentrale von eQ-3. Ich habe mir die CCU2 besorgt. Der Ablauf pro Gerät sieht so aus:

1. Gerät vom Telekom SmartHome ablernen
2. Gerät an der CCU2 anlernen
3. Firmware-Update durchführen
4. Gerät von der CCU2 ablernen
5. Gerät am Telekom SmartHome wieder anlernen

Das ist aufwendig. Für jedes einzelne Gerät. Und bei den HomeMatic IP Geräten dauert ein Firmware-Update zwischen 8 und 42 Stunden. Die Firmware ist dabei knapp über 100 KB groß. Bei den älteren HomeMatic-Geräten ist das gleiche Update in fünf Minuten erledigt. Warum der Funkweg bei den IP-Geräten so langsam ist, erschließt sich mir nicht.

Warum nicht gleich die CCU2?

Das Telekom SmartHome hat einen Vorteil der schwer wiegt: Man kann Geräte verschiedener Hersteller miteinander kombinieren. HomeMatic, Philips Hue, Schellenberg Rolladen, DECT-Steckdosen. Das können die reinen eQ-3 Lösungen wie CCU2 mit Orbylon oder pocket control nicht in dem Umfang. Dafür nimmt man den umständlichen Firmware-Update-Prozess in Kauf.

Fragen? Einfach melden.

DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten

22. Dezember 2017 / / Keine Kommentare

DNS-Abfragen laufen normalerweise im Klartext über UDP Port 53. Jeder der den Traffic mitlesen kann (ISP, Hotspot-Betreiber, Geheimdienst) sieht welche Domains aufgelöst werden. RFC 7858 definiert DNS over TLS (DoT): DNS-Abfragen über eine TLS-verschlüsselte TCP-Verbindung auf Port 853.

BIND9 konnte zum Zeitpunkt dieses Beitrags kein natives DoT. Die Lösung: stunnel als TLS-Wrapper vor den BIND stellen. stunnel terminiert die TLS-Verbindung auf Port 853 und leitet die entschlüsselten DNS-Pakete an BIND auf Port 53 weiter.

Stunnel-Konfiguration

Unter FreeBSD liegt die Konfiguration in /usr/local/etc/stunnel/conf.d/. Für IPv4 und IPv6 jeweils eine Sektion:

# /usr/local/etc/stunnel/conf.d/dnstls.conf

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt

[dns6]
accept = :::853
connect = ::1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt

accept ist der Port auf dem stunnel lauscht (853 = DoT-Standard). connect ist der lokale BIND9. Das Zertifikat muss für den Hostnamen des DNS-Servers gültig sein, sonst schlägt die Validierung auf der Client-Seite fehl.

Testen

TLS-Verbindung prüfen:

openssl s_client -connect ns1.kernel-error.de:853

In der Ausgabe sollte Verify return code: 0 (ok) stehen und eine TLS-1.2- oder TLS-1.3-Verbindung angezeigt werden.

DNS-Abfrage über TLS mit getdns_query (in den FreeBSD-Ports als getdns):

getdns_query @ns1.kernel-error.de -s -a -A -l L www.kernel-error.de AAAA

Die Option -l L erzwingt TLS. Bei Erfolg kommt ein JSON-Objekt mit "status": GETDNS_RESPSTATUS_GOOD und der aufgelösten Adresse zurück. Alternativ kann man mit kdig (aus dem Paket knot-utils) testen:

kdig +tls @ns1.kernel-error.de www.kernel-error.de AAAA

Clients

Android 9+ hat DoT nativ eingebaut (Einstellungen → Netzwerk → Privates DNS). Dort den Hostnamen des eigenen DNS-Servers eintragen. Unter Linux kann systemd-resolved DoT, oder man nutzt stubby als lokalen DoT-Proxy.

Weiterentwicklung

Neben DoT gibt es inzwischen auch DNS over HTTPS (DoH), das DNS-Abfragen über HTTPS auf Port 443 tunnelt. DoH hat den Vorteil, dass es durch Firewalls und Proxies nicht blockiert werden kann, weil es wie normaler HTTPS-Traffic aussieht. Mein DNS-Resolver dns.kernel-error.de bietet inzwischen beides an. Fragen? Einfach melden.

Kaltgang im DataCenter

2. November 2017 / / Keine Kommentare

Ich habe vor kurzem in einem DataCenter gestanden und mir einen „neuen“ Kaltgang angeschaut, bei dem mir wirklich alles aus dem Gesicht gefallen ist.

Was da gebaut wurde

Der Betreiber dieses DataCenters ist groß, international tätig, nennt eine größere zweistellige Zahl an DataCentern sein eigen und ist durchaus namhaft. Dieser Versuch von einem Kaltgang wurde von eben diesem Betreiber gebaut. Nicht für einen vermieteten Cage, sondern ganz trocken für vermietete Rackreihen. Rackreihen, bei denen sie penibel darauf achten, dass auch die einzelnen HE-Blenden eingesetzt werden, damit ein korrekter Luftstrom garantiert ist. Das meinen die wirklich ernst.

Und dann schaut man sich an, was sie als Kaltgangeinhausung gebaut haben. Die Bilder sprechen für sich.

Nein, ich werde nicht sagen, wer der Betreiber ist.

Fragen? Einfach melden.

IPv6 Traffic hat sich verdoppelt

2. November 2017 / / Keine Kommentare

Wenn ich meine Graphen so verfolge sehe ich eine Verdopplung des IPv6 Traffics seit dem Anfang diesen Jahres beim HTTPS Traffic. SMTP ist es nur knapp 50% mehr. Ich würde nun jetzt einfach mal behaupten dass inzwischen viel mehr Enduser mit einer IPv6 Adresse unterwegs sind und Mailserverbetreiber so schnell nicht „nachziehen“.

Mich überrascht dieser starke Anstieg in 2017 etwas daher habe ich nun mal alles gegen meinen IPv4 Traffic gehalten.

Insg. habe ich von meinen Systemen ausgehend 12,5% mehr IPv6 Traffic als IPv4 Traffic. Eingehend habe ich tatsächlich 6% mehr IPv6 Traffic als IPv4 Traffic. OK OK jetzt bin ich dabei sicher nicht repräsentativ… Nur ist in 2017 das Verhältnis zumindest bei mir von IPv4 zu IPv6 gekippt. Jetzt sind alle Systeme bei mir durchgängig IPv6 fähig und alles bewegt sich sicher sehr in seiner eigenen Blase, nicht zu viel herein steigern…

Gab es da nicht vor Kurzem eine Heise Meldung?

https://www.heise.de/newsticker/meldung/IPv4-Adressen-immer-knapper-Adressklau-sogar-mit-gefaelschter-Sterbeurkunde-3872129.html

Schaue ich mir die großen an sieht man das es mehr wird und vor allem auch bei uns in Deutschland:

https://www.google.de/ipv6/statistics.html

https://stats.labs.apnic.net/ipv6

Mit einigen Bekannten habe ich ebenfalls gesprochen, hier zeigt sich ein sehr ähnliches Bild. Wir bleiben nur immer in der gleichen „Blase“. Mein Brötchengeber wäre noch ein ganz guter und sicher schon ein repräsentativ Statistikgeber, nur leider ist es hier produktiv noch extrem dunkel wenn es um IPv6 geht. 🙁 Hier gibt es gerade andere Baustellen.

Wie ist es denn bei euch? Jemand ein paar Zahlen oder Links für mich?

Update

Na schau an, eine erste Anregung habe ich schon mal. Mobile Endgeräte... Wenn man nicht gerade bei der Telekom ist sind viele noch mit ihren Smartphones auf IPv4 festgebunden. Statistiken von google/facebook/twitter usw. wird dieses sicher stark verfälschen. Wobei *grübel* verfälschen? Ist „das Internet“ (ich denke gerade an The IT Crowd) nicht inzwischen eher Smartphone? Benutzer mit einem Smartphone werden meine Webseite kaum anschauen, denn sie sieht mit so einem Gerät noch viel schlimmer aus als sie es bereits mit einem normalen Browser tut.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

RFC 7858 – DNS over Transport Layer Security

30. Oktober 2017 / / Keine Kommentare

Ich habe in den letzten Tagen etwas mit dem RFC 7858 (https://tools.ietf.org/html/rfc7858) herumgespielt. Meine Zonen und auch Dienste sind per DNSsec, HSTS, Pinning usw. usw. abgesichert. Warum also noch DNS per TLS? Nun ja… Sinn macht es sicher keinen, bei mir ist nichts spannendes zu finden und kaum ein Besucher wird mit Problemen rechnen müssen wenn er hier ist. Für mich sollte Kryptographie nicht die Ausnahme sondern der Normalzustand sein. RFC 7858 ist da nur ein weiteres Detail. In einer DNS Abfrage finden sich selten geheime Daten. Klar wäre es schlecht wenn diese verändert würden um diese zu verhindern reicht eine Signatur. Das mitlesen der DNS Abfragen würde einer dritten Person so aber offenlegen wo man surft und welche Dienste man nutzt. Sind diese Abfragen per TLS verschlüsselt bleibt dieses geheim. Daher macht es wohl am meisten Sinn es für seinen lokalen DNS Resolver zu nutzen oder es auf großen DNS Servern zu aktivieren. DNS Servern welche sich um viele Zonen kümmern….

Um irgendwo zu starten und selbst einen Eindruck davon zu bekommen habe ich es auf meinen DNS Servern für meine Zonen aktiviert. Bis auf ns2.kernel-error.org haben die Server gültige Zertifikate. Bei ns2.kernel-error.org muss ich mal schauen wie es sich entwickelt.

Als Test:

$ getdns_query -s www.kernel-error.de a @176.9.109.53 -l L

Viel Spaß

Siehe auch: DoT und DoH mit BIND 9.20

Fragen? Einfach melden.

Sanftanlauf für Elektromotoren: Softstart & Anlaufstrombegrenzer

12. August 2017 / / Keine Kommentare

In meiner Werkstatt habe ich ein paar Elektrogeräte für welche ich gerne einen Sanftanlauf hätte. Einmal um den „Druck“ den hohen Anlaufstrom etwas von den ~Sicherungen~ zu nehmen und dann natürlich um die Geräte an sich etwas zu schonen, denn ein schlagartig anlaufender Elektromotor haut schon ganz schön rein.

Natürlich gibt es viele schöne Dinge, die man einfach kaufen und zwischen stecken/einbauen kann aber ich wollte selbst einmal überlegen wie ich es realisieren kann und vor allem mit dem Zeug aus meiner „Restekiste“. So bin ich auf folgende Schaltung für meine Absauganlage gekommen. Die Anlage bekommt nur Strom, wenn ein anders Elektrogerät eingeschaltet wird und schaltet mit einem gewissen Nachlauf selbst ab (diese Schaltung führe ich vielleicht auch mal irgendwann auf). Es funktioniert also nicht diese einfach immer unter Strom zwischen zu stecken! Oh und natürlich sind Arbeiten am Strom sehr gefährlich und dürfen nur von Menschen ausgeführt werden, welche dieses dürfen. Diese Beschreibung also nicht nachmachen!

Schaltplan für einen 240V Sanftanlauf für Elektromotoren.

C1 und R1 arbeiten in der Schaltung als eine Art Kondensatornetzteil. D1 – D4 übernehmen die Aufgabe des Gleichrichters. R2 sorgt dafür, dass beim Abschalten die Schaltung möglichst schnell spannungsfrei ist (die Kondensatoren also entladen werden). C2 glättet die Spannung aus dem Gleichrichter, D5 nagelt die Spannung in der Schaltung auf ca. 18V fest. Über R3 wird C3 langsam geladen. R4 sorgt wieder für schnelles Entladen von C3. D6 schützt Q1 vor der Spule in K1, R5 ist die eigentliche „Handbremse“ für den nachgeschalteten Elektromotor. Er lässt, bis zum anziehen des Relais weniger durch und der Motor kann nicht mit voller Power loslegen.

Kommt also Spannung auf die Schaltung wird diese so lang über R5 zum Motor geleitet, bis C3 geladen ist. Denn wenn C3 voll ist, schaltet Q1 durch und somit zieht K1 an und überbrückt so R5.

R5 muss daher auf den nach gelagerten Elektromotor abgestimmt sein, sonst platzt R5 ggf. einfach. Die Größe von C3 bestimmt hierbei die Länge der Verzögerung von K1. 220μF war dabei für mich etwas zu klein. 440μF ist die perfekte Zeit

Die Platine selbst sieht nun so aus.

Selbstgebaute Platine für einen 240V Sanftanlauf für Elektromotoren.

Oh, die Absauganlage besteht aus einem Nassauger von Kärcher hinter einem selbstgebauten Zyklonabscheider.

Fragen? Dann fragen.

Siehe auch: Softstart-Modul für 230V

Fragen? Einfach melden.

ioping: Read- und Write-Latency schnell messen

8. August 2017 / / Keine Kommentare

Für ausführliche Storage-Benchmarks gibt es Tools wie bonnie++ oder fio. Wenn man nur schnell die Read- oder Write-Latency eines Dateisystems prüfen will, reicht ioping — ein einzelner Befehl, Ergebnis in Sekunden.

Installation

# FreeBSD
pkg install ioping

# Debian/Ubuntu
apt install ioping

Read-Latency messen

ioping -s 256k -T 120 -D -c 20 ./
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=1 time=16.0 us (warmup)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=2 time=35.7 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=3 time=45.8 us
...

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 853.7 us, 4.75 MiB read, 22.3 k iops, 5.43 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.2 KiB/s
min/avg/max/mdev = 35.7 us / 44.9 us / 52.8 us / 3.85 us

Die Parameter im Detail:

  • -s 256k — Blockgröße pro Request (hier 256 KiB)
  • -T 120 — Timeout in Sekunden, Requests die länger brauchen werden ignoriert
  • -D — Direct I/O, umgeht den Kernel-Cache (misst die echte Disk-Latency)
  • -c 20 — Anzahl der Requests
  • ./ — Pfad zum Dateisystem das gemessen werden soll

Die Summary am Ende zeigt min/avg/max/mdev — genau wie bei ping. Hier: durchschnittlich 44,9 µs Read-Latency auf einem ZFS-Dataset.

Write-Latency messen

Für die Write-Latency kommt ein einziger Parameter dazu — -W:

ioping -s 256k -T 120 -D -W -c 20 ./
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=1 time=27.0 us (warmup)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=2 time=54.4 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=3 time=60.6 us
...

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 3.86 ms, 4.75 MiB written, 4.93 k iops, 1.20 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.5 KiB/s
min/avg/max/mdev = 51.6 us / 202.9 us / 2.65 ms / 577.9 us

Write ist hier erwartungsgemäß langsamer — 202,9 µs im Schnitt gegenüber 44,9 µs beim Lesen. Die höhere Standardabweichung (577,9 µs vs. 3,85 µs) zeigt, dass einzelne Writes deutlich länger dauern können (hier ein Ausreißer mit 2,65 ms — vermutlich ein ZFS Transaction Group Commit).

Weitere nützliche Optionen

# Fortlaufend messen (wie ping ohne -c)
ioping -D ./

# Nur die Summary nach 10 Requests
ioping -D -c 10 -q ./

# Bestimmte Blockgröße (4k für Random I/O)
ioping -s 4k -D -c 20 ./

# Netzlaufwerk / NFS-Mount testen
ioping -D -c 20 /mnt/nfs-share/

Praktisch für einen schnellen Vergleich: Lokale SSD, NFS-Share und USB-Platte mit dem gleichen Befehl messen — die Unterschiede werden sofort sichtbar. Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑