OScam WebIf: So überwachen Sie aktive Leser und Clients (2026 Anleitung)

Wenn Sie OScam laufen haben und das WebIf in einem Browser-Tab geöffnet ist, aber Sie immer noch nicht sagen können, ob Ihre Leser tatsächlich etwas tun, sind Sie nicht allein. Diese Anleitung zuoscam webif: so überwachen Sie aktive Leser und Clientsgeht jede Spalte auf der Statusseite durch, erklärt, was die Protokollcodes bedeuten, und welche Konfigurationsdatei Sie öffnen sollten, wenn etwas nicht funktioniert. Ich habe OScam auf allem von einem Raspberry Pi bis zu einem alten Vu+ Solo2 betrieben, und das WebIf sagt Ihnen fast alles, was Sie brauchen — Sie müssen nur wissen, wie man es liest.

Dies ist kein Einrichtungstutorial. Ich gehe davon aus, dass oscam.conf, oscam.server und oscam.user bereits existieren und der Daemon läuft. Das Ziel hier ist die Diagnose: Zuordnen, was auf dem Bildschirm angezeigt wird, zu einer bestimmten Zeile in einer Konfigurationsdatei, damit Sie es beheben können, anstatt zu raten.

Aktivieren Sie das OScam WebIf, bevor Sie etwas überwachen können

Ein großer Teil der Personen, die nach diesem Thema suchen, hat tatsächlich ein WebIf, das überhaupt nicht lädt. Bevor wir also mit dem Lesen der Spalten beginnen, stellen wir sicher, dass die Seite geöffnet wird. Hier ist ein minimales funktionierendes[webif]Block für oscam.conf:

[webif]

httprefreshsteuert, wie oft die Seite automatisch neu geladen wird, in Sekunden. Setzen Sie es auf 0, wenn Sie ein Protokoll oder eine Status Tabelle lesen und nicht möchten, dass die Seite unter Ihrem Cursor springt — ich mache das ständig, wenn ich versuche, einen Reconnect in Aktion zu fangen.

Wenn Sie ein+vor die Portnummer setzen, wiehttpport = +8888wechselt OScam zu HTTPS. Das erfordert eineoscam.pemDatei im selben Konfigurationsverzeichnis. Ohne sie wird der Daemon sich weigern zu binden und das WebIf wird einfach nicht angezeigt — kein Fehlerdialog, kein offensichtlicher Hinweis, nur eine Verbindung abgelehnt in Ihrem Browser.

Konfigurationspfade sind nicht universell, und das verwirrt mehr Leute, als es sollte. Auf Enigma2-Images finden Sie Dinge typischerweise unter/etc/tuxbox/config/oder/etc/tuxbox/config/oscam/. Auf einer generischen Linux-Box ist es normalerweise/usr/local/etc/. Einige OpenWrt-Bauten verstecken es in/var/etc/. Anstatt zu raten, überprüfen Sie das Init-Skript oder die systemd-Einheit für das-cFlag — das sagt Ihnen genau, welches Verzeichnis OScam tatsächlich liest. Ich habe gesehen, wie Leute oscam.conf zwanzig Minuten lang bearbeitet haben und sich fragten, warum sich nichts ändert, nur um herauszufinden, dass der laufende Prozess mit-c /etc/oscam2/gestart wurde.

Bestätigen Sie, dass Ihr Build tatsächlich WebIf-Unterstützung kompiliert hat:

oscam --build-info | grep -i webif

Wenn das leer zurückkommt, läuft der Daemon einwandfrei — es ist nur so, dass der Port nie lauscht, weil WEBIF zur Compile-Zeit nicht einbezogen wurde. Dies ist eine häufige Ursache für eine "leere Seite", die die Leute fälschlicherweise für ein Konfigurationsproblem halten. Die andere häufige Ursache ist, dass der Port bereits von einer zweiten OScam-Instanz (mehr dazu später) oder einem anderen Dienst verwendet wird.

Die Statusseite lesen: Was jede Spalte tatsächlich bedeutet

Das ist der Teil, den fast niemand richtig erklärt. Die meisten Berichte machen einen Screenshot der Statusseite und sagen "hier sind Ihre Leser", ohne Ihnen zu sagen, was CARDOK versus CONNECTED versus IDLE tatsächlich bedeutet. Lassen Sie uns also Spalte für Spalte durchgehen, denn das ist die echte Antwort auf oscam webif: wie man aktive Leser und Clients überwacht.

