Grundlage ist der angepasste Adafruit nRF52 Bootloader mit verbessertem
OTA/DFU-Support, wie er hier beschrieben ist: (optional)
https://meshcore-de.fyi/meshcore:allgemeines:adafruit-nrf52-bootloader-mit-verbessertem-ota-dfu

Voraussetzungen

• Meshcore Repeater mit nRF52840
• Installierter OTA-fähiger Bootloader
• Android-Smartphone
• App nRF Device Firmware Update
• Meshcore Firmware im passenden DFU-Format

Repeater in den OTA-Modus versetzen

Bevor das Android-Tool genutzt werden kann, muss der Repeater manuell in den
OTA-Modus gebracht werden.

Dazu auf der Kommandoebene (CLI) des Repeaters folgenden Befehl eingeben:

ota start

Der Repeater wechselt anschließend in den OTA-/DFU-Modus und wartet auf eine neue
Firmware. Erst jetzt ist er für das Android-Tool sichtbar.

OTA-Update mit Android durchführen

Die App nRF Device Firmware Update auf dem Android-Gerät starten

1. Den Repeater aus der Geräteliste auswählen
2. Einmalig die Settings korrekt setzen
3. Die neue Firmware-Datei auswählen
4. Flash-Vorgang starten

Während des Updates sollte die Bluetooth-Verbindung nicht getrennt werden und
die App im Vordergrund bleiben. Geduld ist ebenfalls gefragt.

Und ganz wichtig: Daumen drücken nicht vergessen

Wenn alles erfolgreich abgeschlossen ist, startet der Repeater automatisch neu
und läuft anschließend mit der neuen Firmware.

Versuch mit Adafruit_nRF52_Bootloader_OTAFIX

Ich habe zusätzlich versucht, den alternativen Bootloader https://github.com/oltaco/Adafruit_nRF52_Bootloader_OTAFIX zu verwenden, um OTA-Fixes einzuspielen.

Ergebnis:
Der Bootloader ließ sich nicht zuverlässig „fixen“ bzw. patchen.

Somit ist dieser Weg zwar dokumentiert, aber nicht stabil nutzbar. Er birgt das Risiko, dass das Gerät im Bootloader-State hängen bleibt, was bedeutet:

Du müsstest das Gerät dann über USB direkt ansprechen, um es wiederherzustellen

Was ich allerdings nicht reparieren kann, ist die konsequente Entscheidung vieler Leute, ihre Bildschirme mit dem Handy zu fotografieren.

Ich weiß nicht, wann das angefangen hat. Vielleicht wurde das heimlich in einem Update ausgerollt. Vielleicht gibt es irgendwo einen geheimen Kurs mit dem Titel „Digitale Kommunikation für Fortgeschrittene – Modul 3: Wie ich Support maximal ineffizient gestalte“. Anders kann ich mir das kaum erklären.

Typischer Ablauf: Ich bekomme eine Nachricht mit dem Inhalt „Mein PC geht nicht mehr“. Dazu ein Foto. Dieses Foto wurde offensichtlich während eines mittelschweren Erdbebens aufgenommen, leicht diagonal aus der Hüfte geschossen, mit perfekter Spiegelung der Wohnzimmerdecke und einem Fokus, der sich entschieden hat, lieber den Staub auf dem Monitorrahmen scharf darzustellen als die Fehlermeldung selbst. Die Fehlermeldung ist natürlich halb abgeschnitten, denn warum sollte man das komplette Problem zeigen, wenn man auch nur den spannendsten Teil fotografieren kann – zum Beispiel die Worte „Fatal Error“, ohne den komplett unwichtigen Rest wie Ursache oder Fehlercode.

Ich sitze dann davor und versuche aus diesem visuellen Rätsel die technische Realität zu rekonstruieren. Es fühlt sich ungefähr so an, als würde man versuchen, einen Kriminalfall zu lösen, bei dem alle Beweise durch einen Instagram-Filter geschickt wurden.

Screenshots sind keine Raketenwissenschaft

Was viele nicht wissen: Betriebssysteme besitzen seit geraumer Zeit eine eingebaute Funktion namens Screenshot. Diese funktioniert erstaunlich zuverlässig. Sie erstellt ein Bild des Bildschirms. Scharf. Gerade. Lesbar. Ohne Reflexionen von Stehlampen oder verschwommene Katzen im Hintergrund. Diese Technologie existiert übrigens nicht erst seit gestern. Sie begleitet uns schon so lange, dass selbst Windows sie irgendwann verstanden hat.

