CCcam Radegast Einrichtung: Vollständige Konfiguration& Port Anleitung

Wenn Sie hier gelandet sind, haben Sie bereits eine CCcam- oder OScam-Box am Laufen und etwas an der Radegast-Seite Ihrer Kette funktioniert nicht. Die Dokumentation ist spärlich, die Forenbeiträge widersprechen sich und niemand scheint sich einig zu sein, welche Konfigurationsdatei was macht. Dieser Artikel behandelt die vollständigeCCcam Radegast-Protokoll Einrichtung und Konfiguration Prozess — von der serverseitigen Portbindung bis hin zu Debug-Logs und Tunneling. Kein Schnickschnack, keine falschen Benchmarks. Nur die Konfigurationszeilen, die tatsächlich funktionieren.

Was das Radegast-Protokoll tatsächlich ist (und warum es die Leute verwirrt)

Die Verwirrung beginnt fast immer mit der Benennung. Die Leute sehen "Radegast", "newcamd" und "CCcam" in demselben Forenbeitrag austauschbar verwendet und nehmen an, dass es Varianten desselben sind. Das sind sie nicht — und sie zu vermischen wird Stunden Ihrer Zeit verschwenden.

Radegast vs newcamd vs CCcam-Protokoll

Newcamd ist ein verschlüsseltes Protokoll, das 3DES verwendet. Jede Verbindung erfordert einen gemeinsamen Schlüssel (den 14-Byte-DES-Schlüssel in der Client-Konfiguration), und die Authentifizierung erfolgt auf der Handshake-Ebene. Das native Protokoll von CCcam ist sein eigenes binäres Format mit einem anderen Handshake und einer eigenen Verschlüsselungsschicht. Radegast ist keines von beidem. Es ist ein vereinfachtes, größtenteils im Klartext gehaltenes Control Word (CW) Austauschprotokoll — entworfen für Einfachheit, nicht für Sicherheit.

Der praktische Unterschied: Bei newcamd haben Sie einen Benutzernamen, ein Passwort und einen DES-Schlüssel. Bei Radegast gibt es das nicht. Der Server erlaubt entweder Ihre IP oder nicht. Das ist das gesamte Zugriffssteuerungsmodell.

Wo Radegast in einer CCcam/OScam-Kette passt

Die meisten realen Setups, die Radegast beinhalten, sehen so aus: Eine OScam-Instanz sitzt zwischen der Kartenhardware (oder der upstream Quelle) und dem Rest des Netzwerks. OScam bietet einen Radegast-Listener an, mit dem lokale oder LAN-Clients sich verbinden können. Wenn das endgültige downstream Gerät nur das native CCcam-Protokoll spricht, verbinden Sie eine lokale CCcam-Instanz mit dem OScam-Reader.

Reines CCcam zu Radegast ohne OScam dazwischen ist technisch möglich, aber schlecht unterstützt. Die eigene Radegast-Verarbeitung von CCcam ist im Vergleich zu OScam, das seit Jahren erstklassige Radegast-Unterstützung hat, begrenzt. Wenn Sie versuchen, CCcam direkt als nativen Radegast-Server agieren zu lassen, werden Sie schnell auf Wände stoßen. Der funktionierende Weg ist OScam als Radegast-Endpunkt.

Die cs357x (Radegast) und cs378x (Radegast-over-camd35/HTTP) Benennung

Hier bricht die meiste Dokumentation völlig zusammen. In der Terminologie von OScam,cs357x ist das klassische Radegast-Reader-Protokoll — das im Klartext. Der Name stammt von historischen Portkonventionen.cs378x ist ein anderes Tier: es ist eine camd35-over-TCP-Variante (manchmal als Radegast-over-HTTP bezeichnet), die eine leichte Schutzschicht hinzufügt.

Wenn Sie bearbeiten,oscam.server, setzen Sieprotocol = radegast für cs357x-Verbindungen undprotocol = cs378x für die camd35/HTTP-Variante. Die meisten Anleitungen erklären diesen Unterschied nie, weshalb die Leute am Ende versuchen, zufällige Schlüsselwörter zu verwenden, bis etwas funktioniert. Wenn Sie sehen,protocol = cs357x — das ist eine ältere Notation und nicht universell akzeptiert in allen Builds. Verwenden Sieprotocol = radegast im Reader-Block für das klassische Protokoll.

