-=Kernel-Error=-

Mein Datenhaufen zu IT und Elektronik Themen.

Autor: kernel-error (Seite 1 von 47)

FritzBox-7590

Meine FRITZ!Box 7590 und die Spannungswandler

14. Oktober 2024 / / Keine Kommentare

Eigentlich sollte die Überschrift heißen: Ärgere ich mich gerade über mich selbst oder über AVM?

Zuhause arbeitete eine FRITZ!Box 7590 KA, die zu Beginn mit einem Frixtender erweitert wurde. Nach knapp zwei Jahren habe ich bemerkt, dass die FRITZ!Box angefangen hat zu fiepen. Eine Funktionseinschränkung konnte ich jedoch nicht feststellen. Da es aber knapp vor dem Ablauf der Garantie war, habe ich Kontakt mit dem AVM-Support aufgenommen.

Dem AVM-Support habe ich in einer kurzen E-Mail geschildert, dass meine Box plötzlich fiept und ob ihnen in diesem Zusammenhang vielleicht Probleme, beispielsweise mit Spulen oder Spannungsreglern, bekannt sind. Die Antwort vom AVM-Support ließ nicht lange auf sich warten und lautete zusammengefasst: „Nein, uns sind keine Probleme bekannt, aber du kannst deine Box gerne zur Überprüfung/Austausch einschicken.“

Jetzt kommen wir zum Punkt, warum ich mich ärgere und unschlüssig bin, ob ich mich über mich selbst oder über AVM ärgere. Für meine Arbeit benötige ich eine funktionsfähige Internetverbindung. Wenn ich die Box einschicke, muss ich für eine Alternative sorgen. Wenn AVM die Box vorsorglich gegen eine neue tauscht, wäre das zwar schön, aber es gibt schon zu viel Elektroschrott. Elektronik darf Geräusche machen. Spulen könnt ihr euch oft wie eine Art Schwungrad vorstellen. Es braucht etwas, um anzulaufen, läuft dann aber auch noch einige Zeit weiter, selbst wenn es niemand mehr antreibt. Das hängt mit den aufkommenden Magnetfeldern zusammen und ist so gewollt. Magneten kennt ihr, und dass dort Kräfte an den Bauteilen ziehen, könnt ihr euch jetzt ebenfalls vorstellen. Eine Spule kann also mit der Zeit anfangen, leichte Geräusche zu machen, und das ist auch okay. Für Spannungsregler gilt das ebenfalls. Stellt euch einfach euren Wasserhahn vor: Wenn ihr ihn voll aufdreht, kommen da vielleicht 5 Liter in der Minute heraus. Wenn ihr weniger Wasser wollt, macht ihr den Hahn ganz schnell an und wieder aus. Wie schnell ihr das Wasser ein- bzw. ausschalten müsst, um beispielsweise nur 1 Liter pro Minute fließen zu lassen, messt ihr mit euren Augen. Ganz grob funktionieren Schaltnetzteile so. Je nach Last kann man da also schon mal etwas hören, und das ist okay.

So ist ein weiteres Jahr ins Land gegangen, bis mir in einem meiner Newsticker die Meldung über sterbende FRITZ!Boxen vom Typ 7590 aufgefallen ist. Hier wird von anfänglichem Fiepen, schlechter werdendem 2,4-GHz-WLAN bis hin zum Totalausfall des WLANs und der Box berichtet. Bääähhhhh. Das klang verdächtig nach dem von mir beobachteten Fehlerbild. Nun ist meine Box aus jeglicher Garantie und Gewährleistung heraus. Den AVM-Support brauche ich also nicht mehr zu bemühen, sondern kann mich vielmehr mit dem Gedanken anfreunden, eine neue Box zu kaufen, um auf einen Ausfall vorbereitet zu sein. Zeitgleich haben bei uns im Ort die Arbeiten am Glasfaserausbau begonnen. Diese gehen so schnell und gut voran, dass ich damit rechnen kann, bis zum Ende dieses Jahres von DSL auf Glasfaser wechseln zu können. Mit diesem Wechsel kommt vom Anbieter auch eine neue FRITZ!Box. Tjo… Also Risiko eingehen oder eine Box kaufen, die in 5 oder 6 Monaten dann wohl irgendwo im Regal Staub fängt?

Bevor es eine Antwort auf diese Frage gibt, noch schnell zum Punkt mit dem Ärgern: Ich habe AVM bewusst gefragt, ob es bekannte Probleme mit der Box gibt und speziell auf die aus meiner Sicht verdächtigen Bauteile hingewiesen. Die Antwort war ein klares Nein. Das muss ich jetzt einfach so glauben, aber ich werde den Beigeschmack nicht los, dass es zum Zeitpunkt meiner Supportanfrage schon einige Reklamationen wegen dieses Problems gegeben haben müsste. Daher wohl mein möglicher Ärger über AVM – und dass ich auf die Möglichkeit eines Austauschs verzichtet habe – und der Ärger über mich selbst.

