Netzwerk und Ports - JanHG98/netcore-tetra GitHub Wiki
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.
Kanonische Anleitung am aktuellen main-Stand. Für neue Bedienwege, vollständige Rollen-/Portzählung und geänderte Grenzen ist diese Fassung maßgeblich; die früheren Beispiele unten bleiben als Historie erhalten.
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
Das neue Design ändert weder vorhandene Dienstports noch Zugangsverfahren. Deployment-Ports 8320/8321, Discovery und die neuere Syslog-Pipeline gehören weiterhin ausschließlich zur historischen Vorschau. IAM/Drive sind Planung ohne festgelegte neue Produktivports. Bedienoberflaechen · Roadmap und Releases
Beispielwerte, keine globalen Defaults: Die folgenden Angaben stammen aus deploy/open-lab/inventory.example.toml, der sanitisierten TBS-Konfiguration und den jeweiligen Dienstvorlagen. Auf einem anderen Host kann derselbe Port gleichzeitig genutzt werden. Vor einer Freigabe immer die gerenderte /etc/netcore/*.toml und ss am Zielhost lesen.
| Dienst | TCP-Port im Inventory | Dienst | TCP-Port im Inventory |
|---|---|---|---|
| Node Gateway | 8080 | Mobility Core | 8090 |
| Subscriber Core | 8100 | Group Core | 8110 |
| Call Control | 8120 | Media Switch | 8130 |
| Recorder | 8140 | SDS Router | 8150 |
| Packet Core | 8160 | IP Gateway | 8170 |
| Security Core | 8180 | KMF | 8190 |
| Transit | 8200 | Observability | 8210 |
| Application Gateway | 8220 | Media Library | 8230 |
| IoT Gateway | 8240 | Hardware Gateway | 8250 |
| RF Monitor | 8260 | Alarm Workflow | 8270 |
| Task Workflow | 8280 | Asset Management | 8290 |
| SIP Switch | 8300 | Control Room | 9010 |
Zusätzlich: TBS-Dashboard 8080 auf der TBS, Provisioning Core 8125, Directory 8095, Piper 5005. Node Gateway 8080 und TBS-Dashboard 8080 dürfen nur auf verschiedenen Hosts/Adressen parallel binden. Dienstzweck und Quellpfad: Dienstkatalog.
| Verbindung | Protokoll/Beispiel | Prüffrage |
|---|---|---|
| TBS → Node Gateway | WebSocket auf ws://<gateway>:8080/ws/node
|
stimmen host, port, endpoint_path, Node-ID und Security-Modus? |
| Backend → Node Gateway | WebSocket /ws/backend sowie HTTP APIs |
meldet der Dienst sich mit gültiger Vertragsversion? |
| Fach-WebUI/API | HTTP/TCP am jeweiligen Managementport | antworten /health/live, /health/ready, /api/v1/status? 503 bei Ready kann eine echte Abhängigkeit anzeigen. |
| IoT Gateway → Broker | MQTT/TCP, Vorlage 1883
|
stimmen Host, Topic-Prefix, QoS, ACL und Retained-Status? |
| TBS → Brew-Peer | WebSocket/TCP, Vorlagenwert 8081
|
ist Peer erreichbar und unterstützt er die freigeschalteten Features? |
| TBS → Directory/Piper | HTTP/TCP, Beispiele 8095/5005
|
Names/Status bzw. Sprachsynthese getrennt testen. |
| IP Gateway | TUN, DNS/UDP, HTTP-WAP-Testserver | TUN-Passthrough, Route, NAT und Firewall getrennt prüfen. |
| Rolle | Beispielwert | Bedeutung |
|---|---|---|
| Zentraler SIP Switch |
5060 UDP/TCP |
SIP-Listener des zentralen Asterisk, getrennt vom HTTP-Management 8300
|
| Zentraler SIP Switch |
10000–20000 UDP |
RTP-Bereich aus der Beispiel-TOML, standortabhängig |
| Native TBS-SIP-Bridge |
5062 UDP |
Beispiel der TBS-Konfiguration; lokalen Asterisk separat prüfen |
| Native TBS-Bridge |
30000–30100 UDP |
RTP-Beispielbereich |
| Vorhandene PBX |
5060 im Beispiel |
eigener Host/Trunk; kein NetCore-Managementport |
SIP-Registrierung und 180 Ringing beweisen keinen bidirektionalen RTP-Durchsatz. Eine funktionierende Verbindung benötigt zusätzlich passenden Codec, NAT-/Firewall-Regeln, Rufannahme und Audio in beide Richtungen. SIP-und-Brew
sudo ss -lntup
systemctl status netcore-node-gateway.service --no-pager
curl -fsS http://<GATEWAY-IP>:8080/health/live
curl -sS -w '\nHTTP %{http_code}\n' http://<GATEWAY-IP>:8080/health/readyDie konkreten Ziele stehen im eigenen inventory.toml, in den gerenderten Dienstkonfigurationen und in der TBS-Konfiguration. Ein Verwaltungsport gehört nicht ungeprüft an einen öffentlichen Router. Security-and-Operations
alert-service verwendet 10.0.20.34:8310/tcp. Ausgehend benötigt er HTTP zum Control Room (9010), SDS Router (8150) und HTTPS zu den konfigurierten BBK/NINA-Quellen. Control Room liest zusätzlich ws://node-gateway:8080/ws/backend; die TBS bleibt auf /ws/node. Direkte HTTP-Listener schützen und Token nicht in URLs übertragen. Warnzentrale
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. Die Vorschau ergänzt HTTP TCP 8320 für den Controller, HTTP TCP 8321 je Agent und UDP 48320 an Multicast 239.192.84.82 mit TTL 1. Geroutete VPN-Netze verwenden erreichbare Unicast-Seeds. Der Imagebuilder nutzt nur /run/netcore-image-builder/api.sock. Syslog empfängt TCP/UDP 514 sowie RELP TCP 20514; NMS bleibt auf HTTP 8210. Diese Ports sind kein Bestandteil der unveränderten main-Dienstmatrix. Deployment-und-Discovery · Syslog-und-Archivierung