MgCamd Share öffnet sich nicht: Fehlerbehebung (OSCam/CCcam)

Wenn Sie hier gelandet sind, weil Sie nachmgcamd: share not opening решениеsuchen, wissen Sie bereits, wie frustrierend es ist, einen grünen Verbindungsstatus zu sehen, während Ihre Kanäle komplett schwarz bleiben. Die Verbindung scheint hergestellt zu sein. MgCamd stürzt nicht ab. Aber nichts wird entschlüsselt. Dieser Leitfaden behandelt die tatsächlichen Ursachen in der Reihenfolge der Wahrscheinlichkeit — beginnend mit Ihrer lokalen Konfiguration und endend beim Server.

Dies ist kein "füllen Sie diese Vorlage aus" Leitfaden. Jeder Abschnitt unten geht davon aus, dass Sie bereits MgCamd am Laufen haben und die Anmeldedaten zur Hand — Sie können nur kein Kartenwort daraus erhalten.

Was 'Share Not Opening' in MgCamd tatsächlich bedeutet

Der Ausdruck "share not opening" beschreibt einen spezifischen Fehlerzustand, der völlig anders ist als ein Anmeldefehler. MgCamd authentifiziert sich erfolgreich beim newcamd-Server — Benutzer, Passwort, Port stimmen alle — aber wenn Ihre Box auf einen Kanal umschaltet und eine ECM (Entitlement Check Message) sendet, kommt kein entschlüsseltes Steuerwort (dcw) zurück. Der Kanal ist verschlüsselt. Die Dekodierschleife beginnt nie. Schwarzer Bildschirm.

Die meisten Leitfäden verwechseln "kann nicht verbinden" mit "share not opening" und deshalb sind sie für dieses Problem nutzlos.

Verbindung aktiv vs. Dekodierung fehlgeschlagen — zwei verschiedene Probleme

Ein Anmeldefehler sieht aus wie eine Verbindung, die sofort abbricht oder nie als verbunden angezeigt wird. MgCamd protokolliert etwas wieAnmeldung fehlgeschlagenoder versucht einfach wiederholt, sich erneut zu verbinden. Sie werden sehen, dass die Verbindung in/var/log/mgcamd.logoder wo auch immer Ihr Image es protokolliert, springt.

Ein Dekodierungsfehler ist leiser. Die Verbindung scheint aktiv zu sein. MgCamd betrachtet sich als verbunden. Aber die ECM, die Ihre Box sendet, bleibt unbeantwortet. Der Kanal öffnet sich nie, weil niemand ein gültiges CW für den aktuellen Verschlüsselungszeitraum zurücksendet — der alle 10 Sekunden auf den meisten Systemen wechselt.

Lesen des MgCamd-Protokolls: ECM-Anfrage, Antwort und Timeout-Markierungen

Erste Sache: Erhöhen Sie die Ausführlichkeit. In/var/keys/mg_cfgfinden Sie die Debug-Zeile und setzen Sie sie auf Stufe 3:

G: { 03 }

Mit dieser Einstellung sieht ein gesundes Dekodieren im Protokoll etwa so aus:

[mgcamd] ecm für caid 0x0500 pid 0x0136 provider 0x032820

Ein fehlerhaftes sieht so aus:

[mgcamd] ecm für caid 0x0500 pid 0x0136 provider 0x032820

Oder schlimmer, Sie erhalten überhaupt keine ECM-Anfrage im Protokoll — was bedeutet, dass MgCamd nicht einmal die CAID des Kanals an diese Verbindung weiterleitet. Anderes Problem, derselbe schwarze Bildschirm.

Newcamd-Protokollfluss: Anmeldung OK, aber kein dcw

Der Newcamd-Handshake hat zwei Phasen. Phase eins: TCP-Verbindung, DES-Schlüsselaustausch, Benutzer-/Passwortauthentifizierung. Phase zwei: tatsächlicher ECM/dcw-Verkehr. Sie können Phase eins vollständig bestehen und trotzdem Phase zwei fehlschlagen. Ein falscher DES-Schlüssel ist das klassische Beispiel — der Handshake wird manchmal in einem verschlechterten Zustand abgeschlossen, der "verbunden" anzeigt, aber nichts produziert. Eine abgelaufene Karte auf dem Server ist ein weiteres Beispiel: Anmeldung funktioniert einwandfrei, Berechtigungsprüfung gibt leer zurück.

