Verbindlich: main@8fb581b730f7a3833566c4bbb7c87875ad921e69; veröffentlicht bleibt v1.9.0. PR #74–#97 sind integriert. Deployment/Discovery, Imagebuilder, Pi-VPN und Syslog sind auf main, nicht mehr nur historische Vorschau. 26 reguläre Rollen einschließlich Deployment-VM; Provisioning ist optional zusätzlich.

Betreiberbestätigt: KDE-Boot, Rufe, SDS, Aufnahme/RF-Wiedergabe und WLAN am 13.10.; 28/28 Discovery-Agenten aktualisiert und keine ungeklärten Remote-Aufträge mehr am 15.10. Ein aktueller Backend-Gesamtrollout, NAS-Entlastung, SIP/Telegram, VPN-Wechsel und Dauerlauf bleiben separat offen. Vier alte Git-/Timeoutfehler bleiben Fehler.

Gesamtroadmap · Upstream-Vergleich · Roadmap und Releases. NETCORE-IAM-01 ist weiterhin Planung; AD-SSO-Pilot und Gruppenmapping sind konkretisiert, Produkt-/Betriebsentscheidung und Umsetzung offen.

Volle MQTT-Outbox, verlorene Agentenquittung, Git-Transportabbruch, OpenVPN lport 0 und Ubuntu-logrotate-Kontext sind inzwischen getrennte bekannte Pfade mit Korrekturen auf main. Einen historischen Fehlerlog nicht als heutigen Anlagenzustand ausgeben.

Kanonische aktuelle Fachanleitung.

Die folgende frühere Fassung bleibt als datierte Historie erhalten. Frühere Dienstzahlen, Featurebranch-Aussagen, offene Tests und Prioritäten sind keine aktuelle Statusaussage; heutige Verfahren stehen oben beziehungsweise in den verlinkten kanonischen Docs.

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Nur main ist als Branch vorhanden. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

PR #59 ist auf main; der frühere Branch feat/netcore-dashboard-design existiert nicht mehr. Alte Branchwechsel in den TBS- und Dienstanleitungen durch einen geprüften main-/SHA-Checkout ersetzen. Aktive Unit, ExecStart, Binary- und Konfigurationspfad erfassen; lokale Änderungen, Konfiguration und vorherige Binary sichern. Erst erfolgreich bauen, dann gezielt installieren und Fachfunktion prüfen.

Für das reine TBS-Designupdate MIGRATE_LOCAL_TTS_CONFIG=0 und DISABLE_LOCAL_PIPER=0 verwenden. Dienst-Updater können zusätzliche Konfigurationen verändern; gezielte Binary-/Python-Updates gemäß tatsächlicher Unit bevorzugen. Rückweg über die gesicherte passende Binary und den dokumentierten früheren Quell-SHA, ohne aktuelle Konfiguration pauschal zu überschreiben. Ein Checkout allein aktualisiert keinen installierten Dienst.

1. Fehlerzeitpunkt und betroffene ISSI/GSSI notieren.
2. Dienstzustand und ersten Fehler im Journal prüfen.
3. Konfiguration gegen Fallback und letzte Sicherung vergleichen.
4. RF-, Protokoll- und Integrationsfehler getrennt betrachten.
5. Nur eine Variable gleichzeitig ändern.
6. Nach einem Fix den vollständigen Ablauf einschließlich Release erneut testen.

sudo systemctl status tetra.service --no-pager
sudo journalctl -u tetra.service -b -n 300 --no-pager
/usr/local/bin/bluestation-bs /etc/netcore/config.toml

Typische Ursachen:

• TOML-Fehler oder falsche config_version
• SDR nicht gefunden
• Sample-Rate nicht unterstützt
• Dual-Carrier-Passband ungültig
• Port bereits belegt
• fehlende native Bibliothek
• Verzeichnis nicht beschreibbar

ss -ltnp | grep -E ':8080|bluestation'
curl -I http://127.0.0.1:8080/

Bind-Adresse, Port, Firewall und Auth-Konfiguration prüfen. Nach UI-Updates Browser hart neu laden.

• MCC/MNC, Frequenz, Colour Code und Location Area prüfen.
• Downlink-Signal und Uplink-Empfang getrennt betrachten.
• Gerätelogs auf Location Update prüfen.
• Allowlist/Recovery-Regeln kontrollieren.
• Zeitbasis und SDR-Buffer beobachten.

• Affiliation vorhanden?
• Traffic-Carrier/Timeslot zugewiesen?
• Floor Grant erhalten?
• Uplink-Sprachrahmen sichtbar?
• Audio-Codec oder SDR-Pfad gestört?
• Hangtime-Retake eines älteren Geräts?

• U-DISCONNECT/D-RELEASE im Log suchen.
• ul_inactivity_secs prüfen.
• AudioPlayer-Release-Guard abwarten.
• Carrier-/Timeslot-Anzeige mit dem tatsächlichen Scheduler vergleichen.
• anschließend gezielt Gerät re-registrieren, nicht sofort alle Teilnehmer kicken.

