MGCamd Reshare Setup: Vollständige Konfiguration& Newcamd Anleitung

Eine ordentlichemgcamd reshare Einrichtung bringt viele Leute durcheinander — und das aus gutem Grund. Die meisten Anleitungen im Internet gehen davon aus, dass MGCamd wie ein Mini-Server funktioniert, auf den man einfach andere Receiver ausrichten kann. Das tut es nicht. MGCamd ist ein Client. Dieses Verständnis ist der Unterschied zwischen einem Abend mit Debugging und tatsächlich dem Entschlüsseln Ihrer downstream Boxen.

Diese Anleitung behandelt die gesamte Architektur: welche Dateien was steuern, wie man durchOScam für echtes Resharing bridgt und wie man die häufigsten Fehlermodi debuggt, einschließlich des frustrierenden Problems "Quelle entschlüsselt gut, aber downstream friert ein".

Wie MGCamd Resharing tatsächlich funktioniert

MGCamd als Client vs. als Reshare-Quelle

MGCamd ist grundsätzlich einnewcamd/cs357x Client. Es verbindet sich upstream, empfängt Steuerwörter (CWs) und übergibt sie an Ihren lokalen Tuner. Das ist seine Aufgabe. Es gibt keinen integrierten newcamd Server-Daemon, der auf downstream Verbindungen hört — MGCamd öffnet keinen Port, auf den andere Receiver zugreifen können.

Wenn also Leute von einer mgcamd reshare Einrichtung sprechen, meinen sie tatsächlich (ob sie es wissen oder nicht), MGCamd zu verwenden, um die upstream Linie zu empfangen und diese dann durch etwas anderes — typischerweise OScam — zu bridgen, um downstream Clients zu bedienen.

Die Newcamd Protokollkette: Client → MGCamd → Downstream

Die realistische Kette sieht so aus: Ihre upstream Kartenlinie verbindet sich über das newcamd Protokoll mit MGCamd. MGCamd entschlüsselt und übergibt CWs lokal. OScam, das auf derselben Box läuft, verbindet sich mit demselben Upstream als newcamd Leser — oder, wenn Sie clever sind, liest es aus dem Shared Memory von MGCamd. OScam betreibt dann seine eigenen newcamd/cccam Serverports, mit denen sich downstream Receiver verbinden.

Reshare-Tiefe — manchmal als Hops bezeichnet — ist, wie oft ein CW weitergeleitet werden kann, bevor es blockiert wird. Jeder Hop fügt Latenz hinzu. Bei zwei Hops tief schauen Sie bereits auf 400–800ms ECM-Zeiten, wenn irgendetwas in der Kette hakt.

Warum MGCamd allein für Resharing begrenzt ist

MGCamd 1.35, 1.38 und 1.45 haben alle keinen Server-Listener. Sie können das Cache-Sharing über cache-ex konfigurieren, um CWs mit Peers auszutauschen, aber das ist ein lateraler CW-Austausch zwischen Gleichgestellten, kein echtes Server-Client Reshare-Modell. Verschwenden Sie keine Zeit mit der Suche nach einer "reshare port" Einstellung in mg_cfg — sie ist nicht vorhanden.

Einige Drittanbieter-MGCamd-Bauten behaupten, Reshare-Fähigkeiten zu haben, sind aber in der Praxis instabil und schlecht dokumentiert. Die OScam-Brücke ist der Ansatz, der tatsächlich zuverlässig funktioniert.

Wann man MGCamd mit OScam als Reshare-Server kombinieren sollte

Verwenden Sie diese Kombination, wenn Sie eine upstream Linie haben und 2–10 downstream Receiver bedienen möchten. OScam kümmert sich sauber um Authentifizierung, CAID-Filterung, maxhops-Limits und Benutzerberechtigungen für Reshare. MGCamd bleibt als upstream Client, wenn Ihre upstream Linie dies speziell erfordert, obwohl viele Setups MGCamd vollständig überspringen und einfach OScam sowohl als Client als auch als Server verwenden.

Voraussetzungen und Dateianordnung

Erforderliche Dateien: newcamd.list, mg_cfg, cw_list