Habe ich jetzt eine neue Box gekauft oder nicht? Nein, habe ich natürlich nicht. Ich habe meine Box von der Wand genommen, aufgeschraubt und durchgemessen. Ja, Geräusche und etwas zu hohe Spannung für das 2,4-GHz-WLAN habe ich gemessen bzw. zuordnen können. Alles aber noch im Rahmen, sodass ich gehofft habe, dass es noch ein paar Monate gutgeht. War leider nicht so. Vor ein paar Wochen ist die Box an der Wand „geplatzt“ und ich musste in den sauren Apfel beißen und eine neue für den Übergang kaufen. Jetzt habe ich wohl ein Backup für die Zukunft. Woohoo 🙁 Manchmal lerne ich nicht so schnell dazu, oder? Naja, manchmal kommt halt eins zum anderen.

Ob meine alte Box wirklich mit genau dem beschriebenen Problem ausgefallen ist, wollte ich dennoch herausfinden. Die Sichtprüfung war noch immer gut, aber es war keine Spannung mehr zu messen. Daher habe ich mir von Aliexpress ein paar MP1477 (die genaue Bezeichnung ist MP1477GTF-Z) zuschicken lassen. Ich habe direkt alle drei verbauten Chips ausgetauscht und siehe da, die Box lebt wieder. Oft sollen dabei wohl noch die RF FRONT ENDs 055F als Folge der zu hohen Spannung sterben, aber diese haben es bei mir zum Glück überlebt.

Nun habe ich also auch noch ein Backup für das zukünftige Backup. Super…

Da ich bei Aliexpress insgesamt 10 Stück bestellt habe, liegen hier jetzt noch ein paar herum. Ich wäre bereit, sie gegen ein Snickers zu tauschen, falls jemand von euch vor einem ähnlichen Problem steht. Uhh, und bedenkt bitte, dass die Dinger ECHT klein sind. Ich habe euch mal einen auf ein 1-Cent-Stück gelegt. Ohne Heißluftstation und etwas SMD-Löterfahrung solltet ihr das vielleicht lieber nicht angehen.

Die Messpunkte und die erwarteten Spannungen findet ihr im folgenden Bildchen.

Wenn ihr dann noch Fragen habt, fragt einfach 🙂

FNIRIS GC-01

Nuclear Radiation Detector FNIRSI GC-01 – Upgrade

13. Oktober 2024 / / Keine Kommentare

Bei meinen letzten Einkaufstouren auf Aliexpress ist mir immer mal wieder ein FNIRSI GC-01 Nuclear Radiation Detector, sprich Geigerzähler vorgeschlagen worden. Was soll ich sagen, japp hat funktioniert, irgendwann habe ich das Teil tatsächlich einfach für knapp 30€ mit im Einkaufswagen gehabt. Nach ein paar Spielerreien ging mir aber schnell die Batterielebensdauer auf die Nerven, denn das Teil war im grunde immer leer. Da mich, wie immer, brennend interessiert, was denn da überhaupt verbaut ist, habe ich es mir etwas näher angesehen und schnell festgestellt, dass man noch ein paar Veränderungen vornehmen kann. Darum soll es in diesem Beitrag gehen.

Das Gerät kam mit einem J613 Geiger-Müller-Zählrohr. Dieses ist in der Lage Beta- und Gamma-Strahlung zu erfassen. J613 braucht eine Betriebsspannung von 300 bis 400 Volt und ist ganz gut darin auch niedrige Stralungsniveaus zu messen. Die Platine des GC-01 ist recht simpel aufgebaut. Es hat ein kleines PSU, welches vom USB-C Anschluss oder vom 3.7V Akku eine Spannung von ca. 130V AC aufbaut (ich hab den Teil mal mit einer 1 markiert). Dieses fütter dann einen 3-Stage Multiplier (2) und schon kommen die knapp 400V zusammen. Eine kleine CR1220 Knopfzellenbatterie sorgt dafür, dass der Speicher für Uhrzeit und Messwerte gehalten wird. Dann ist da noch ein kleiner CH32F103 (3). Das kann aber auch mal ein ARM MCU sein, kommt auf die Version an. Der eigentliche 3.7V Akku kommt bei mir mit 1100mAh, also knapp 4Wh, was die geringe Laufzeit erklären sollte. Es gibt noch einen kleinen Piezo Tongeber, welcher für die für einen Geigerzähler bekannten Knackgeräusche sorgt, wenn ein Teilchen „gezählt“ wird. Nahe der MCU sind noch vier „Löcher“ in der Platine, welche als JP1 beschriftet sind. Wie sich heraus stellte, ist dieses ein ST-Link Connector und von link nach rechts sind es die Pins +3.3V, SWDIO, SWCLK, GND. Das wird etwas später noch spannend.

Was mir ebenfalls recht schnell aufgefallen ist, ist dass scheinbar nicht jedes Teilchen ein hörbares Knacken auslöst. Zwar findet sich über dem Display noch eine kleine rote LED, welche passen zu den Teilchen aufblinkt aber halt nicht das Knacken. Der Soundgeber scheint auschließlich per Firmware angesteuert zu werden und die Entwickler haben anders entschieden. 😉