curl -fsS http://<DIRECTORY-IP>:8095/api/health
sudo journalctl -u tetra.service -n 300 --no-pager | grep -i directory

Base-URL, Timeout und Firewall prüfen. Numerische IDs sollten trotzdem sichtbar bleiben.

Siehe Audio-Zentrale. Besonders ffmpeg, Piper-Endpunkt, Cache-Rechte, NFS-Mount und Ruf-Release prüfen.

• Basisstation stoppen.
• Primärkonfiguration sichern.
• bekannten Stand oder Fallback manuell testen.
• Clean-Build ausführen.
• erst danach wieder automatisch starten.

Für den betroffenen Host zuerst Liveness, dann Readiness, dann den konkreten API-Vertrag und schließlich den Nutzungsfall prüfen. Eine 503 auf /health/ready kann eine ausgefallene Abhängigkeit anzeigen, obwohl der Prozess läuft. Die echte URL steht in inventory.toml und der gerenderten Dienst-TOML; Dienstkatalog und Netzwerk-und-Ports.

systemctl status netcore-node-gateway.service --no-pager
journalctl -u netcore-node-gateway.service -b -n 200 --no-pager
curl -sS -w '\nHTTP %{http_code}\n' http://<GATEWAY-IP>:8080/health/ready

Widersprechen sich TBS-[control_room].host und Inventory-Gateway, zuerst die tatsächlich installierten Dateien angleichen. Control Room 9010 ist nicht das TBS-Ziel /ws/node.

Mit einer Testnachricht und Zeitstempel TBS-RX → lokale SDS-Verarbeitung → Node Gateway/SDS Router → IoT Gateway → Broker-Topic → HA-Trigger prüfen. System-ISSI 4010001 kann eine lokale Steueradresse sein. Nur „MQTT verbunden“ oder ein vorhandenes Discovery-Entity reicht als Nachweis nicht. MQTT-und-Home-Assistant

PJSIP-Registrierung, erreichbaren Kontakt, Ruf-Setup/U-CONNECT, RTP beider Richtungen und TETRA-Codec-Pfad getrennt prüfen. Lokalen TBS-Asterisk und zentralen SIP Switch nicht auf denselben Host installieren; Fallback-Meldung und aktive Route lesen. Bei Rufende Floor, Hangtime und Release auf TBS und Asterisk vergleichen. SIP-und-Brew · Calls

PDP/NSAPI im Packet Core, TUN und Lease im IP Gateway, Route/NAT/Firewall/DNS und Endgeräte-URL getrennt prüfen. TBS-WAP-Port 9200, Testserver 8088 und Management 8170 sind verschiedene Rollen. Paketdaten-und-WAP

Commit/Tag und lokale Änderungen; Unit und geladene TOML ohne Geheimnisse; Fehlerminute mit Zeitzone; betroffene ISSI/GSSI, Carrier/Slot; erstes auffälliges Log jeder beteiligten Komponente; erwartetes und beobachtetes Ergebnis. Abnahme

• SDS Router: live=200, aber ready/status brechen ab; index out of bounds und anschließend PoisonError. Die Kurzstatus-Reparatur einspielen und Persistenz behalten.
• SDS Router/Call Control: langsame Readiness und Fallback bei Gateway-Telemetrie. Der Release vermeidet unnötige synchrone Persistenz bei unveränderten Daten. Latenz am Standort erneut messen.
• Warnzentrale: Gerät fehlt oder Prüfung nötig. Registrierung, GPS-Alter, TBS-Lage, Gateway-Kanal und Versandhistorie vergleichen. Warnzentrale
• Sepura-REREGs: Frame-18-BNCH wurde korrigiert; die Ursache aller beobachteten Neuanmeldungen ist damit nicht bewiesen. Vergleichsversuch mit gleicher Konfiguration und Hardware durchführen.
• SIP Switch: Asterisk kann generierte Includes nicht lesen. Eigentümer/Gruppe asterisk und Modus 0640 prüfen.

Der statische Gesamt-Audit hat drei bekannte Befunde; sie stehen auf Projektstand.

Entwicklungsvorschau vom 28.09.2026: Historischer Featurecommit bbf0397, Deployment-Komponente 0.2.3. Diese Funktionen sind noch nicht auf main und kein neuer Gesamtrelease. PR #57 wurde in den Entwicklungsbranch gemergt. Bei remote_uncertain denselben Remote-Auftrag und Agenten prüfen; Deployment-POST nicht blind wiederholen. Falsche Dienstrollen anhand echter systemd-Unit/FragmentPath eingrenzen. Bei Discovery-Konflikten Bindung ausdrücklich setzen. Bei Archivfehlern echten NFS/CIFS-Mount und Collector-Rechte prüfen; keine pauschalen NAS-Rechteänderungen. Deployment-und-Discovery · Syslog-und-Archivierung