Klartext, nicht authentifiziertes Design und was das impliziert

Radegast hat keine Verschlüsselung und keine Benutzerauthentifizierung per Design. Der ursprüngliche Zweck war eine einfache, ressourcenschonende CW-Verteilung in vertrauenswürdigen lokalen Netzwerken. Es erfüllt diesen Anwendungsfall gut. Aber diese Designentscheidung bedeutet, dass jeder, der den Port erreichen kann, Control Words anfordern kann. Kein Benutzername, kein Passwort, kein Schlüsselaustausch — nur eine offene TCP-Verbindung.

Deshalb ist Radegast in einem vertrauenswürdigen LAN angemessen und eine wirklich schlechte Idee über das offene Internet ohne Tunnel. Mehr dazu im Sicherheitsabschnitt.

Serverseitige Konfiguration: Einen Radegast-Port freigeben

Die Serverseite lebt in zwei OScam-Dateien:oscam.conf (globaler Listener) und potenzielloscam.server (wo Sie spezifische Reader dem Radegast-Ausgang zuordnen). Zuerst den Listener-Block richtig einrichten.

OScam oscam.conf radegast Block

Öffnen/etc/oscam/oscam.conf und fügen Sie einen[radegast] Abschnitt hinzu, falls er noch nicht existiert. Ein minimal funktionierender Block sieht so aus:

[radegast]

Das ist das Minimum. OScam wird auf TCP-Port 8888 hören und Verbindungen nur von localhost und dem Subnetz 192.168.0.x akzeptieren. Lassen Sieallowed nicht leer — in einigen Builds wird standardmäßig alles akzeptiert, was genau das ist, was Sie nicht wollen.

Sie können auchnodeid oderuser Parameter je nach Ihrer OScam-Version hinzufügen, aber für eine grundlegende LAN-Konfiguration bringen Sie mit den oben genannten zwei Zeilen alles zum Laufen. Speichern Sie, und starten Sie OScam neu.

Einstellen des Listenports und der erlaubten IP-Bereiche

Port 8888 ist konventionell für Radegast, aber nicht zwingend erforderlich — Sie können alles über 1024 verwenden, das noch nicht belegt ist. Überprüfen Sie zuerst, was sonst noch läuft:ss -tlnp gibt Ihnen eine vollständige Liste der gebundenen Ports. Wenn Sie auch die OScam-Weboberfläche ausführen, achten Sie auf Konflikte — die Weboberfläche läuft oft auf Port 8888 oder 16002, je nach Ihrem Build. Setzen Sie einen von ihnen auf etwas anderes.

Dasallowed Feld akzeptiert einzelne IPs, CIDR-ähnliche Bereiche oder durch Bindestriche getrennte Bereiche. Für einen einzelnen vertrauenswürdigen Remote-Host:allowed = 192.168.1.50. Für ein vollständiges Subnetz:allowed = 192.168.1.0-192.168.1.255. Halten Sie es eng.

Denken Sie auch darüber nach, an welches Interface Sie binden. Standardmäßig bindet OScam an alle Interfaces (0.0.0.0). Wenn Ihre Maschine sowohl eine externe NIC als auch eine interne LAN-NIC hat, bedeutet das Binden an alle Interfaces, dass der Radegast-Port technisch auch von der externen Seite erreichbar ist — Ihre Firewall-Regeln könnten dies blockieren, aber Verteidigung in der Tiefe ist wichtig. Sie könnenbindaddr = 192.168.0.1 innerhalb des[radegast] Blocks hinzufügen, um es nur an das LAN-Interface zu binden.

Zuordnen eines Readers/CAID zum Radegast-Ausgang

OScam leitet ECM-Anfragen automatisch basierend auf CAID-Abgleich durch seinen Reader-Pool. Sie benötigen keine explizite Verkabelung zwischen einem Reader und dem Radegast-Listener — solange Ihr Reader inoscam.server in einer Gruppe ist, auf die Radegast-Clients zugreifen können, erfolgt das Routing intern.

Wenn Sie einschränken möchten, welche Karten ein Radegast-Client abfragen kann, setzen Sie diecaid undident Filter im Leser-Eintrag und konfigurieren Sie die Gruppen sorgfältig. Ein Radegast-Client-Benutzer (automatisch erstellt oder inoscam.user definiert) kann auf spezifische Gruppen beschränkt werden, die nur die Leser enthalten, die Sie ihm zeigen möchten.