Im Internet habe ich ein paar Modifikation per Widerstand, Transistor usw. gesehen um eine Verbindung zwischen LED und Piezo Soundgeber zu löten, damit diese auch immer Geräusche von sich gibt. Ich bin aber bei Firmware hängen geblieben. Zum einen gibt es eine doch leistungsstarke MCU, dann noch eine USB-C Schnittstelle, bei welcher die Datenleitungen bis zur MCU reichen und natürlich noch den ST-Link.

Schalte ich das Gerät aus, schließe es per USB-C an meinen Computer an und schalte es ein taucht ein Laufwerk mit einem leeren Textfile auf. Irgendwas muss da also gehen. Da war nun wieder der Punkt an welchem ich nicht los lassen konnte.

Die CR1220 kam schon etwas verbraucht an und wurde von mir gegen eine frische ersetzt. Für den kleinen 1100mAh Akku hat sich ebenfalls ein günstiger und vor allem ins Gehäuse passender Ersatz mit immerhin 2200mAh gefunden. Dieser sollte die Autonomiezeit fast verdoppeln. Das J613 ist im grunde sehr gut für seinen Zweck, ich hatte da aber noch ein SBM-20 von einem früheren Projekt in meiner Schublade liegen. Das SBM-20 braucht eine Betriebsspannung von 380 bis 450V und hat eine sehr ähnliche Bauform. Ebenfalls erfasst es Beta- und Gamma-Strahlung. Es ist zwar bei geringeren Strahlungen nicht gaaanz so genau wie das J613 und das Fenster für Beta-Strahlung ist etwas kleiner aber hey, dafür ist das Ding fast unkaputtbar und wenn ich der Firmware irgendwie mitteilen kann, was ich da eingebaut habe, dann sollte sich Vieles durch berechnungen in der Firmware doch ausgleichen lassen, oder?

Firmware….
Ein Datalogger wäre toll, damit ich einfach jeden Tag, jede Stunde oder so kurz den aktuellen Messwert wegschreiben kann. Dann könnte ich über einen laaangen Zeitraum eine Kurve zeichnen. Wenn ich dann noch irgendwie den Stromverbrauch beeinflussen könnte, denn das Display muss ja nicht 24/4 leuchten. Vielleicht noch etwas um die normale Hintergrundstrahlung heraus zu filtern?! So Kleinigkeiten welche mir in der Stock Firmware irgendwie fehlen. Aber vielleicht gibt es ja inzwischen ein Update vom Herstellen oder ich kann da was auslesen und selbst schreiben, mal schauen.

Die Recerche hat mich recht schnell zu einem GitHub repro gebracht. Rad Pro, da hat sich schon jemand mit einer alternativen Firmware für verschiedene Geräte beschäftigt. Selbst Dinge über welche ich noch nicht im Ansatz nachgedacht habe, werden dort erfüllt bzw. gelöst. Öhm also was soll ich sagen? Ich hab einfach gemacht, was dort in der sehr überschaubaren Anleitung steht und geht einfach! Naja, fast. der Weg über das USB Laufwerk hat nicht so wirklich funktioniert. Am Ende habe ich einfach kurz eine Stiftleiste für den ST-Link eingelötet und die neue Firmware über diesen Weg in die MCU gedrückt. Was sich für mich auch irgendwie zuverlässiger anfühlte, vielleicht bin ich da aber auch zu oldschool.

Ein paar Bilder vom Gerät mit der neuen Firmware findet ihr unten.

Viel Spaß beim Basteln und wenn ihr Fragen habt, wie immer einfach fragen.

Google Chrome und die Hardwarebeschleunigung auch als Flatpak

8. Oktober 2024 / / Keine Kommentare

Wer den Chrome-Browser unter Linux für Videocalls oder sogar für Microsoft Teams nutzt, kann meinen Schmerz in Bezug auf die hohe CPU-Auslastung sicherlich nachvollziehen. Wenn ich dann noch meinen Hintergrund im Video unscharf stellen möchte, fühlt es sich an, als wäre mein System mindestens 15 Jahre alt.

Dabei spielt es bei mir keine Rolle, ob ich Chrome direkt aus den Paketquellen oder als Flatpak installiere – die Performance bleibt gleich schlecht.

Bisher habe ich keine endgültige Lösung für dieses Problem gefunden, konnte jedoch zumindest eine gewisse Verbesserung erreichen. Falls also jemand einen Tipp hat, wie man das noch weiter optimieren kann, immer her damit!

Genug der Worte – ihr wollt euch sicher nicht länger mit dem Thema beschäftigen als nötig. Wenn euch Google hierher geführt hat, seid ihr vermutlich bereits genervt von der Performance eures Systems.

Grundlegend müsst ihr zuerst sicherstellen, dass das Tool vainfo in eurer Konsole ohne Fehlermeldung einige Infos ausgibt. In den gängigen Distributionen ist das meist schon „out of the box“ der Fall. Sollte dies bei euch nicht so sein, gibt es unzählige sehr gute Anleitungen dazu, daher gehe ich darauf nicht weiter ein.

Wie viel Hardware-Beschleunigung wir bereits im Browser aktiviert haben, kann uns der Browser selbst verraten. Einfach Chrome starten und chrome://gpu aufrufen. Vor meinen Anpassungen sah das Ergebnis so aus:

Graphics Feature Status

  • Canvas: Hardware accelerated
  • Canvas out-of-process rasterization: Enabled
  • Direct Rendering Display Compositor: Disabled
  • Compositing: Hardware accelerated
  • Multiple Raster Threads: Enabled
  • OpenGL: Enabled
  • Rasterization: Hardware accelerated
  • Raw Draw: Disabled
  • Skia Graphite: Disabled
  • Video Decode: Hardware accelerated
  • Video Encode: Software only. Hardware acceleration disabled
  • Vulkan: Disabled
  • WebGL: Hardware accelerated
  • WebGL2: Hardware accelerated
  • WebGPU: Disabled
  • WebNN: Enabled

Nach den Änderungen sieht es nun folgendermaßen aus:

Graphics Feature Status

  • Canvas: Hardware accelerated
  • Canvas out-of-process rasterization: Enabled
  • Direct Rendering Display Compositor: Disabled
  • Compositing: Hardware accelerated
  • Multiple Raster Threads: Enabled
  • OpenGL: Enabled
  • Rasterization: Hardware accelerated on all pages
  • Raw Draw: Disabled
  • Skia Graphite: Disabled
  • Video Decode: Hardware accelerated
  • Video Encode: Hardware accelerated
  • Vulkan: Enabled
  • WebGL: Hardware accelerated
  • WebGL2: Hardware accelerated
  • WebGPU: Hardware accelerated
  • WebNN: Enabled

Um dies zu erreichen, legt einfach die folgende Konfigurationsdatei an bzw. passt sie an:

Für Chrome und Chromium aus den Paketquellen: ~/.config/chromium-flags.conf
Für Chrome und Chromium als Flatpak: ~/.var/app/com.google.Chrome/config/chrome-flags.conf

--ignore-gpu-blocklist
--enable-zero-copy
--enable-gpu-rasterization
--enable-unsafe-webgpu
--enable-gpu-compositing
--enable-smooth-scrolling
--canvas-oop-rasterization
--disable-direct-compositionr-bug-workarounds
--enable-features=VaapiVideoDecoder,VaapiIgnoreDriverChecks,Vulkan,DefaultANGLEVulkan,VulkanFromANGLE,UseOzonePlatform,VaapiVideoEncoder

Ein kleiner Tipp zur einfacheren Anpassung der allgemeinen Konfiguration von Flatpaks: Schaut euch mal das Tool „Flatseal“ an.

Viel Spaß!

FreeBSD SSH Server mit MFA 2FA

29. März 2024 / / Keine Kommentare

Dass man eigentlich keinen reinen Kennwort-Login für seine Anmeldung an einem SSH-Server haben möchte, ist sicherlich bei fast allen angekommen. Kennwörter lassen sich einfacher mittels eines Brute-Force-Angriffes herausfinden. Ebenso gehen diese auch mal verloren. SSH-Keys werden die meisten ebenfalls bereits aufseiten des Clients mit einem zweiten Faktor geschützt haben. Dies kann ein MFA-Token sein oder einfach eine Passphrase.

Hin und wieder lässt es sich aber nicht vermeiden, dass man seinen Login nur mit einer einfachen Kombination aus Benutzername und Kennwort sichert. Um dieses dennoch etwas aufzuwerten, lässt sich dieses ebenfalls mit MFA ausstatten. In diesem kurzen Beispiel geht es dabei um einen SSH-Server auf einem FreeBSD-System, welches nach der Authentifizierung mittels Benutzername/Kennwort noch nach einem Auth-Code vom Google Authenticator fragt.

Clientseitig ist eigentlich nichts weiter zu beachten. Auf Serverseite muss das Paket pam_google_authenticator installiert werden:

pkg install pam_google_authenticator

Ist die Installation abgeschlossen, müssen wir nun unsere PAM-Konfiguration für den SSHD-Password-Login erweitern. Oh, ja… Auf demselben Weg lässt sich dieses ebenfalls für den normalen Login an der Konsole, für su, ftp usw. einbinden. Selbstverständlich ebenfalls für den Login per SSH-Keys. Wir bleiben aber hier nun beim Login mit User/Pass. Meine /etc/pam.d/sshd sieht damit wie folgt aus:

#
#
# PAM configuration for the "sshd" service
#

# auth
#auth		sufficient	pam_krb5.so		no_warn try_first_pass
#auth		sufficient	pam_ssh.so		no_warn try_first_pass
auth		required	pam_unix.so		no_warn try_first_pass
auth            required        /usr/local/lib/pam_google_authenticator.so

# account
account		required	pam_nologin.so
#account	required	pam_krb5.so
account		required	pam_login_access.so
account		required	pam_unix.so

# session
#session	optional	pam_ssh.so		want_agent
session		required	pam_permit.so

# password
#password	sufficient	pam_krb5.so		no_warn try_first_pass
password	required	pam_unix.so		no_warn try_first_pass

Ebenfalls muss die folgende Option in der /etc/ssh/sshd_config aktiviert sein:

ChallengeResponseAuthentication yes