Ein echter Screenshot hat außerdem den angenehmen Nebeneffekt, dass man Dinge lesen kann. Manchmal kann man Fehlermeldungen sogar kopieren. Ich weiß, das klingt futuristisch, aber tatsächlich beschleunigt das Fehlersuche enorm. Ein unscharfes Handyfoto hingegen zwingt mich dazu, kryptische Pixelmuster zu entziffern wie ein Historiker, der versucht, eine beschädigte Keilschrifttafel zu übersetzen, während jemand im Hintergrund nervös fragt, ob das Problem nicht „mal schnell“ gelöst werden kann.

Kontext ist kein optionales Feature

Besonders faszinierend wird es, wenn das Foto ohne jeglichen Kontext verschickt wird. Dann folgt auf meine vorsichtige Nachfrage meist eine Antwort wie „Na, geht halt nicht“. Das ist ungefähr so hilfreich, als würde man beim Arzt erscheinen, schweigend auf den eigenen Körper zeigen und erwarten, dass sofort die richtige Diagnose gestellt wird.

Betriebssystem, Version, Programm oder eine kurze Beschreibung dessen, was eigentlich passieren sollte, wirken auf den ersten Blick vielleicht wie unnötige Details, erhöhen aber die Wahrscheinlichkeit einer erfolgreichen Problemlösung dramatisch.

Ein sehr klares Statement zu Sprachnachrichten

Ein weiteres Kapitel dieser epischen Saga sind Sprachnachrichten. Ich möchte das hier einmal sehr klar formulieren, um spätere Missverständnisse zu vermeiden: Ich höre keine Sprachnachrichten ab. Wirklich nicht. Auch nicht später. Auch nicht „wenn ich mal Zeit habe“. Auch nicht in doppelter Geschwindigkeit, rückwärts oder unter Zuhilfenahme forensischer Audiotechnik.

IT-Support lebt davon, Informationen nachlesen zu können. Eine fünfminütige Audioaufnahme, in der irgendwo zwischen Kaffeemaschine, Straßenlärm und Rascheln einer Jacke beiläufig eine Fehlermeldung erwähnt wird, ist für Fehlersuche ungefähr so geeignet wie Morsecode über einen Presslufthammer.

Desktop-Kommunikation – Der unterschätzte Endgegner

Dabei wäre alles so einfach. Moderne Messenger lassen sich auf Desktops öffnen. Dort kann man Screenshots einfügen, Texte vernünftig schreiben und Fehlermeldungen direkt übernehmen. Es ist ein gewaltiger zivilisatorischer Fortschritt gegenüber der Methode „Ich fotografiere meinen Monitor wie ein seltenes Naturphänomen und schicke das dann kommentarlos weiter“.

Zum Abschluss ein ehrlicher Gedanke

Ich verstehe ja, dass viele Dinge schnell gehen sollen. Ich verstehe auch, dass nicht jeder täglich mit Technik arbeitet. Aber glaubt mir: Ein sauberer Screenshot spart Zeit, Nerven und erhöht massiv die Wahrscheinlichkeit, dass ich das Problem erkenne, bevor mein Kaffee kalt wird und meine Geduld in den Energiesparmodus wechselt.

Ich helfe wirklich gern. Ehrlich. Aber wenn ich irgendwann anfange, Fehlermeldungen anhand der Spiegelung eurer Wohnzimmerlampen zu analysieren, dann ist das kein Zeichen besonderer Kompetenz, sondern ein Hilferuf.

Netzwerkkarte und Knotendarstellung

Eine der zentralen Funktionen ist die Kartenansicht. Dort werden aktive Nodes mit ihrer Position sowie deren Verbindungen dargestellt. Besonders hilfreich ist die Hop-Darstellung zwischen den Knoten. Damit lässt sich schnell erkennen, welche Nodes besonders wichtig für das Routing sind und als zentrale Weiterleitungsstation fungieren. Ebenso fallen Funklöcher oder schlecht angebundene Regionen oft sofort auf.

Gerade beim Aufbau von Repeatern oder Gateways hilft diese Übersicht bei der Standortplanung. Oft zeigt sich erst in der Praxis, dass ein vermeintlich guter Standort durch Gelände, Bebauung oder Abschattungen schlechter funktioniert als erwartet.

Packet-Tracking und Ausbreitungsanalyse

Ein spannender Bereich im Analyzer ist das Nachverfolgen einzelner Nachrichtenpakete. Hier sieht man, über welche Nodes eine Nachricht transportiert wurde und wie viele Hops nötig waren, bis sie ihr Ziel erreicht hat.