Drei Dateien erledigen den Großteil der Arbeit in MGCamd.newcamd.list enthält Ihre Serververbindungszeilen — einen CWS-Eintrag pro upstream Linie.mg_cfg steuert das Laufzeitverhalten: Zeitüberschreitungen, Cache-Einstellungen, Debug-Verbosity, Verbindungswiederholungen.cw_list ist optional, aber nützlich — es ermöglicht Ihnen, zu filtern, welche CAIDs und Anbieter MGCamd verarbeitet, was wichtig ist, wenn Sie einen gemischten Feed resharen und nur einige Anbieter weitergegeben werden dürfen.

Gemeinsame Pfade: /var/keys/, /var/emu/, /etc/tuxbox/

Auf Enigma2-Images (OpenPLi, OpenATV usw.) finden Sie typischerweise die MGCamd-Konfiguration unter/var/keys/. Ältere Images, insbesondere auf Gemini basierende oder DreamElite-Bauten, verwenden/var/emu/. Einige eingebettete Builds legen alles unter/etc/tuxbox/config/.

Überprüfen Sie, welches Verzeichnis das Startskript Ihres Builds referenziert, bevor Sie Änderungen vornehmen. Das Bearbeiten der falschen Kopie und sich zu fragen, warum sich nichts ändert, ist ein klassischer Zeitfresser.

MGCamd Versionskompatibilität (1.35 / 1.38 / 1.45)

Die Flag-Namen in mg_cfg haben sich zwischen den Versionen verschoben. MGCamd 1.35 verwendet eine leicht andere cache-ex-Syntax als 1.38 und 1.45. DieM: undG: Blockstruktur ist konsistent, aber Optionen wie die Definition des Cache-Peers haben das Format geändert. Lesen Sie immer die mit Ihrer spezifischen Binärdatei gebündelte README — gehen Sie nicht davon aus, dass eine Konfiguration aus einem Forumspost mit Ihrer Version übereinstimmt.

Überprüfen, ob Ihre Upstream-Leitung dekodiert, bevor Sie sie erneut teilen

Berühren Sie die Reshare-Konfiguration nicht, bis das lokale Dekodieren einwandfrei funktioniert. Schalten Sie auf einen Pay-Kanal, warten Sie 10–15 Sekunden und durchsuchen Sie Ihr MGCamd-Protokoll nach ECM-Zeit:grep "ecm time" /tmp/mgcamd.log. Sie möchten konsistente Zeiten unter 500 ms. Wenn Sie Zeitüberschreitungen oder "kein CW" sehen, bevor Sie versuchen, erneut zu teilen, wird die Reshare-Konfiguration nur Verwirrung über ein Upstream-Problem hinzufügen.

Konfigurieren der newcamd.list-Zeile

Anatomie einer CWS-Zeile: Host Port Benutzer Passwort DES-Schlüssel

Jeder Eintrag innewcamd.list folgt diesem Format:

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

Der DES-Schlüssel sind die letzten 14 Felder, jedes ein zweistelliges Hex-Byte, durch Leerzeichen getrennt. Einige Builds akzeptieren sie ohne Leerzeichen als eine einzige 28-Zeichen-Zeichenfolge. Beide Formate existieren in der Wildnis — überprüfen Sie die Beispielkonfiguration Ihres Builds, um zu wissen, welches erwartet wird.

Whitespace-Sensitivität ist hier real. Ein Tabulator, wo ein Leerzeichen erwartet wird, oder ein zusätzliches Leerzeichen vor dem Zeilenumbruch, kann das Parsen stillschweigend brechen. Verwenden Sie einen Hex-Editor odercat -A um nach versteckten Zeichen zu suchen, wenn eine Zeile sich weigert, eine Verbindung herzustellen.

Der 14-Byte DES-Schlüssel und warum 28 Hex-Zeichen wichtig sind

Der DES-Schlüssel authentifiziert die newcamd-Sitzung. Er ist 14 Bytes — aus genau 28 hexadezimalen Zeichen ausgedrückt. Ein einzelnes falsches Zeichen bedeutet, dass der Handshake fehlschlägt. Der Fehler im Protokoll sieht aus wie eine Verbindungszeitüberschreitung oder "Anmeldung fehlgeschlagen", nicht wie ein Schlüssel-Formatfehler, sodass es leicht ist, ihn mit einem Netzwerkproblem zu verwechseln.

Ihr Upstream-Anbieter gibt Ihnen diesen Schlüssel als Teil Ihrer Leitungsanmeldeinformationen. Kopieren Sie ihn genau. Tippen Sie ihn nicht manuell ein — fügen Sie ihn ein und überprüfen Sie dann die Zeichenanzahl. 28 Zeichen, keine Leerzeichen in der 28-Zeichen-Form, keine Trunkierung.