Das war es auch schon fast. Wenn man nun auf seinem Smartphone noch schnell den Google Authenticator installiert, können wir schon damit beginnen, den zweiten Faktor zu erstellen. Dafür einfach mit dem gewünschten Nutzer in dessen Home-Verzeichnis: „cd ~“ den google-authenticator aufrufen und den Anweisungen folgen:

Dieses nur noch mit der Authenticator-App am Smartphone scannen, den Code einmal eingeben und schon wird man bei jedem Kennwort-Login nach seinem aktuellen Code gefragt.

Oh, sehr ähnlich ist die Einrichtung unter Linux 🙂

Linux Mint / Ubuntu und DNSSEC

29. März 2024 / / Keine Kommentare

Heute habe ich versucht, mich von meiner neuen Linux Mint Installation aus mit einem meiner SSH-Server zu verbinden. Mein SSH-Client hat mich direkt mit der Frage begrüßt, ob ich dem neuen Hostkey vertrauen möchte oder nicht.

ssh username@hostname.kernel-error.org
The authenticity of host 'hostname.kernel-error.org (2a01:5a8:362:4416::32)' can't be established.
ED25519 key fingerprint is SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Für viele mag diese Meldung bekannt und vollkommen normal erscheinen. In der Regel antwortet man initial mit „yes“ und sieht sie nie wieder. Aber diese Meldung hat ihren Grund. Beim initialen Aufbau einer Verbindung zu einem SSH-Server wird einem der Fingerprint des HostKeys angezeigt. So hat man die Möglichkeit, den Fingerprint mit dem erwarteten Fingerprint abzugleichen, um sicherzustellen, dass man sich wirklich mit dem gewünschten SSH-Server verbindet und nicht etwa ein Angreifer Zugangsdaten abfischt. Wenn man eh immer nur „JA“ sagt, könnte man diesen Check auch direkt in seiner ~/.ssh/config mit folgendem Eintrag deaktivieren:

Host *
    StrictHostKeyChecking no

Warum erzähle ich das alles? Nun, weil es für mich eigentlich nicht normal ist, diese Meldung zu sehen. Denn es gibt die Möglichkeit, die Fingerprints der erwarteten HostKeys in seiner DNS-Zone zu hinterlegen und seinen SSH-Client mit der folgenden Konfiguration in seiner ~/.ssh/config anzuweisen, dies einfach selbst zu überprüfen, sofern der SSH-Client eine vertrauenswürdige Antwort vom DNS-Server erhält.

Host *
   VerifyHostKeyDNS yes

Vertrauenswürdige Antwort vom DNS-Server… Hier sind wir schon bei DNSSEC angekommen. Meine DNS-Server, einschließlich des lokalen Resolvers auf meinem Router, unterstützen alle DNSSEC. Meine SSH-Client-Konfiguration ist korrekt und dennoch erscheint die Meldung…. Also habe ich den Verbindungsaufbau mit etwas mehr Debugging-Output gestartet, was bei ssh einfach die zusätzliche Option -vvv bedeutet:

ssh usermane@hostname.kernel-error.org -vvv
[...]
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu
debug3: verify_host_key_dns
debug1: found 2 insecure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
[...]

Zu meiner Überraschung sehe ich:

debug1: found 2 insecure fingerprints in DNS

Hm… „insecure“… Er hat also die passenden Einträge in der DNS-Zone gefunden, kann diesen aber nicht vertrauen, weil… ja, warum? Die Antwort des DNS-Servers ist nicht vertrauenswürdig? OK, das lässt sich einfach mit dig und der Option +dnssec testen. Wir suchen einfach im Header nach „ad„:

dig +dnssec hostname.kernel-error.org @8.8.8.8

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +dnssec hostname.kernel-error.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48645
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[...]

@8.8.8.8 gibt an, dass direkt der öffentliche DNS-Server von Google gefragt wird. Dieser wird natürlich meine Server fragen usw., einfach um sicherzugehen, dass meine eigentlichen DNS-Server, die für die Zone zuständig sind, sauber konfiguriert sind. Ich sehe ein „ad„, also ist dort schon mal alles gut. Im Anschluss habe ich den Test noch mit meinem lokalen DNS-Resolver auf dem Router durchgeführt. Also einfach @192.168.0.1 oder was auch immer euer lokaler Router ist. Gleiches Ergebnis…. Aber warum will dann mein Linux Mint nicht? Sollte Linux Mint etwa kein DNSSEC können?

dig +dnssec hostname.kernel-error.org

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> +dnssec hostname.kernel-error.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1789
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
[...]

Öhhh ähhh… Ja, öhm, geht nicht… Aber warum? Was steht denn in meiner /etc/resolv.conf? 127.0.0.53? Ohhhhhhhh, stimmt! systemd-resolv! OK, ok… Ich könnte also in meiner /etc/systemd/resolved.conf nun einfach DNSSEC=yes setzen und mit einem systemctl restart systemd-resolved sollte dann… Nope, leider nicht. Nun geht überhaupt keine DNS-Auflösung mehr. Es scheint am eingesetzten Stub-Resolver zu liegen, den man ebenfalls noch ändern kann usw… Nennt mich etwas oldschool, aber für meine Zwecke reicht der klassische Weg über die vom NetworkManager gepflegte resolv.conf. Um also systemd-resolved zu deaktivieren und auf den NetworkManager zu wechseln, sind die folgenden Schritte nötig:

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo rm /etc/resolv.conf