Das ist besonders praktisch bei Reichweitentests: Wenn man zwei Standorte miteinander verbinden möchte, kann man nachvollziehen, ob Nachrichten direkt oder über Zwischenstationen laufen. Gleichzeitig lassen sich ineffiziente Routingpfade oder Paketverluste sichtbar machen. Für Feldtests liefert das wertvolle Hinweise, wie sich Funkwellen in unterschiedlichen Umgebungen ausbreiten.

Observer Nodes

Damit der Analyzer überhaupt Daten anzeigen kann, werden Observer benötigt. Das sind Nodes, die Netzwerkdaten sammeln und an die Analyseplattform weitergeben. Diese Observer können zum Beispiel auf Repeatern oder festen Standorten betrieben werden.

Kurzanleitung

1. Die Observer-Seite im Analyzer öffnen.
2. Das gewünschte Gerät bzw. den Node-Typ auswählen.
3. Die generierte Konfiguration übernehmen.
4. Die Konfiguration in der MeshCore Firmware eintragen.
5. Node neu starten und kurz warten, bis Daten im Analyzer auftauchen.

Typische Einsatzszenarien

• Standortplanung für neue Repeater
• Optimierung bestehender Verbindungen (Antenne, Höhe, Position)
• Langstrecken-Tests zwischen Städten oder Regionen
• Überwachung wachsender Community-Netze
• Fehlersuche bei Routing- und Verbindungsproblemen

Gerade bei größeren Mesh-Netzen zeigt eine Visualisierung oft erst, wie sich das Netzwerk tatsächlich verhält – und welche Nodes wirklich entscheidend für Stabilität und Reichweite sind.

Unter Ubuntu 22.04 kann es vorkommen, dass der Standard-Dokumentenbetrachter Evince keine Dokumente mehr druckt. Besonders auffällig ist dabei, dass der Drucker selbst korrekt funktioniert und Testseiten problemlos ausgibt – normale Dateien wie PDFs jedoch nicht gedruckt werden.

Mögliche Ursache

Häufig liegt das Problem an fehlerhaften oder beschädigten Druckeinstellungen, die Evince lokal speichert.

Lösung 1: Druckeinstellungen zurücksetzen

Die gespeicherten Druckeinstellungen lassen sich einfach löschen. Beim nächsten Start werden diese automatisch neu erstellt.

rm -r ~/.config/evince/print-settings

Anschließend sollte der Dokumentenbetrachter neu gestartet und ein erneuter Druckversuch durchgeführt werden.

Lösung 2: Alternativen PDF-Betrachter verwenden

Falls das Problem weiterhin besteht oder häufiger auftritt, kann es sinnvoll sein, auf einen alternativen PDF-Betrachter auszuweichen. Bewährte Alternativen sind:

• Atril
• qpdfview

Diese lassen sich bequem über die Paketverwaltung installieren:

sudo apt install atril

sudo apt install qpdfview

Fazit

Wenn der Drucker Testseiten ausgibt, liegt das Problem meist nicht an der Druckerkonfiguration, sondern an lokalen Einstellungen des Dokumentenbetrachters. Das Zurücksetzen der Evince-Druckeinstellungen oder der Wechsel auf eine alternative Anwendung behebt das Problem in den meisten Fällen schnell.

Viele nutzen ihre DiskStation nicht nur als Datenspeicher, sondern auch zur Automatisierung von Backup-Prozessen. In meinem Setup wird ein externes Backup-NAS bei Bedarf automatisch per Wake-on-LAN (WOL) durch ein benutzerdefiniertes Skript gestartet. Dadurch läuft das Backup nur dann, wenn es wirklich benötigt wird – energiesparend und effizient.

Nach dem Update auf DSM 7 musste ich allerdings feststellen, dass die bekannte Binary ether-wake nicht mehr Bestandteil des Systems ist. Synology hat diese Funktion inzwischen in das interne Tool synonet integriert. Wake-on-LAN lässt sich damit weiterhin problemlos nutzen, nur mit einem anderen Befehl.

Wake-on-LAN mit synonet verwenden

Um einen entfernten Rechner oder ein NAS über die DiskStation aufzuwecken, kann man sich per SSH auf der DiskStation anmelden und folgenden Befehl ausführen:

sudo synonet --wake E8:D8:D1:42:27:73 eth0

Hinweise:

• Die MAC-Adresse muss durch die Adresse des Zielgeräts ersetzt werden.
• eth0 beschreibt das Netzwerkinterface, über das das Wake-Signal gesendet wird.

Bestehende Automationen funktionieren damit weiterhin zuverlässig – es muss lediglich der neue Befehl berücksichtigt werden.