Neustart und Bestätigung, dass der Port lauscht

Nach dem Neustart von OScam führen Sie dies auf dem Server aus:

ss -tlnp | grep 8888

Oder wenn Ihr System älter ist:

netstat -tlnp | grep 8888

Sie sollten etwas sehen wie0.0.0.0:8888 (oder Ihre spezifische Bind-Adresse) mit der OScam PID. Wenn nichts angezeigt wird, konnte OScam entweder den Konfigurationsblock nicht parsen oder Ihr Build enthält nicht das Radegast-Modul. Überprüfen Sie das Startprotokoll von OScam — es protokolliert, welche Listener aktiviert wurden.

Um zu bestätigen, dass das Modul kompiliert ist:oscam --show-info 2>&1 | grep -i radegast. Wenn Sie nichts zurückbekommen, hat Ihr Binary den Radegast-Leser/Server nicht kompiliert. Sie benötigen einen anderen Build. Dies ist häufiger, als die Leute bei vorgepackten Builds denken.

Client-Seitige Konfiguration: Lesen eines Radegast-Feeds

Sobald der Server als lauscht bestätigt ist, findet die meiste tägliche Fehlersuche auf der Client-Seite statt. Die Konfiguration geht in die Client-Maschine/etc/oscam/oscam.server Datei.

OScam cs357x Leser in oscam.server

Hier ist ein vollständiger, funktionierender Leserblock für eine Radegast (cs357x) Quelle:

[reader]

Dasdevice Feld ist IP und Port als kommagetrennte Paar — keine Leerzeichen. Dascaid Feld sagt OScam, dass es nur diesen Leser nach CAID 0x0500-Diensten fragen soll. Ohne es wird OScam diesen Leser nach allem abfragen und Sie erhalten ECM-Timeouts bei CAIDs, die die Quelle nicht bedienen kann.

Erforderliche Felder: device (host,port), protocol, caid, ident

Das Überspringen voncaid undident ist der häufigste Konfigurationsfehler, den ich gesehen habe. Der Leser wird sich gut verbinden, aber OScam leitet jedes unbekannte ECM darüber, was die Latenz erhöht und Ihre Protokolle mit fehlgeschlagenen Abfragen füllt. Filtern Sie immer auf das, was die Quelle tatsächlich trägt.

Dasident Das Feldformat istCAID:ProviderID. Wenn Sie die Provider-ID nicht kennen, beginnen Sie mit000000 als Auffang-ID und verfeinern Sie es, sobald Sie die tatsächlichen Provider-IDs im ECM-Log sehen können. Übermäßig strenge Identfilterung ist eine der Ursachen für "verbunden, aber keine Karten" — behandelt im Abschnitt zur Fehlersuche.

cs378x für die camd35/HTTP-Variante und wann man sie bevorzugen sollte

Der cs378x-Readerblock sieht nahezu identisch aus, aber das Protokollschlüsselwort und die Authentifizierung ändern sich:

[reader]

cs378x fügt eine Benutzername/Passwort-Schicht hinzu und ist nat-freundlicher, da der Client die Verbindung outbound initiiert — nützlich, wenn sich die Serverseite hinter einer Firewall befindet, die ausgehenden, aber keinen eingehenden Verkehr erlaubt. Es behandelt auch einige Randfälle bei der Multi-Byte-CW-Codierung, die ältere Radegast-Implementierungen falsch handhaben. Für jede Verbindung, die das Internet überquert (auch über einen Tunnel), ist cs378x die weniger problematische Wahl.

In einem vertrauenswürdigen LAN, in dem Sie beide Enden kontrollieren, ist klassisches Radegast (cs357x) in Ordnung und hat weniger Overhead.

Gruppe, Fallback und CAID/Provider-Filterung

OScam verwendet Gruppen, um zu steuern, welche Reader für welche Benutzer verfügbar sind. Wenn Sie OScam → CCcam auf derselben Box verketten, wird die lokale CCcam-Instanz normalerweise als automatisch erstellter Benutzer in OScam mit Gruppenberechtigungen angezeigt, die inoscam.user definiert sind. Stellen Sie sicher, dass die Gruppe im Radegast-Reader mit dem übereinstimmt, auf das dieser Benutzer Zugriff hat.