Client vs Reader vs Proxy-Reihen

Jede Reihe auf der Statusseite hat einen Typbuchstaben.c ist ein Client — ein Eintrag aus oscam.user, der sich verbindet, um ECMs anzufordern.p ist ein Proxy-Reader — eine Netzwerkverbindung zu einem anderen Cardsharing-Server (cccam, newcamd, camd35, cs378x, gbox).r ist ein lokaler Reader — eine physische Karte über PCSC oder einen seriellen Reader wie einen Smargo.m ist die Monitorreihe, die nur OScams eigenen Monitorport ist.

Eine Sache, die die Leute verwirrt: ein Peer, der auf beiden Seiten konfiguriert ist — du speist sie und sie speisen dich — erscheint zweimal. Einmal als Client-Reihe, einmal als Reader-Reihe. Wenn du das als zwei separate Personen zählst, wirst du deine aktiven Verbindungen überzählen.

Die Statusspalte

Dies ist das Feld, auf das die Leute am längsten starren. Hier ist, was jeder Zustand in der Praxis tatsächlich bedeutet:

• VERBUNDEN — der Socket ist geöffnet und authentifiziert, aber das allein sagt dir nicht, ob Daten fließen.
• ANMELDUNG — mitten im Handshake, sollte vorübergehend sein. Wenn es hier hängen bleibt, sind die Anmeldeinformationen oder die Protokollversion wahrscheinlich falsch.
• INAKTIV — verbunden, authentifiziert, aber gerade nicht aktiv, um ein ECM in diesem Moment zu bedienen. Völlig normal.
• AUS — nicht verbunden. Für einen Reader, überprüfe den Netzwerkpfad und die Anmeldeinformationen. Für einen lokalen Reader, überprüfe, ob die Karte tatsächlich eingesetzt ist.
• KARTE OK — spezifisch für lokale und Proxy-Reader: die Karte wurde erfolgreich gelesen und OScam hat ihr ATR und ihre Berechtigungen.
• GETRENNT — war verbunden, ist es jetzt nicht. In Kombination mit einer steigenden Wiederverbindungsanzahl deutet dies auf ein Netzwerk- oder Keepalive-Problem hin.

Ein Reader, der in KARTE OK sitzt und eine stetig steigende ECM-Anzahl hat, ist gesund — das ist das Bild, das du willst. Ein Reader, der in VERBUNDEN feststeckt, ohne jemals ECMs zu senden, ist erreichbar, wird aber nie tatsächlich vom Lastenausgleich ausgewählt, normalerweise wegen eines CAID- oder Identitätsfehlers oder weil ein anderer Reader schneller ist und immer das Rennen gewinnt. Ein Reader, der alle ein oder zwei Minuten zwischen VERBUNDEN und AUS wechselt, hat ein Netzwerk- oder Anmeldeproblem, kein Kartenproblem.

AU: die Spalte, die jeder falsch interpretiert

AU steht für Auto Update — ob diese Verbindung erlaubt ist, EMMs zu senden, um das Abonnement einer Karte aktuell zu halten.EIN bedeutet, dass EMMs erlaubt sind.AUS bedeutet, dass sie vollständig blockiert sind. Wenn du stattdessen einen CAID-Wert siehst, ist AU auf genau diesen CAID beschränkt — nützlich, wenn ein Client mehrere Karten dahinter hat, du aber nur automatische Updates für eine möchtest. Dies wird mitau = 1 in oscam.user gesetzt, oderau = um Updates an einen bestimmten Reader zu binden.

ECM-Zeit, Letzter Kanal und der LB-Indikator

Die ECM-Zeit wird in Millisekunden gemessen und ist die nützlichste Leistungszahl auf der Seite. Unter etwa 300 ms fühlt sich das Zappen sofort an. Zwischen 300 und 800 ms ist es nutzbar, aber du wirst einen Moment bemerken, bevor das Bild klar wird. Über 1000 ms konstant wirst du sichtbares Einfrieren beim Kanalwechsel sehen, und wenn es über deineecmtimeout Einstellung (standardmäßig häufig 3000 ms) steigt, verwirft OScam dieses ECM vollständig.