Schritt 1: Überprüfen Sie die Newcamd-Zeile und den DES-Schlüssel

Öffnen Sie/var/keys/newcamd.listund sehen Sie sich Ihre CWS-Zeile an. Das Format ist:

CWS = hostname port username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Der letzte Block ist der DES-Schlüssel. Er muss genau 14 Bytes lang sein — geschrieben als 14 durch Leerzeichen getrennte Hex-Paare. Einige Konfigurationen schreiben ihn ohne Leerzeichen als 28-stelligen Hex-String. Beide Formate existieren; wissen Sie, welches Ihr Image erwartet.

newcamd.list Syntax: CWS = host port user pass DES-key

Eine vollständige funktionierende Zeile sieht so aus:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Nach dem DES-Schlüssel können Sie optional eine CAID und eine Anbieter-ID anheften:

CWS = myserver.example.com 17000 myuser mypassword 01 02 03 04 05 06 07 08 09 10 11 12 13 14 0500 032820

Wenn die CAID/Identifikation falsch ist, wird nichts für diesen Anbieter auf dieser Zeile dekodiert, selbst wenn der Server die Karte hat.

Der 14-Byte (28 hex Zeichen) DES-Schlüssel-Fehler

Dies ist die häufigste Ursache für das Problem "verbunden, aber schwarz". Jemand kopiert einen DES-Schlüssel mit einem nachfolgenden Leerzeichen, lässt ein Zeichen weg oder fügt ihn aus einem PDF ein, das eine Null für den Buchstaben O ersetzt hat. Der Schlüssel sieht auf den ersten Blick gut aus. MgCamd verbindet. Nichts dekodiert.

Zähle deine Zeichen. Wenn der Schlüssel als Paare geschrieben ist, die durch Leerzeichen getrennt sind: zähle 14 Paare. Wenn es sich um eine durchgehende Hex-Zeichenfolge handelt: zähle genau 28 Zeichen. Nicht 27. Nicht 29. 28.

Achte auch auf Inkonsistenzen zwischen Klein- und Großbuchstaben. Das Newcamd-Protokoll ist für Hexadezimalzahlen nicht groß-/kleinschreibungssensitiv, aber einige MgCamd-Bauten haben sich mit gemischten Groß- und Kleinbuchstaben-Schlüsseln als problematisch erwiesen. Normalisiere auf Großbuchstaben, wenn du einem Gespenst nachjagst.

Erreichbarkeit testen: telnet/nc zum Newcamd-Port

Bevor du die Konfiguration beschuldigst, bestätige, dass die TCP-Verbindung tatsächlich von deinem Rechner funktioniert:

nc -zv myserver.example.com 17000