Einstellungfallback = 1 auf einem Radegast-Reader sagt OScam, dass es nur verwendet werden soll, wenn andere Reader fehlschlagen. Nützlich, wenn Sie eine primäre lokale Karte haben und die Radegast-Quelle ein Backup ist — es verhindert unnötiges ECM-Weiterleiten an die Remote, wenn die lokale Karte damit umgehen kann.

Fehlerbehebung: Keine Karten, Keine Dekodierung, Verbindung abgelehnt

Dies ist der Abschnitt, der tatsächlich wichtig ist. Die meisten Anleitungen dumpen einen Konfigurationsblock und nennen es erledigt. Die eigentliche Arbeit beginnt, wenn die Konfiguration eingerichtet ist und trotzdem etwas nicht funktioniert.

OScam-Protokolle mit Debug-Level 4 für Reader-Verkehr lesen

Erster Schritt: Erhöhen Sie das Logging. Inoscam.conf unter dem[global] Abschnitt:

[global]

Dann neu starten mit Debug-Level:oscam -d 255 (von der Kommandozeile) oderdebuglevel = 255 zu dem[global] Block für persistentes Debug-Logging hinzufügen. Auf Level 4+ sehen Sie einzelne ECM-Zeilen, die die CAID, die Provider-ID, das hex ECM selbst und ob der Reader eine CW- oder eine "nicht gefunden"-Antwort zurückgegeben hat. Auf 255 erhalten Sie alles — laut, aber vollständig.

Eine erfolgreiche ECM-Zeile sieht ungefähr so aus:ECM 0500<hexstring> CW gefunden (127ms) von radegast_lan. Ein Fehler sieht so aus:ECM 0500<hexstring> CW nicht gefunden. Der Unterschied zwischen "nicht gefunden" und "keine Antwort" ist wichtig — siehe unten.

'Verbindung abgelehnt' vs 'verbunden, aber keine ECM-Antwort'

"Verbindung abgelehnt" bedeutet eines: Die TCP-Verbindung ist fehlgeschlagen. Der Port hört nicht zu, oder eine Firewall hat das SYN verworfen. Überprüfen Sie den Server mitss -tlnp | grep 8888, überprüfen Sie dann iptables/nftables auf der Serverseite. Überprüfen Sie auch dieerlaubte Liste inoscam.conf — OScam verwirft Verbindungen von IPs, die nicht in dieser Liste stehen, bevor der Reader sie überhaupt sieht, und das kann wie eine Firewall-Abweisung von der Client-Seite aussehen.

"Verbunden, aber keine ECM-Antwort" ist ein ganz anderes Problem. Der TCP-Pfad ist in Ordnung. Irgendetwas auf der Protokollebene ist falsch. CAID- oder Identitätsmismatch ist die häufigste Ursache — die upstream Quelle hat einfach keine Karte, die den angeforderten Dienst entschlüsseln kann. Überprüfen Sie mit tcpdump:tcpdump -i any port 8888 -X während der Client versucht zu dekodieren. Wenn Sie ECM-Pakete am Server ankommen sehen und nichts zurückgeht, hat der Server die Anfrage erhalten, konnte aber kein CW finden.

CAID/Provider-Mismatch und leere Kartenlisten

Ein Reader, der sich verbindet, aber leere Kartenlisten zurückgibt, hat fast immer ein Filterproblem. Entweder dascaid Feld im Reader stimmt nicht mit dem überein, was die Quelle überträgt, oder dasident Feld hat eine Provider-ID, die auf der Karte nicht existiert.

Rufen Sie die OScam-Weboberfläche auf dem Server ab (Port 8888 oder 16002 — nicht derselbe Port wie Radegast, wählen Sie unterschiedliche Werte für jeden) und überprüfen Sie den Reader-Status. Es sollte anzeigen, welche CAIDs und Provider-IDs die Karte meldet. Vergleichen Sie das mit Ihrer Reader-Konfiguration auf dem Client. Selbst eine einzige hexadezimale Ziffer, die im Provider-ID falsch ist, führt zu einem leeren Ergebnis ohne Fehlermeldung.

Außerdem: Einige Builds von OScam haben das Radegast-Modul eingebaut, aber mit subtil fehlerhafter CAID-Zählung. Wenn alles andere in Ordnung ist und Sie immer noch leere Listen erhalten, testen Sie mitcaid undident vollständig entfernt — wenn Karten erscheinen, waren Ihre Filterwerte falsch. Fügen Sie sie nacheinander wieder hinzu.