Der Vergleich der ECM-Zeit zwischen Lesegeräten, die denselben CAID tragen, ist genau das, wie Sie die Priorität der Leser für den Lastenausgleich entscheiden — das schnellste sollte bevorzugt werden, und die Statistik-Engine von OScam verfolgt dies automatisch, wenn lb_mode aktiviert ist (mehr dazu in einer Minute).

Letzter Kanal wird angezeigt alsCAID:provid:sid in Hexadezimal. Ohne eineoscam.srvid Datei in Ihrem Konfigurationsverzeichnis werden Sie nur das sehen — rohe Zahlen, keine Kanalnamen. Legen Sie eine ordnungsgemäße oscam.srvid (oder oscam.srvid2) Datei dort ab, und die WebIf löst diese IDs in tatsächliche Kanalnamen auf. Ich habe gesehen, dass Leute annehmen, das WebIf sei defekt, nur weil diese Datei nie hinzugefügt wurde.

Leerlauf-Timer und warum ein Client mit null ECMs verbunden sein kann

Die Leerlauf-Spalte zählt die Sekunden seit der letzten Anfrage von dieser Verbindung. Ein Client kann stundenlang auf VERBUNDEN bleiben, während der Leerlauf-Timer steigt und null ECMs verarbeitet werden — das bedeutet einfach, dass sie den Kanal nicht gewechselt haben oder gerade nichts entschlüsselt über Ihre Box ansehen. Das ist kein Fehler, es ist einfach ruhig.

Cache-Treffer und Cache-ex-Leser

Das ist der Teil, den fast jeder andere Leitfaden überspringt, und es verursacht echte Verwirrung. Wenn Sie Cache-Austausch (cacheex) betreiben, gibt es einige Leser, die ausschließlich dazu dienen, zwischengespeicherte ECM-Antworten zwischen Servern zu teilen — sie verarbeiten möglicherweise legitim nie ein einziges "echtes" ECM gegen eine Karte. Ihre Zähler stehen für immer auf null, und das ist so gewollt, kein defekter Leser. Verfolgen Sie kein Phantomproblem bei einem nur cacheex-Leser, der null ECMs anzeigt; überprüfen Sie stattdessen die Einstellung des cacheex-Modus in oscam.server, anstatt anzunehmen, dass er tot ist.

Live-Protokollüberwachung: Den Lärm filtern, um das fehlerhafte ECM zu finden

Die Statusseite zeigt Ihnen den aktuellen Zustand der Dinge. Das Protokoll sagt Ihnen, warum. Hier ist eine echte annotierte ECM-Zeile, formatmäßig (Werte sind illustrative Platzhalter, nicht an ein echtes Kartensystem gebunden):

2026/07/14 21:14:02 c (client) benutzername ECM 0100:000000 sid 4A21 pid 0834 von reader1 (0 ms) rc=1 (gefunden)

Das aufgeschlüsselt: caid ist0100, provid ist000000, sid ist die Dienst-ID4A21, pid ist die PID des Elementarstroms0834, der Leser, der geantwortet hat, warreader1, undrc=1 (gefunden) ist der Rückgabewert — was bedeutet, dass das ECM erfolgreich entschlüsselt wurde. Die Zahl in Klammern vor rc ist die Antwortzeit in Millisekunden, die dieselbe Zahl ist, die in der ECM-Zeit-Spalte der Statusseite für diesen Leser angezeigt wird.

Rückgabecodes, die Sie tatsächlich sehen werden

• gefunden — erfolgreich entschlüsselt, alles gut.
• nicht gefunden — jeder Leser, den Sie ausprobiert haben, trägt diese CAID/provid-Kombination nicht. Überprüfen Sie die Berechtigungsseite, um dies zu bestätigen.
• cache1 / cache2 / cache3 — die Antwort kam aus dem Cache, nicht von einer Karte. Das ist normal und schnell — das ist auch der Grund, warum ein Leser auf der Statusseite "inaktiv" aussehen kann, während der Kanal gut entschlüsselt wird.
• Zeitüberschreitung — der Leser hat zu lange gebraucht, um zu antworten. Erhöhen Sie nicht einfach ecmtimeout, um dies zu kaschieren — überprüfen Sie die tatsächliche Netzwerkverzögerung zu diesem Leser und überlegen Sie, ob ecmtimeout (standardmäßig oft 3000 ms) realistisch für diese Verbindung ist.
• abgelehnt — fast immer eine Gruppen-, CAID- oder Identitätsdiskrepanz zwischen oscam.user und oscam.server. Die Gruppe des Clients in oscam.user muss sich mit der Gruppe des Lesers überschneiden, oder die Anfrage wird nie weitergeleitet.