Obwohl ihr euch sicher seid, dass ihr das richtige Kennwort nutzt, kommt ihr nicht in den Cloud Key?
Versucht doch mal den Zugang per

ssh root@IP

ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 106820 Feb  2 00:24 /usr/bin/sudo
chmod u+s /usr/bin/sudo

Danach sollte der Zugang zum Webinterface wieder funktionieren.

Leider gibt es für den Dymo LabelWriter 450 keinen aktuellen, gepflegten Linux-Support mehr. Nach einer Neuinstallation von Ubuntu 25.10 funktioniert der klassische Installationsweg über das alte SDK nicht mehr zuverlässig. Mit der folgenden Anleitung lässt sich der Drucker dennoch manuell einrichten.

1. Drucker erkennen

Zunächst prüfen, ob das System den Drucker erkennt:

sudo lsusb

Der Drucker sollte ähnlich wie folgt angezeigt werden:

Bus 002 Device 006: ID 0922:0020 Dymo-CoStar Corp. LabelWriter 450

2. Benötigte Pakete installieren

Als nächstes werden die notwendigen CUPS-Pakete installiert:

sudo apt-get update
sudo apt-get install cups cups-client printer-driver-dymo

3. Druckertreiber (PPD) manuell installieren

Die Druckerdefinition wird aus dem offiziellen Dymo SDK benötigt. Da unklar ist, wie lange diese Dateien noch verfügbar sind, empfiehlt sich eine lokale Sicherung.

wget http://download.dymo.com/dymo/Software/Download%20Drivers/Linux/Download/dymo-cups-drivers-1.4.0.tar.gz
tar -xzf dymo-cups-drivers-1.4.0.tar.gz

sudo mkdir -p /usr/share/cups/model
sudo cp dymo-cups-drivers-1.4.0.5/ppd/lw450.ppd /usr/share/cups/model/

Damit steht die Druckerdefinition dem System zur Verfügung.

4. Druckeradresse ermitteln

Nun wird die Geräteadresse des Druckers abgefragt:

sudo lpinfo -v

Der relevante Eintrag sieht typischerweise so aus:

direct usb://DYMO/LabelWriter%20450?serial=XXXXXXXXXXXX

Die Seriennummer ist individuell und muss im nächsten Schritt übernommen werden.

5. Drucker im System registrieren

lpadmin -p dymo \
-v usb://DYMO/LabelWriter%20450?serial=XXXXXXXXXXXX \
-P /usr/share/cups/model/lw450.ppd

Falls keine Fehlermeldung erscheint, wurde der Drucker erfolgreich angelegt.

6. Drucker aktivieren

lpstat -v
sudo cupsenable dymo
sudo cupsaccept dymo

7. Funktion prüfen

Der Drucker sollte jetzt in der Systemsteuerung sichtbar sein. Ein Testdruck bestätigt die erfolgreiche Installation.

Fazit

Trotz fehlender offizieller Pflege lässt sich der Dymo LabelWriter 450 weiterhin unter aktuellen Linux-Distributionen betreiben. Der wichtigste Schritt ist dabei die manuelle Integration der PPD-Datei.

Mit Meshcore entsteht nun ein Ansatz, der viele der strukturellen Probleme adressiert, die Meshtastic zuletzt ausgebremst haben. Während Meshtastic Firmware, Protokoll und Anwendung in einem einzigen Projekt bündelt, trennt Meshcore diese Bereiche bewusst voneinander. Das Protokoll steht im Mittelpunkt und ist so definiert, dass es unabhängig von einer bestimmten App oder Hardware genutzt werden kann. Diese klare Abgrenzung erhöht nicht nur die Transparenz, sondern schafft auch eine Grundlage für nachhaltige Weiterentwicklung.

Ein weiterer Unterschied zeigt sich in der technischen Architektur. Meshtastic wuchs organisch – viele Funktionen wurden nachträglich ergänzt, wodurch das Verhalten im Netz mit steigender Teilnehmerzahl zunehmend unvorhersehbar wurde. Meshcore dagegen setzt auf ein konsistentes Routingmodell und eine streng definierte Paketbehandlung. Das reduziert Overhead, verbessert die Stabilität und sorgt dafür, dass Netze auch dann zuverlässig funktionieren, wenn sie größer werden oder hohe Verkehrslasten tragen müssen.

Auch die Governance und Offenheit unterscheiden sich deutlich. Meshtastic enthielt im Laufe der Zeit proprietäre Komponenten und war organisatorisch eng an einzelne Entwickler gebunden. Meshcore startet dagegen mit dem Anspruch, vollständig offen und gemeinschaftlich steuerbar zu sein. Diese Offenheit erleichtert es externen Entwickler*innen, eigene Implementierungen zu erstellen oder bestehende Systeme zu erweitern, ohne sich an eine bestimmte Plattform binden zu müssen.