Dann in die Konfigurationsdatei vom NetworkManager /etc/NetworkManager/NetworkManager.conf in der [main]-Sektion die folgende Option setzen:

dns=default

Nun nur noch den NetworkManager neu starten und schon sollte die /etc/resolv.conf mit den DNS-Informationen gefüttert werden:

sudo systemctl restart NetworkManager
cat /etc/resolv.conf
# Generated by NetworkManager
search kernel-error.local
nameserver 10.10.88.1
nameserver fd00:424e:6eff:f525:454e:6eff:f525:4241

Perfekt! Also los, noch ein Versuch mit dem SSH-Client und… nichts… DNS-Auflösung funktioniert, aber es ist noch immer „insecure„. Stimmt! Es fehlt etwas in meiner resolv.conf. Wir brauchen bestimmt noch die folgende Option:

options edns0

Jetzt aber! HA, dig ist schon mal glücklich, ich sehe ein „ad“. Ähm, aber der SSH-Client noch immer nicht?! Was zum… OK, OK… Irgendwas um SSH muss ich vergessen haben. Aber was? Wie macht SSH das überhaupt? Vielleicht gibt mir das eine Idee. Also, mal kurz in den Code geschaut, C bekomme ich gerade noch hin:

        /* Check for authenticated data */
        if (ldns_pkt_ad(pkt)) {
                rrset->rri_flags |= RRSET_VALIDATED;
        } else { /* AD is not set, try autonomous validation */
                ldns_rr_list * trusted_keys = ldns_rr_list_new();

                debug2("ldns: trying to validate RRset");
                /* Get eventual sigs */
                rrsigs = ldns_pkt_rr_list_by_type(pkt, LDNS_RR_TYPE_RRSIG,
                    LDNS_SECTION_ANSWER);

                rrset->rri_nsigs = ldns_rr_list_rr_count(rrsigs);
                debug2("ldns: got %u signature(s) (RRTYPE %u) from DNS",
                       rrset->rri_nsigs, LDNS_RR_TYPE_RRSIG);

                if ((err = ldns_verify_trusted(ldns_res, rrdata, rrsigs,
                     trusted_keys)) == LDNS_STATUS_OK) {
                        rrset->rri_flags |= RRSET_VALIDATED;
                        debug2("ldns: RRset is signed with a valid key");
                } else {
                        debug2("ldns: RRset validation failed: %s",
                            ldns_get_errorstr_by_id(err));
                }

                ldns_rr_list_deep_free(trusted_keys);
        }

Aaaaaaaaaaaaaaaaaaaaaaa… ldns… woher bekommt er wohl die Trust Keys? Genau… woher? Da fehlt also NOCH etwas in meiner resolv.conf:

options edns0 trust-ad

Und? genau… geht 😀 

ssh usermane@hostname.kernel-error.org -vvv
[...]
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:kTRGVCMRLiHfvJunW2CbW5H3NZmn3Wkx2KnHJXl3iJu
debug3: verify_host_key_dns
debug1: found 2 secure fingerprints in DNS
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug3: verify_host_key_dns: checking SSHFP type 4 fptype 2
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
[...]

Pfff… nun habe ich natürlich die Optionen von Hand in meine resolv.conf eingetragen, der NetworkManager wird diese Option also spätestens beim nächsten Boot rauswerfen. Also muss ich noch meinem NetworkManager beibringen, dass er bitte diese Option ebenfalls in meine resolv.conf schreibt, wenn das jeweilige Netzwerkprofil aktiviert ist. Dazu gibt es aber leider keinen Menüpunkt in der GUI vom NetworkManager, also muss das per CLI gemacht werden. Dieses für IPv4 und IPv6 gleichermaßen, sonst greift es leider nicht!

nmcli conn modify DEINE-PROFIL-UUID ipv4.dns-options edns0,trust-ad
nmcli conn modify DEINE-PROFIL-UUID ipv6.dns-options edns0,trust-ad

Oh, ein nmcli conn show listet die bestehenden und vor allem das aktive Profil inkl. der UUID auf. Davon abgesehen, klappt es nun so und ist rebootfest.

So und nun ihr! Ich bin mit meinem FreeBSD-Wissen an das Thema herangegangen. Wie macht man das als Hardcore-Linux-User und mit systemd-resolved richtig und funktionierend?

VC-64 Turbo Tape (c) 1986 by CIK

29. März 2024 / / Keine Kommentare

In meinem Keller sammelt sich unter anderem die eine oder andere Hardware an, die wohl inzwischen der Retro-Computer-Ecke zugeordnet werden kann. Dazu gehört auch diese Cartridge für den Commodore 64.

Der Name „Turbo Tape“ ist dabei wörtlich zu nehmen. Das kleine Programm, das auf dem IC in der Cartridge gespeichert ist, ermöglicht es, das Lesen und Schreiben auf einem Kassettendeck zu beschleunigen. Ja, früher speicherten wir unsere Programme auf Kassetten.