MTU-, NAT- und Firewall-Probleme über das Internet

Wenn Sie Radegast über eine WAN-Verbindung betreiben (bereits eine schlechte Idee für Klartext, aber lassen Sie uns das trotzdem debuggen), kann MTU-Fragmentierung ECM-Nutzlasten stillschweigend beschädigen. Das klassische Symptom ist intermittierendes Dekodieren — einige Kanäle funktionieren, andere nicht, und es scheint zufällig. Führen Sieping -M do -s 1400 remote_server_ip vom Client aus, um den Pfad-MTU zu testen. Wenn Sie Antworten auf Fragmentierung benötigen erhalten, senken Sie Ihre MTU im Tunnel oder fügen Sie eine Clamp-Regel hinzu.

CGNAT ist ein schwierigeres Problem. Wenn sich die Client-Maschine hinter Carrier-Grade NAT befindet, funktionieren eingehende Verbindungen zu dieser Maschine einfach nicht — cs357x erfordert, dass der Server erreichbar ist. Verwenden Sie entweder cs378x (Client initiiert die ausgehende Verbindung) oder richten Sie ein WireGuard-Tunnel ein, der einen stabilen routbaren Pfad erstellt.

Einfrieren und CW-nicht-gefunden bei Hochbitratkanälen

Einfrieren nach ein paar Sekunden, insbesondere bei Hochbitratkanälen, ist fast immer ein Latenzproblem. DVB-S2-Krypto-Zeiträume dauern etwa 10 Sekunden. Der Client muss ein frisches CW erhalten, bevor das aktuelle abläuft. Wenn Ihr Radegast-Reader über eine langsame WAN-Verbindung mit 200 ms+ RTT verfügt, kann die ECM-Roundtrip genug von diesem Fenster verbrauchen, sodass das CW zu spät ankommt.

UHD-Kanäle sind schlimmer — sie verwenden manchmal kürzere Krypto-Zeiträume und höhere ECM-Frequenzen. Ein Link, der für SD in Ordnung ist, wird bei UHD einfrieren. Messen Sie die tatsächlichen ECM-Antwortzeiten im Debug-Log (der Zeitwert in der ECM-Zeile). Alles über 2-3 Sekunden ist ein Problem für die meisten Kanäle. Beheben Sie die zugrunde liegende Routing-Problematik, bevor Sie das Protokoll beschuldigen.

Mixed-endian-Firmware auf älteren Receivern ist ein separater Sonderfall. Einige ältere STB-Firmware liest CWs von einer Radegast-Quelle falsch — die Bytes kommen umgekehrt an — was zu intermittierendem schwarzen Bildschirm führt, der sich auf einem ungefähr 10-Sekunden-Zyklus klärt und wieder einfriert. Wenn Sie dies auf einem bestimmten Receiver sehen, aber nicht auf anderen, ist die STB-Firmware der Verdächtige, nicht Ihre OScam-Konfiguration.

Sicherheits- und Zuverlässigkeits-Härtung für Radegast

Dieser Teil wird in den meisten Berichten übersprungen, was ein Teil des Grundes ist, warum Radegast den Ruf hat, von Natur aus unsicher zu sein. Es ist nicht die Schuld des Protokolls — es wurde für ein vertrauenswürdiges LAN entworfen. Das Problem sind die Menschen, die es über diesen Kontext hinaus ohne zusätzlichen Schutz verwenden.

Setzen Sie niemals einen Klartext-Radegast-Port dem offenen Internet aus

Rohes Radegast auf einer öffentlichen IP bedeutet, dass jeder, der Port 8888 erreichen kann, ECM-Anfragen senden und CWs empfangen kann. Ihre Firewallerlaubte Liste hilft, aber IP-Spoofing und Hijacking sind im offenen Internet real. Über das Zugriffssteuerungsproblem hinaus sind die Daten selbst im Klartext auf dem Draht — für jeden sichtbar, der sich auf dem Pfad zwischen Client und Server befindet.

Wenn Sie Port 8888 in den Portweiterleitungsregeln Ihres Routers geöffnet haben und an eine öffentliche IP gebunden ist, schließen Sie ihn jetzt. Verwenden Sie stattdessen einen Tunnel.

Tunneling Radegast über SSH oder WireGuard/OpenVPN

Die lokale Portweiterleitung über SSH ist die schnellste Lösung, wenn Sie bereits SSH-Zugriff auf den Server haben:

ssh -L 8888:127.0.0.1:8888 user@your_server_ip -N

Dies bindet Port 8888 lokal auf dem Client-Rechner und leitet ihn über die verschlüsselte SSH-Verbindung an den localhost:8888 des Servers weiter. Ihr OScam-Reader auf dem Client zeigt dann auf127.0.0.1,8888 anstelle der IP des Servers. Der Radegast-Verkehr ist Ende-zu-Ende verschlüsselt und gelangt niemals unverschlüsselt ins Internet. Dieerlaubte Liste des Servers sollte127.0.0.1 enthalten, damit dies funktioniert.

WireGuard ist die sauberere Option für eine dauerhafte Einrichtung. Sobald der WireGuard-Tunnel eingerichtet ist, zeigt der Radegast-Reader auf die interne WireGuard-IP des Servers (z. B.10.0.0.1,8888), und der gesamte Verkehr wird automatisch durch den verschlüsselten Tunnel geleitet. Es ist nicht notwendig, eine SSH-Sitzung aufrechtzuerhalten. Auf einem Raspberry Pi oder ähnlichem stromsparenden Gerät verursacht WireGuard im Vergleich zu OpenVPN nur minimalen CPU-Overhead.

Die 'erlaubte' Zugriffsliste und Gruppen pro Reader verschärfen

Selbst in einem LAN sollten Sieerlaubt nicht auf einen breiten Bereich setzen, es sei denn, jedes Gerät in diesem Bereich sollte Zugriff haben. Wenn nur ein Gerät eine Verbindung herstellen soll, fügen Sie nur die IP dieses Geräts in die Liste ein. OScam protokolliert abgelehnte Verbindungsversuche, sodass Sie sehen können, ob etwas Unerwartetes versucht, sich zu verbinden.

Das Gruppensystem von OScam ist hier ebenfalls Ihr Freund. Wenn die Anmeldeinformationen eines Clients (oder die IP, für den IP-basierten Zugriff von Radegast) kompromittiert werden, begrenzt eine gut konfigurierte Gruppeneinrichtung den Explosionsradius. Diese kompromittierte Verbindung kann nur auf Reader in ihren zugewiesenen Gruppen zugreifen — nicht auf Ihren gesamten Kartenpool.

Bevorzugung von cs378x, wenn ein Remote-Link unvermeidlich ist

Wenn Sie unbedingt einen Radegast-ähnlichen Link über das Internet betreiben müssen und ein Tunnel keine Option ist, ist cs378x die bessere Wahl gegenüber rohem cs357x. Die Authentifizierungsschicht bedeutet, dass eine zufällige IP nicht einfach verbinden und CWs abrufen kann — sie benötigt gültige Anmeldeinformationen. Es ist keine starke Verschlüsselung, aber es ist bedeutend besser als offenes Radegast.

Kombinieren Sie cs378x mit einer engenerlaubten Liste, die auf die statische IP des Clients beschränkt ist, und Sie haben eine Einrichtung, die zumindest für ein privates Heimlabor verteidigbar ist.

CCcamRadegast-Protokoll einrichten und konfigurieren richtig zu machen, hängt hauptsächlich davon ab, zu verstehen, in welcher Schicht ein Problem liegt — TCP/Firewall, CAID-Routing oder das Protokoll selbst — und die richtigen Debug-Tools zu haben, um sie auseinanderzuhalten. Die obigen Konfigurationszeilen sind die funktionierende Basis. Wenn etwas nicht funktioniert, sagt Ihnen das OScam-ECM-Protokoll und ein schnelles tcpdump genau, wo die Kette unterbrochen ist.

Ein letzter Randfall, den es wert ist, erwähnt zu werden: Wenn Sie ein vollständigesCCcam Radegast-Protokoll einrichten und konfigurieren von Grund auf neu durchführen und OScam Ihren[radegast] Block stillschweigend ignoriert, überprüfen Sie immer zuerstoscam --show-info. Ein ohneREADER-RADEGAST kompiliertes Binary wird die Konfigurationsdatei ohne Fehler analysieren und einfach den Listener nicht aktivieren — keine Warnung, kein Logeintrag, nur ein Port, der sich nie öffnet. Das trifft viele Leute, die vorgefertigte Pakete aus Repositories verwenden, die mit einem minimalen Funktionsumfang kompiliert werden.