Einstellen von Reshare/Aktivieren-Flags pro Zeile

Einige MGCamd-Bauten unterstützen nachgestellte Flags in der CWS-Zeile:

CWS = hostname 15000 myuser mypass 01 02 03 04 05 06 07 08 09 10 11 12 13 14 01 00

Die nachgestellten Bytes hier (z.B.01 00) können den Aktivierungs-/Deaktivierungszustand oder Reshare-Hinweise je nach Build anzeigen. In Vanilla MGCamd 1.38/1.45 werden diese zusätzlichen Bytes typischerweise ignoriert. Fügen Sie sie nicht hinzu, es sei denn, die README Ihrer Version dokumentiert spezifisch, was sie tun — undokumentierte Flags fügen Verwirrung ohne Nutzen hinzu.

Mehrere Zeilen, Priorität und Failover-Reihenfolge

MGCamd liest CWS-Zeilen von oben nach unten und versucht sie in dieser Reihenfolge. Die erste Zeile, die mit einem gültigen CW antwortet, "gewinnt" für dieses ECM. Wenn Sie zwei Zeilen haben, die unterschiedliche CAIDs abdecken, setzen Sie Ihre primäre/schnellste Zeile zuerst. Wenn die erste Zeile eine Zeitüberschreitung hat (basierend auf dem Zeitüberschreitungswert in mg_cfg), fällt MGCamd zur nächsten durch.

Failover funktioniert, aber es erhöht die ECM-Zeit um die Zeitüberschreitung der fehlgeschlagenen Zeile. Halten Sie Ihre Zeitüberschreitung so eng, dass das Failover keinen sichtbaren Freeze verursacht — 2000–3000 ms sind ein vernünftiger Ausgangspunkt.

mg_cfg-Flags, die das Resharing und die Stabilität beeinflussen

M: (Konfigurationsmodus) und G: (global) Blöcke

mg_cfg ist in Blöcke strukturiert. DieM: Der Block setzt den Betriebsmodus — ob MGCamd lokale EMM verwendet, CWs teilt oder Cache-EX ausführt. DerG: Block (oder das Äquivalent in deiner Version) legt das globale Verhalten wie Protokollausführlichkeit und Cache-Größe fest. Eine minimale mg_cfg für ein Reshare-Setup sollte ein Protokollniveau haben, das hoch genug ist, um ECM-Zeiten und den Verbindungsstatus zu sehen, aber nicht so ausführlich, dass es /tmp füllt und I/O-Probleme auf Flash-Speicher verursacht.

Cache- und Cache-EX-Einstellungen (C: / Cache-Zeilen)

Der Cache speichert kürzlich empfangene CWs, sodass eine zweite ECM-Anfrage für denselben Schlüssel keinen Netzwerk-Round-Trip benötigt. In einem Reshare-Setup beschleunigt dies die Antwort nach unten — es führt jedoch auch zu einer Falle: Wenn zwei Knoten sich gegenseitig resharen (versehentlicher Loop), können sie veraltete oder falsche CWs austauschen, die zwischengespeichert und wiederholt bereitgestellt werden, was zu einem anhaltenden Einfrieren führt, das wie ein Netzwerkproblem aussieht.

Wenn du Cache-EX-Peers verwendest, stelle sicher, dass die Topologie strikt einseitig ist. Lass Knoten A nicht mit Knoten B peer und Knoten B nicht zurück zu Knoten A peer, es sei denn, du hast explizit Loop-Erkennungsflags gesetzt.

ECM-Timeout, Wiederholungs- und Fallback-Einstellungen

Das ECM-Timeout in mg_cfg steuert, wie lange MGCamd auf ein CW wartet, bevor es eine Zeile als nicht reagierend markiert und die nächste versucht (oder kein CW zurückgibt). Für eine Reshare-Topologie beeinflusst dieses Timeout auch deine downstream Empfänger — sie warten auf MGCamd, das auf upstream wartet.

Ein sicherer Startwert ist 3000ms (3 Sekunden). Unter 1500ms erhältst du falsche Timeouts bei jeder Zeile mit moderater Last. Über 5000ms verursacht ein verpasstes ECM ein sichtbares Einfrieren downstream. Reduziere den Wert, sobald das Setup stabil ist.

Anti-Kaskade und Einstellungen zur Vermeidung von Einfrierungen