Da dieses Produkt offenbar von einem kleineren, lokalen Anbieter stammt und ich selbst im Internet nichts weiter darüber finden konnte, möchte ich ihm hiermit eine Bühne bieten, damit es nicht einfach in Vergessenheit gerät.

Der Hersteller ist wohl Computertechnik Ingo Klepsch, Postfach 13 31, 5828 Ennepetal 1. Die Telefonnummer lautete: 0 23 33 / 8 02 02. An der kurzen Postleitzahl erkennt man bereits, dass die Adresse noch vor der Änderung der Postleitzahlen aufgedruckt wurde. Ich habe auch Informationen zum Unternehmen gefunden. Die Ingo Klepsch – CIK – Computertechnik war ein Unternehmen aus Hagen, das am 25.07.1990 im Handelsregister eingetragen und am 24.02.1992 bereits wieder gelöscht wurde. Außerdem habe ich noch Werbung für dieses Unternehmen in der Amiga Kickstart 2-90 gefunden.

Wie auf den Bildern zu erkennen, ist das PCB sehr übersichtlich gestaltet. Es enthält einen Widerstand, ein MC74HC00 als NAND-Gate, einen kleinen Folienkondensator, einen kleinen Schalter und natürlich das Herzstück, den MBM2716 UV-EPROM mit dem eigentlichen Programmcode. Diesen habe ich mit meinem kleinen TL866 II Plus ausgelesen und biete ihn euch ebenfalls unten zum Download an.

Download: MBM2716_VC-64_Turbo_Tape_1986_by_CIK.BIN

QIDI Tec 3D Printer i-mates

QIDI Tech i-mates

5. Juni 2023 / / Ein Kommentar

Ich möchte ein paar Worte über meinen 3D Drucker verlieren. Seit knapp 2 Jahre werkelt bei mir der i-mates von QIDI Tech. Ich habe damals ein paar Testberichte durchgeschaut und bin auf diesen gekommen. Wichtig war mir, ein geringer Preis, beheizbares Druckbett, kompaktes Design, die Möglichkeit eines geschlossenen Druckraumes sowie, dass sich das Druckbett nur in der Z-Achse bewegt und natürlich, dass ich den Standard drucken kann. Also PLA, ABS und PETG.

Bisher bin ich extrem zufrieden mit dem Drucker. Er tut genau, was er soll und für den Preis in guter Qualität. Bis hier finden sich diese Informationen sicherlich besser in verschiedensten Testberichten….

Gekauft habe ich den Drucker direkt bei AliExpress im offiziellen Store von QIDI Tec: https://s.click.aliexpress.com/e/_DFkNgSl

Was sich in den Testberichten selten findet, sind Informationen zum Filament Sensor, einem all oder full metal Extruder/Hotend und diesen nervigen Muttern beim bed leveling, sowie etwas zum Support von QIDI Technology und woher man denn Firmware Upgrades bekommt.

Starten wir mit dem Support, dieser war bisher durchgehen exzellent. Es gibt verschiedene Wege den Support zu erreichen. Für mich funktionierte am besten E-Mail, direkt an: mateb@qd3dprinter.com
Der Support war immer freundlich, immer hilfsbereit, hatte super Infos, Videos, Anleitungen und was man sich sonst noch wünscht. Der Kontakt lief ohne jedes Problem vollständig in englisch. Dateiaustausch wurde in der Regel über google drive realisiert. Wer schon einmal mit Herstellern hinter der Chinesischen Mauer/Firewall Daten austauschen wollte, versteht den Mehrwert von google drive, in dieser Beziehung. Reagiert hat der Support auf meine E-Mails, in der Regeln innerhalb von 24h (selbst an Wochenenden und Feiertagen). Ich will einfach keinen anderen Support mehr haben.

Mein erstes Upgrade für den Drucker war, nach knapp einem Jahr, ein full-metal Extruder. Ebenfalls gekauft bei AliExpress: https://de.aliexpress.com/item/1005003165841775.html

Das nötige Firmware Update gab es direkt beim Support inkl. Anleitung. Einbau war sehr einfach, besondere Einstellungsänderungen waren in der QIDI Print App nicht nötig. Die QIDI Print App basiert auf Cura, wurde aber speziell eingepasst für diesen 3D Drucker.

Mit dem neuen Druckkopf hatte ich leider ein paar Probleme. Die Layerhaftung war schlechter. Hier konnte mir der Support helfen. Nicht jeder Schrittmotor läuft 100%tig gleich. Zusammen mit dem Support habe ich getestet ob bei 2cm Filamentvorschub auch wirklich 2cm bewegt werden, was bei mir nicht der Fall war. Daraufhin habe ich vom Support eine für mich angepasste Konfigurationsdatei bekommen. Diese habe ich einfach „gedruckt“ und schon war dieses Problem Geschichte. Insg. waren das 3 E-Mails und 15 Minuten Arbeit.