Zusammengefasst führt Meshcore den Grundgedanken von Meshtastic fort, legt dabei aber mehr Wert auf technische Sauberkeit, klare Zuständigkeiten und langfristige Wartbarkeit. Wo Meshtastic den Einstieg erleichtert hat, versucht Meshcore nun, ein stabiles Fundament zu schaffen, auf dem unterschiedliche Anwendungen, Geräte und Projekte verlässlich zusammenarbeiten können.

Schritt-für-Schritt-Anleitung

1. In die Adresszeile eingeben:

about:config

2 .Warnung bestätigen („Vorsicht, Gefahr…“).

3. Nach folgendem Eintrag suchen:

browser.tabs.insertAfterCurrent

• Den Wert auf true setzen.

Ab sofort öffnen sich neue Tabs nicht mehr ganz rechts, sondern direkt neben dem aktiven Tab.

Optional: Verhalten für Links anpassen

Zusätzlich kannst du steuern, ob auch Tabs aus Links daneben erscheinen:

• browser.tabs.insertRelatedAfterCurrent
  • true = Link-Tabs öffnen direkt neben dem aktuellen.
  • false = Sie öffnen sich am Ende der Tableiste.

Add-ons für mehr Kontrolle

Falls du noch mehr Einfluss auf die Tab-Position haben möchtest, gibt es Erweiterungen wie:

• Tab Position Options – für feines Tab-Tuning.

Mit dem Release von Proxmox VE 9 steht ein großes Upgrade bevor. Wer noch auf Version 8 läuft, sollte das Upgrade sorgfältig planen. In diesem Artikel beschreibe ich, wie ich das Update durchgeführt habe – inklusive hilfreicher Hinweise, Best Practices und typischer Stolperfallen.

Vorbereitung – Backup ist Pflicht!

• Alle VMs und Container sichern (Snapshots reichen nicht, besser vollständige Backups über Proxmox Backup Server oder andere Tools).
• Am besten alle VMs herunterfahren (stop), um inkonsistente Daten zu vermeiden.

Ohne ein funktionierendes Backup geht man bei einem Major-Upgrade ein hohes Risiko ein.

System auf den neuesten Stand bringen

apt update
apt dist-upgrade

Falls hier nichts mehr zu aktualisieren ist, erscheint die Meldung „Your system is up-to-date“.

Check mit dem Migrations-Tool

pve8to9 --full

Das Tool prüft u. a.:

• Kernel-Version
• Pakete, die nicht kompatibel sind
• Konfigurationen, die angepasst werden müssen

So lässt sich frühzeitig erkennen, ob Handlungsbedarf besteht.

Microcode-Update (optional, aber empfohlen)

Falls ihr eine Intel-CPU habt, kann ein Microcode-Update erforderlich sein. Dazu müssen die Debian-Repos vollständig eingebunden sein:

deb http://deb.debian.org/debian bookworm main contrib non-free-firmware

Danach:

apt install intel-microcode

Debian-Basis von Bookworm auf Trixie aktualisieren

Proxmox VE 9 basiert auf Debian 13 „Trixie“. Wir passen also die Repositories an:

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

Falls ihr das Enterprise-Repository nicht nutzt (keine Subscription), könnt ihr die pve-no-subscription-Quelle hinzufügen:

cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

Upgrade starten

apt update
apt dist-upgrade

Das kann eine Weile dauern – je nach Hardware und Anzahl der Pakete.

System prüfen und neu starten

reboot

Anschließend prüfen wir die installierte Version:

pveversion

Hier sollte jetzt eine 9.x erscheinen.

Tipps & Hinweise

• Reihenfolge beachten: Zuerst Backups → Update unter Proxmox 8 → Migrationstool → Repos umstellen → Upgrade → Reboot.
• Cluster-Umgebung: Wer mehrere Nodes in einem Cluster betreibt, sollte sie nacheinander upgraden. Mischbetrieb (ein Node auf 8, einer auf 9) ist nur für kurze Zeit empfohlen.
• Custom-Repositories (z. B. Ceph, ZFS): Prüfen, ob sie kompatibel mit Debian Trixie sind, und ggf. vorab aktualisieren.
• Downtime einplanen: Je nach Setup können VMs für die Dauer des Upgrades offline sein.

Mit diesen Schritten hat das Upgrade von Proxmox VE 8 auf 9 bei mir sauber funktioniert.