Einige MGCamd-Bauten enthalten ein Anti-Kaskaden-Verhalten — das die Anzahl der ECMs pro Sekunde begrenzt, die upstream weitergeleitet werden. Dies schützt deinen upstream-Anbieter vor übermäßiger Last (und schützt dich davor, dass deine Leitung gekappt wird). In einem Reshare-Setup mit mehreren downstream Empfängern kann die ECM-Rate ansteigen, da jeder Empfänger sein eigenes ECM unabhängig sendet. Setze eine angemessene Obergrenze pro Sekunde und überwache deine upstream ECM-Rate im Protokoll.

MGCamd mit OScam für echtes Resharing verbinden

Hier lebt ein funktionales mgcamd Reshare-Setup tatsächlich. OScam kümmert sich um alles, was MGCamd nicht kann: Bereitstellung von downstream-Verbindungen, Benutzerberechtigungen, CAID-Filterung und ordnungsgemäße Kontrolle der Reshare-Tiefe.

oscam.server: Reader Type=newcamd, der auf deine Leitung zeigt

In/etc/oscam/oscam.server definiere einen Reader, der sich mit deiner upstream-Leitung über das newcamd-Protokoll verbindet:

[reader]

Daskey Feld hier ist dein 14-Byte-DES-Schlüssel in 28 hexadezimalen Zeichen, ohne Leerzeichen. Dasgroup Wert verknüpft diesen Reader mit OScam-Benutzern — ein Benutzer in Gruppe 1 kann diesen Reader verwenden. Wenn die Gruppen nicht übereinstimmen, werden keine ECMs weitergeleitet, unabhängig davon, ob alles andere korrekt ist.

oscam.user mit cccam/newcamd-Server + maxhops und Reshare

In/etc/oscam/oscam.user benötigt jedes downstream-Konto eine Reshare-Berechtigung und Gruppenzuweisung:

[account]

reshare = 1 bedeutet, dass dieses Konto eine Ebene weiter teilen kann.reshare = 0 bedeutet, dass der Client dekodieren kann, aber nicht an andere weitergeben kann.cccmaxhops begrenzt, wie viele CCcam-Hops downstream von diesem Benutzer ein CW reisen kann.

oscam.conf Server-Ports (cs378x/newcamd/cccam)

In/etc/oscam/oscam.conf aktiviere die Serverprotokolle, die du downstream anbieten möchtest:

[newcamd]

Die newcamd-Portlinie umfasst CAID- und Ident-Bindung —15001@0500:000000 bedeutet, dass Port 15001 CAID 0500 verarbeitet. Sie können mehrere CAIDs auf separaten Ports binden oder einen generischen Port verwenden. Dies sind die Ports, mit denen Ihre nachgelagerten Receiver verbunden sind, und sie müssen durch jede Firewall oder NAT zwischen Ihnen und Ihren Clients erreichbar sein.

Reshare = N und cccmaxhops korrekt einstellen

Eine häufige Fehlkonfiguration: Einstellungreshare = 1 auf dem Benutzer, abercccmaxhops = 0 lassen, oder umgekehrt. Beide müssen die beabsichtigte Tiefe zulassen. Wenn Ihr upstream-Anbieter maxhops auf 1 auf seiner Seite eingestellt hat, erhält Ihr nachgelagerter Client genau 1 Hop — Sie können das von Ihrer Seite aus nicht überschreiben. Sie können nur weiter einschränken, nicht erweitern.

Für einen einfachen Zwei-Ebenen-Share (Sie → Client),reshare = 1 undcccmaxhops = 1 auf dem Client-Konto ist ausreichend.

Fehlerbehebung: Verbindet, aber wird nicht weitergegeben

Login OK, aber kein ECM weitergeleitet (Gruppen/CAID-Unstimmigkeit)

Dies ist das häufigste Problem in jeder mgcamd Reshare-Konfiguration und es handelt sich immer um eine Gruppen- oder CAID-Unstimmigkeit. Im OScam-Log (/var/log/oscam/oscam.log) suchen Sie nach Zeilen, die "kein passender Reader" oder "keine Karte für CAID" enthalten. Wenn Sie "verbunden" für den Downstream-Client sehen, aber keine ECM-Aktivität, wird der Reader nicht für die Anfragen dieses Benutzers ausgewählt.