Die Schrittmotoren selbst werden beim Druck sehr warm. Nicht zu warm, aber doch so warm, dass ich dem Verlangen nicht nachgeben konnte sie zu kühlen. Dazu habe ich folgende selbstklebende Kühlkörper gefunden: https://s.click.aliexpress.com/e/_DEuRYyh

Diese habe ich an allen Schrittmotoren installiert. Ausgenommen der Druckkopf, dieser wird bereits gut gekühlt und das zusätzliche Gewicht wäre sicherlich nicht hilfreich. Also nur ein Kühlkörper für jede Achse.

Wer die passive Kühlung direkt in eine aktive verwandeln möchte dem findet hier die passenden Lüfter, direkt für 24V: https://s.click.aliexpress.com/e/_Dk6rsrB

Zuletzt fehlte mir noch ein Filament Sensor. Mal bricht das Filament (super selten aber passiert) oder es ist einfach mitten im Druck leer und dann läuft der Drucker einfach weiter. Der Filament Run Sensor bemerkt dieses und stoppt den Druckvorgang. So kann einfach Filament „nachgeladen“ werden und der Druck läuft weiter. Ebenfalls gekauft bei AliExpress: https://s.click.aliexpress.com/e/_DFCISh7

Die Installation ist wieder extrem einfach, vor allem mit der Anleitung des Supportes. Es gab wieder eine Konfigurationsdatei, welche man einfach druckt und schon ist der Filament Sensor funktionstüchtig. OK, in der deutschen Übersetzung nennt sich der Punkt Glühfaden-Sensor… Für den Hinweis auf dieses Übersetzungsproblemchen hat sich der Support sehr gefreut und möglicherweise ist es im nächsten Firmwareupdate bereits ersetzt durch Filament-Sensor.

Bed Leveling… Leider hat dieser Drucker kein automatisches Leveling. Es gibt im Druckmenü eine geführte Funktion und diese ist einfach und kein Problem. Ebenfalls sind die eigentlichen Muttern kein Problem, nur die Sicherung mittels einer weiteren Flügelmutter ist sehr nervig. Man durchläuft das Leveling Programm, stellt alles perfekt ein und sichert die Muttern, unter Zuhilfenahme der Flügelmuttern. Vielleicht habe ich zu dicke Finger aber jedes Mal hat sich der Abstand zur Nozzel dadurch wieder verändert. Die einfachste Lösung war dann für mich folgender Druck von Thingiverse: https://www.thingiverse.com/thing:4806871

Dazu einfach ein paar selbst sichernde M4 Muttern: https://amzn.to/3MU6fCW

Gedruckt habe ich die neuen Leveling Nuts mit PETG… Funktioniert super und Bed Leveling macht fast Spaß, so viel Spaß manuelles Leveling halt machen kann.

Filament… Japp ebenfalls Aliexpress und direkt von QIDI Tec: https://s.click.aliexpress.com/e/_Dk0scHx

Tut und hält 😀

Nozzle… Zusammen mit dem Druckkopf bin ich auf eine Nozzel von Brozzl gewechselt. Einmal braucht meine Nozzel keinen Platz mehr für diesen Plastikschlauch (ist ja nun all metal) und zum anderen wollte ich etwas weg von Messing. Metall ist zwar viel härter, hinsichtlich Abnutzung, aber ich drucke nicht mit Material welches zu hoher Abnutzung führt und die Temperaturleitfähigkeit von Metall ist nicht so wirklich super. Geht, wenn man daran denkt die Temperatur immer +10°C zu nehmen aber beschichtetes Kupfer gefällt mir besser. Noch besserer Wäremeleitwert und sogar noch etwas härter als Messing. Hier der Link zu dem Teil: https://www.brozzl.com/products/plated-copper-nozzles/

Cloudflare deal for $10-11 YubiKeys

14. Oktober 2022 / / Keine Kommentare

Es gibt aktuell einen EEEECCCHHHTTTT guten Deal um günstig an bis zu 10 YubiKeys 5 NFC und/oder 5C NFC zu kommen.

Man benötigt dafür einen Cloudflare Account, der ist ja schnell geklickt. Dann klickt man ein paar Links und wartet auf eine E-Mail mit seinem Discount Code.

Da die Keys in der Regel etwas um die 50€ Kosten, ist dieses schon eine extreme Ersparnis.

Oh der Link: https://www.reddit.com/r/yubikey/comments/xrcly7/cloudflare_deal_for_1011_keys/

„Time is Up!“ – Mark Benecke im EU-Parlament

30. Juli 2022 / / Keine Kommentare

Klimawandel… Joar, den gibt es. Das wir Menschen dran schuld sind wissen wir ebenfalls. Im Grunde ist es uns allen schon seit Jahren klar. Wir machen nur so schön die Augen davor zu.

Probleme zu ignorieren hilft leider nicht immer (ok in der IT geht es hin und wieder *lach*)… Ich möchte hier auf einen Vortrag verweisen, welcher es für normale Menschen, fachlich belegt zusammenfasst. Vorsicht youtube!

Ich habe seit dem Video schlechte Laune :-/

« Ältere Beiträge

© 2024 -=Kernel-Error=-

Theme von Anders Norén — Hoch ↑