Debug-Ebenen — verwenden Sie die Bitmaske, nicht 255

Die Debug-Ebenen von OScam sind eine Bitmaske, und das Setzen von Debug auf 255 gibt alles auf einmal aus. Auf einem stark frequentierten Server ist das eine Flut, und auf einer Box mit wenig RAM, die auf Flash-Speicher schreibt, kann es tatsächlich die Festplatte füllen oder einen Watchdog-Neustart auslösen. Ich habe auf diese Weise eine Sitzung auf einer alten Set-Top-Box mit einem 512 MB Flash-Chip blockiert — tun Sie das nicht.

Verwenden Sie die spezifischen Bits, die Sie benötigen:2 für Leser/ATR-Aktivität,4 für Kundenverbindungen,16 für EMM-Verarbeitung,64 für ECM-Flow. Wenn Sie einen Kanal verfolgen, der nicht entschlüsselt,debug = 64 allein ist normalerweise genug. Setzen Sielogfile auf einen Ort in einem echten Dateisystem, nicht Flash, setzen Siemaxlogsize um es zu begrenzen, und setzen Sie debug sofort auf 0, sobald Sie Ihre Antwort gefunden haben.

Die Live-Log-Seite im WebIf ermöglicht es Ihnen, nach einem einzelnen Kunden- oder Lesernamen zu filtern, anstatt den gesamten Stream zu lesen, was viel schneller ist, als eine riesige oscam.log-Datei zu durchsuchen, wenn Sie bereits wissen, welche Verbindung sich nicht richtig verhält.

Leser-Gesundheit: Berechtigungen, Karten und die Lastenausgleichsansicht

Der schnellste Weg zu beantworten "Ist meine Karte tatsächlich aktiv?" ist die Berechtigungsansicht auf der Leserseite. Sie listet jede CAID, Anbieter-ID, Klasse und das Ablaufdatum auf, das die Karte meldet. Für einen lokalen Leser — PCSC, ein interner Slot, ein Smargo — kommt dies direkt von der Karte selbst. Für einen Netzwerkleser (eine cccam- oder newcamd-Proxy-Verbindung) sehen Sie, was der upstream-Server bewirbt, was möglicherweise nicht mit einer echten physischen Karte auf deren Seite übereinstimmt.

Ich habe gesehen, dass ein Leser wochenlang auf CARDOK saß, die ECM-Zeit perfekt gesund aussah, und die tatsächliche Berechtigung zwei Tage zuvor abgelaufen war — die Karte antwortete einfach weiterhin auf ECMs für CAIDs, für die sie keine Rechte mehr hatte, und gab nicht gefunden zurück, anstatt einen Fehler, den Sie im Status bemerken würden. Der einzige Ort, an dem das angezeigt wird, ist die Ablaufspalte der Berechtigungsseite.

Die Lastenausgleichsstatistikseite ist Geschichte, kein Live-View

Das ist der Teil, den die meisten konkurrierenden Anleitungen völlig überspringen, und es ist der Grund, warum ein perfekt gesund aussehender Leser bei null ECMs sitzen kann. Die Lastenausgleichsseite zeigt akkumulierte Leistungsstatistiken pro Leser — durchschnittliche ECM-Zeit, Fehlerrate — und OScam verwendet diese Historie, um zu entscheiden, welcher Leser zuerst für eine gegebene CAID/Anbieter-Kombination ausprobiert wird. Ein Leser, der jetzt in Ordnung ist, aber eine schlechte Historie von vor einer Stunde hat, wird weiterhin das Rennen gegen einen Leser mit einer besseren Erfolgsbilanz verlieren, bis sich genügend Daten ändern.

Relevante Schlüssel in oscam.conf:

• lb_mode = 1 — aktiviert Lastenausgleich und priorisiert den schnellsten Leser.
• lb_save — speichert Statistiken auf der Festplatte, damit sie einen Neustart überstehen.
• lb_nbest_readers — wie viele Top-Leser pro Anfrage ausprobiert werden sollen.
• lb_retrylimit — Millisekunden, bevor OScam beim ersten Leser aufgibt und den nächsten versucht. Dies interagiert direkt mit der ECM-Zeit, die Sie im Status sehen: Wenn lb_retrylimit niedriger ist als die typische Antwortzeit eines Lesers, wird dieser Leser fast nie gewinnen, selbst wenn er schließlich gut geantwortet hätte.
• lb_stat_cleanup — Stunden, bevor alte Statistiken verfallen.

Wenn Sie einen langsamen Leser reparieren — sagen wir, Sie haben ihn auf einen besseren Netzwerkpfad verschoben — wiegen seine alten Statistiken immer noch gegen ihn. Setzen Sie die Lastenausgleichsstatistiken über das WebIf nach der Reparatur zurück, andernfalls vermeidet OScam weiterhin einen Leser, der nicht mehr tatsächlich langsam ist. Und wennlb_save Statistiken von einer vorherigen Hardwarekonfiguration übernommen hat, können Sie am Ende haben, dass OScam weiterhin ECMs auf einen Leser lenkt, der nicht mehr existiert — das zeigt sich als ECMs, die leise fehlschlagen, ohne offensichtliche Ursache, bis Sie die Lastenausgleichsseite überprüfen und einen Phantom-Eintrag sehen.

Automatisierung der Überwachung: HTTP-API, JSON-Status und externe Tools

Fast niemand behandelt diesen Teil, aber OScam stellt über das WebIf eine maschinenlesbare API zur Verfügung, sodass Sie kein HTML scrapen müssen, um den Status des Lesers zu überprüfen. Rufen Sie es mit curl auf:

curl --user admin:your_password_here "http://192.168.1.50:8888/oscamapi.json?part=status"

Die Antwort ist ein JSON-Objekt mit einem Kundenarray — jeder Eintrag enthält Typ, Name, Protokoll, Verbindungsstatus und letzten Kanal, strukturell die gleichen Informationen wie die Statusseite, aber von einem Skript analysierbar. Es gibt auchpart=readers für leserspezifische Daten. Dies ist wirklich nützlich, wenn Sie den Status des Lesers alle fünf Minuten von cron abfragen und eine Warnung auslösen möchten, wenn ein Leser ausfällt.

Bevor Sie dies in irgendetwas einbinden, sichern Sie es: Erstellen Sie ein separates, eingeschränktes WebIf-Konto, anstatt Ihr Admin-Login wiederzuverwenden, und beschränken Siehttpallowed nur auf die IP der Maschine, die das Polling durchführt. Das WebIf kann den Daemon neu starten und Konfigurationsdateien neu schreiben — es ist nichts, was man breit zugänglich machen sollte, nur weil man ein Dashboard möchte.

Für die Prozessüberwachung — läuft OScam überhaupt, nicht nur "ist der Leser verbunden" — verlassen Sie sich auf systemd (systemctl status oscam) oder das Neustartverhalten Ihres init.d-Skripts bei Abstürzen, da das WebIf Ihnen offensichtlich nichts sagen kann, wenn der gesamte Prozess ausgefallen ist.

Häufige Überwachungs-Symptome und was sie tatsächlich bedeuten

Hier ist eine Tabelle mit Symptomen und Lösungen, denn das ist normalerweise der Grund, warum die Leute hierher gekommen sind, als sie nach oscam webif suchten: wie man aktive Leser und Clients überwacht.

Ein paar Randfälle, die es wert sind, direkt angesprochen zu werden. Wenn Sie zwei OScam-Instanzen gleichzeitig ausführen — eine, die vom Image der Box gestartet wurde, eine, die Sie manuell gestartet haben — hat jede ihr eigenes WebIf auf einem anderen Port, und es ist einfach, das falsche vollständig zu überwachen, während man sich fragt, warum Ihre Änderungen nie zu wirken scheinen. Überprüfen Sieps aux | grep oscam wenn die Statusseite zeitlich festzustecken scheint.

Überprüfen Sie auch Ihre Systemuhr. Wenn NTP seit dem letzten Neustart nicht synchronisiert hat, sehen Sie falsche Anmeldezeiten, negative Leerlauf-Timer und — wenn Sie HTTPS auf dem WebIf ausführen — Zertifikatsvalidierungsfehler, da das Gültigkeitsfenster von oscam.pem davon abhängt, dass die Uhr ungefähr korrekt ist.