Beheben: Stellen Sie sicher, dass dieGruppeNummer in Ihrem oscam.server Reader-Block imGruppenFeld des oscam.user Kontos erscheint. Und stellen Sie sicher, dass die CAID, die der Downstream anfordert, tatsächlich an beiden Stellen aufgeführt ist.

Einfrieren im Downstream, aber Quelle dekodiert einwandfrei

Wenn Ihr lokaler Tuner sauber dekodiert, der Downstream-Empfänger jedoch alle 8–15 Sekunden (eine Krypto-Periode) einfriert, kommt das CW entweder zu spät oder ist falsch. Zu spät = ECM-Zeitüberschreitung, falsch = Cache-Schleife, die ein veraltetes CW bereitstellt.

Durchsuchen Sie das OScam-Log nach ECM-Zeiten im Downstream-Konto:grep "client1" /var/log/oscam/oscam.log | grep "ecm". Wenn die Zeiten sporadisch auf über 2000 ms ansteigen, erhöhen Sie die Zeitüberschreitung. Wenn die Zeiten schnell sind, der Downstream jedoch weiterhin einfriert, vermuten Sie ein falsches CW aus dem Cache — deaktivieren Sie vorübergehend cache-ex, um zu testen.

'Karte nicht gefunden' / Keine Berechtigungen übergeben

Dieser Fehler bedeutet, dass OScam die ECM-Anfrage vom Downstream-Client erhalten hat, aber keinen Reader gefunden hat, der sie verarbeiten kann. Entweder läuft der Reader nicht (prüfen Sie den Status des oscam Readers), der CAID-Filter schließt die Anfrage aus, oder die Upstream-Leitung trägt diesen Anbieter nicht.

Überprüfen Sieoscam.server: wenncaid =zu eng eingestellt ist, werden Anfragen für andere CAIDs auf derselben Leitung stillschweigend verworfen. Ein gemischter CAID-Upstream-Feed, bei dem nur einige CAIDs für Reshare autorisiert sind, ist ein reales Szenario — der Upstream-Anbieter erlaubt möglicherweise 0500 Reshare, aber nicht 1800. Sie können CAIDs, die der Upstream an seinem Ende blockiert hat, nicht resharen.

Reshare-Tiefe erschöpft (maxhops = 0)

Wenn Ihr Upstream-Anbieter seine Leitung auf maxhops = 1 eingestellt hat und Sie an einen Client resharen, hat dieser Client maxhops = 0 — er kann dekodieren, aber nicht weiter resharen. Dies ist kein Konfigurationsfehler Ihrerseits; es sind die Einschränkungen des Upstreams. Keine Anpassung Ihrer OScam-Konfiguration wird die Hops über das hinaus verlängern, was der Upstream erlaubt.

Wenn die Upstream-Leitung selbst mit maxhops = 0 ankommt (das können Sie in den Reader-Informationen von OScam sehen), dann können Sie sie überhaupt nicht resharen — der Upstream hat sie ausdrücklich blockiert. Entweder verhandeln Sie mit Ihrem Anbieter neu oder Sie erhalten eine andere Leitung mit Reshare-Erlaubnis.

NAT-, Firewall- und Double-Hop-Netzwerkprobleme

Ein Downstream-Empfänger hinter einem zweiten NAT-Router (Double-NAT) ist ein häufiges Problem. Die Downstream-Box kann Ihren OScam-Serverport erreichen, aber die TCP-Verbindung von einem Client hinter einem CGNAT oder Double-NAT funktioniert möglicherweise nicht ohne ordnungsgemäße Portweiterleitung auf jeder Ebene.

Für newcamd-Clients initiiert der Server keine Verbindungen — der Client verbindet sich mit Ihrem Serverport. Daher muss Ihr Serverport (z. B. 15001) aus dem öffentlichen Internet erreichbar sein. Auf der Downstream-Seite müssen keine Ports geöffnet sein. Aber wenn Sie selbst hinter CGNAT sind, können Sie nicht einfach einen eingehenden Server hosten — ziehen Sie einen VPN-Tunnel (WireGuard funktioniert gut dafür) zwischen Ihnen und Ihren Downstream-Clients in Betracht.

Überprüfen Sie mit:nc -zv your.server.ip 15001 von der Downstream-Maschine. Wenn das Zeitüberschreitung hat, handelt es sich um ein Netzwerk-/Firewall-Problem, bevor irgendeine MGCamd- oder OScam-Konfiguration relevant ist.