Du möchtest sehenVerbindung zu myserver.example.com 17000 Port [tcp/*] erfolgreich!. Wenn es zeitüberschreitet oder verweigert wird, erreichst du den Server nicht einmal — MgCamd zeigt "verbunden", während dies fehlschlägt, bedeutet, dass es einen zwischengespeicherten/abgelaufenen Zustand gibt, der beim Neustart gelöscht wird.

Häufige Portnummern und Firewall/NAT-Überprüfungen

Newcamd-Ports variieren je nach Serverkonfiguration, laufen aber normalerweise zwischen 10000–20000. Einige Betreiber verwenden 17000, 15000 oder benutzerdefinierte Bereiche. Wenn du hinter CGNAT oder Double-NAT (häufig bei mobilem Internet oder einigen ISPs) bist, kann die TCP-Verbindung von deinem Rechner lokal hergestellt erscheinen, aber der Server sieht niemals einen echten Socket. Der "verbunden"-Status in MgCamd basiert auf dem Abschluss des lokalen TCP-Handshakes — es beweist nicht, dass der serverseitige Socket funktionsfähig ist.

Teste von einem anderen Netzwerk, wenn du NAT-Probleme vermutest. Überprüfe auch, ob keine Firewall auf deinem Router stillschweigend ausgehende Verbindungen an diesem Port blockiert.

Schritt 2: Überprüfe CAID, Anbieter und ECM PID-Routing

Selbst mit einer perfekten newcamd.list können ECMs nirgendwohin gehen, wenn MgCamd sie an die falsche Zeile weiterleitet oder der Leser des Servers diese CAID nicht unterstützt. Dies ist die zweithäufigste Ursache fürmgcamd: share not opening решениеProbleme — und es ist fast immer unsichtbar ohne ausführliches Logging.

Eine Zeile auf die richtige CAID/Identifikation beschränken

In/var/keys/mg_cfgdefiniert derC:Block, welche CAIDs jede Zeile verarbeitet. Ein Beispiel:

C: ( 0500 )

Die zweite Form bindet an eine spezifische Anbieter-Identifikation innerhalb der CAID. Wenn dein Server nur die Identifikation 032820 hat, du aber ECMs für die Identifikation 040810 sendest, kommen diese Anfragen leer zurück. Passe die Identifikation an das an, was der Server tatsächlich hat — frage den Betreiber, wenn du es nicht weißt, oder überprüfe das OSCam-Webinterface.

Wenn die CAID des Kanals nicht im Leser ist

Einige Kanäle senden mehrere CAIDs auf demselben Transponder. Dein Receiver könnte CAID 0x0100 (Seca) auswählen, während der Server nur 0x0500 (Viaccess) hat. Die Lösung besteht entweder darin, deinen Receiver zu zwingen, die CAID zu verwenden, die der Server hat, oder die Prioritätenliste von MgCamd so zu konfigurieren, dass die richtige bevorzugt wird. In mg_cfg setzen dieP:Zeilen die Prioritätsreihenfolge für CAIDs, wenn mehrere Optionen verfügbar sind.

ECM PID und mehrere CAID-Transponder

Dieser Grenzfall trifft häufig auf Menschen zu. Ein Transponder trägt einen Kanal, der mit zwei verschiedenen CA-Systemen verschlüsselt ist — sagen wir Nagravision auf PID 0x0600 und Irdeto auf PID 0x0601. Dein Receiver könnte sich auf die Irdeto PID festlegen, weil sie zuerst in der PMT aufgeführt ist. MgCamd sendet das ECM an deine Irdeto-Zeile, die keine Karte hat. In der Zwischenzeit sitzt deine Nagravision-Zeile untätig mit einer perfekt gültigen Karte, die es sofort dekodieren würde.

Zwinge die ECM PID in den Kanaleinstellungen deines Receivers, wenn dein Image dies unterstützt, oder konfiguriere MgCamd so, dass diese spezifische CAID ausschließlich an die richtige Zeile weitergeleitet wird.

Prioritäts- und Ignorierlisten (mg_cfg C:/P: Einträge)

DieI:(Ignorieren)-Zeilen in mg_cfg sind das Gegenteil vonC:— sie sagen MgCamd, dass eine bestimmte CAID/Identifikation niemals an eine bestimmte Zeile gesendet werden soll. Verwende diese, wenn du mehrere Zeilen hast und verhindern möchtest, dass eine schwache Zeile ECMs abfängt, auf die sie nicht antworten kann:

Ich: ( 0500:040810 )

Kombiniert mit explizitenP:Prioritätseinträgen können Sie jede CAID/Identifikation genau einer Zeile zuordnen und Rennbedingungen zwischen mehreren CWS-Einträgen eliminieren.

Schritt 3: Diagnose von der Serverseite (OSCam/CCcam)

An diesem Punkt, wenn Ihre Konfiguration korrekt aussieht, könnte das Problem überhaupt nicht in Ihrer Box liegen. Die Sichtbarkeit von der Serverseite trennt eine 20-minütige Lösung von einer 3-stündigen Debugging-Sitzung.

OSCam newcamd-Server: [newcamd] Schlüssel, Port und Benutzerblock

Wenn der Server OSCam ausführt, überprüfen Sie/etc/oscam/oscam.conf und/etc/oscam/oscam.server. Der newcamd-Listener benötigt einen eigenen Abschnitt inoscam.conf:

[newcamd]

Derkey = hier muss genau mit dem DES-Schlüssel in Ihrernewcamd.list übereinstimmen. Die Portbindung fügt optional@CAID:ident hinzu, um einzuschränken, was dieser Listener bereitstellt. Wenn die CAID/Identifikation in Ihrer Box nicht übereinstimmt, kann OSCam das ECM akzeptieren und sofort verwerfen.

Benutzerkonten befinden sich in/etc/oscam/oscam.user. Bestätigen Sie, dass Ihr Benutzername die korrekte CAID und Identifikation in dencaid = undident = Feldern hat, und dassdisabled = 0 ist.

OSCam webif-Status: Leser, ecm und 'nicht gefunden' vs 'Zeitüberschreitung'

Die Weboberfläche von OSCam (gewöhnlich erreichbar über Port 8888 oder 8383) ist das nützlichste Diagnosetool, das Sie haben. Unter dem Tab ECM-Historie sehen Sie eines von drei Ergebnissen für eingehende ECM-Anfragen:

• gefunden — die Karte hat es decodiert, ein gültiges CW ging zurück an MgCamd. Wenn Ihre Box immer noch schwarz ist, liegt der Fehler lokal.
• nicht gefunden — OSCam hat das ECM empfangen, aber kein Leser konnte darauf antworten. Karte fehlt, falsche CAID oder kein Anspruch.
• Zeitüberschreitung — OSCam hat das ECM upstream weitergeleitet, aber innerhalb der konfigurierten Zeitüberschreitung keine Antwort erhalten. Problem mit dem upstream-Hops.

Diese dreifache Aufteilung lokalisiert den Fehler genau. "Gefunden, aber schwarz" ist ein lokales PID/CAM-Problem. "Nicht gefunden" ist ein Karten-/Anspruchsproblem. "Zeitüberschreitung" ist ein Problem mit der upstream-Kette.

CCcam newcamd Export und Freigabeverfügbarkeit

Für CCcam-Server, überprüfen Sie/etc/CCcam.cfg. Der newcamd Exportbereich benötigt einenNEWCAMD LISTEN PORT: Eintrag und entsprechendeN: host port username password DES-key Clientdefinitionen — oder das serverseitige Äquivalent für ausgehende Freigaben. Auf den CCcam-Infoseiten (normalerweise Port 16001) überprüfen Sie, ob die Karte, die Sie erwarten, tatsächlich in der Freigabeliste enthalten und als lokal verfügbar markiert ist, nicht nur als eine entfernte Freigabe von einem anderen Hop, der möglicherweise nicht funktioniert.

Kartenverfügbarkeit, AU und Berechtigungsprüfungen

Eine technisch perfekte Konfiguration kann trotzdem "Freigabe öffnet nicht" produzieren, wenn die Karte selbst keine gültige Berechtigung hat. Karten laufen ab. Anbieter rotieren Schlüssel mit EMM-Updates. Wenn AU (Automatisches Update) nicht funktioniert — die Karte muss physisch in einem Leser sein, der mit einem Server verbunden ist, der aktiv EMMs empfängt — verfallen die Berechtigungen und die Dekodierung stoppt, obwohl die Karte vorhanden ist und OSCam sie als aktiv anzeigt.

Überprüfen Sie auf OSCam den Leserstatus im Webinterface: schauen Sie sich die Berechtigungsübersicht und den letzten EMM-Zeitstempel an. Eine Karte, die seit Tagen keine EMM erhalten hat, ist verdächtig.

Schritt 4: Timing, Cache und ECM-Ratenlimits beheben

Wenn die Konfiguration korrekt ist und die Karte Berechtigungen hat, Sie aber trotzdem intermittierende schwarze Bildschirme oder Einfrieren nach ein paar Sekunden haben, liegt das Problem an der Zeitsteuerung. Dies betrifft die schwierigste Kategorie vonmgcamd: Freigabe öffnet nicht решение Problemen, da sie jedes Mal anders aussehen.

ECM-Timeout-Anpassung in mg_cfg (M: / T: Werte)

Das Timeout von MgCamd für das Warten auf eine dcw-Antwort wird durch denM: (max ecm time) Wert in mg_cfg gesteuert, oft in Einheiten von 100ms ausgedrückt. Eine Einstellung wie:

M: { 3 }

Bedeutet, dass MgCamd 300ms wartet, bevor es aufgibt, eine CW-Antwort zu erhalten. Für einen Server, der zwei Hops entfernt ist und etwas Latenz hat, ist das eng. Erhöhen Sie es auf 6 oder 8 (600–800ms) und testen Sie. Zu hoch zu gehen, schafft ein anderes Problem — Sie könnten einen CW-Rotationszeitraum verpassen und anstelle eines nahtlosen Bildes ein Einfrieren erhalten. Balancieren Sie es basierend auf Ihrer tatsächlichen Serverlatenz.

Das Muster des Einfrierens nach ein paar Sekunden tritt speziell auf, wenn die CW-Rotation erfolgt (ungefähr alle 10 Sekunden) und die neue CW nicht rechtzeitig ankommt. Die vorherige CW läuft ab, das Bild friert ein, und je nach Ihrem Gerät kann es sich erholen oder nicht. Strengere Zeitkontrolle auf der Serverseite oder die Verwendung des CW-Caches von OSCam kann dies glätten.

cache-ex / cache Peers, die veraltete CWs verursachen

Die cache-ex-Funktion von OSCam ermöglicht es mehreren OSCam-Instanzen, dekodierte CWs zu teilen. Dies ist normalerweise ein Leistungsgewinn — eine CW, die gerade von einem Server dekodiert wurde, wird sofort dem nächsten Anforderer bereitgestellt. Aber ein falsch konfiguriertes Cache-Peer kann eine veraltete CW aus dem vorherigen Kryptoperioden bereitstellen. Ihr Gerät erhält eine CW, die gültig aussieht, wendet sie an, und das Bild ist Müll oder eingefroren, weil die Verschlüsselung bereits rotiert hat.

Wenn Sie ein kurzes Bild sehen (1–2 Sekunden, dann Einfrieren), deaktivieren Sie cache-ex vorübergehend und sehen Sie, ob es stabiler wird. Wenn ja, gibt das Cache-Peer falsche Daten zurück.

ECM-Ratenbegrenzung und 'zu viele ecm' Drosselung

Server unter Last implementieren oft ECM-Ratenbegrenzung pro Benutzerkonto. Wenn Ihr Gerät ECMs zu schnell sendet (Kanalwechsel, schlechtes PMT-Parsing, das doppelte Anfragen sendet), beginnt der Server, Anfragen abzulehnen. In den OSCam-Protokollen zeigt sich dies alszu viele ecm oder einfach Stille — das ECM wird empfangen und ohne Antwort verworfen.

Schwarze Bildschirme nur zu Stoßzeiten sind fast immer dies. Der Leser des Servers ist überfordert. Es gibt nicht viel, was Sie auf der Client-Seite tun können, außer unnötigen ECM-Verkehr zu reduzieren — scannen Sie die Kanäle nicht schnell, stellen Sie sicher, dass Ihr Gerät keine doppelten ECMs für dasselbe PID sendet, und warten Sie die Stoßzeit ab.

Interferenzen von einem zweiten CAM (Softcam-Priorität)

Dies ist subtil und verursacht wirklich das Szenario "gestern funktioniert, heute kaputt". Wenn ein zweites Softcam installiert oder aktiviert wurde — oder wenn Ihr Image einen integrierten Decoder hat, der bei bestimmten CAIDs aktiviert wird — kann es das ECM abfangen, bevor MgCamd es erhält. Das integrierte CAM kann nicht dekodieren (keine Karte), gibt nichts zurück, und MgCamd sieht die Anfrage überhaupt nicht, weil das ECM upstream verbraucht wurde.

Überprüfen Sie die CAM-Prioritätseinstellungen Ihres Images und stellen Sie sicher, dass MgCamd die höchste Priorität für die CAIDs hat, die Sie teilen. Deaktivieren Sie konkurrierende CAMs vollständig für diese CAIDs, wenn Ihr Image dies unterstützt. Das Symptom ist: Das ECM-Protokoll in MgCamd zeigt keine Anfragen für einen Kanal, der sie anfordern sollte.

Systematisch durch diese Schritte zu arbeiten, ist der einzige zuverlässige Weg, wenn man mitmgcamd: share not opening решение Fehlern konfrontiert ist — es gibt keine einzelne Lösung, da der Fehler an sechs verschiedenen Stellen auftreten kann. Beginnen Sie lokal (DES-Schlüssel, CAID-Routing), wechseln Sie zur serverseitigen Überprüfung (OSCam-Webinterface, CCcam-Sharing), und untersuchen Sie dann Timing und Interferenzen. Die OSCam "gefunden / nicht gefunden / Zeitüberschreitung"-Aufteilung ist das leistungsstärkste Diagnosewerkzeug, das verfügbar ist, und die meisten Menschen nutzen es nie.