Dies ist eine mobil optimierte Seite, die schnell lädt. Wenn Sie die Seite ohne Optimierung laden möchten, dann klicken Sie auf diesen Text.

gelöst ORF EMM Verlängerungs-Problem bei 0D98 Crypto-Karten - (NEU: ohne needsglobalfirst)

Das Logfile bestätigt, dass das Problem im cryptoworks-reader liegt.
Ich mache mal eine Änderung und schicke ein neues Binary zum Testen. Das ist dann keine Indizien Version, sondern sollte schon mal richtig getestet werden.

The new version is coming soon

Wir sollten doch noch einen Test vorher durchführen, damit wir an der richtigen Stelle die Änderung vornehmen:

Code: 
Testet mal bitte, ob beim abgeschaltetem emmcache (emmcache 0,0,0,0) eine Verlängerung der Karte nur mit SHARED-EMMs möglich ist.
Dazu alle EMMs bis auf die Shared-EMMs blocken.

Das mal laufen lassen. Das EMMs geskipped werden ist dabei normal. Der debug_level kann auf 0 stehen bleiben.
Das sollten diejenigen Testen, bei denen das Verlängern nur mit Shared-EMMs nicht läuft.
 
Zuletzt bearbeitet:
Hi,
@pehedima
vielleicht hilft dir das PDF (Cryptoworks FAQ By SlayraCkEr) ein wenig weiter, wenn du es nicht schon hast.
94 04 scheint ja sowas wie - Anweisung von der Karte abgelehnt (FILE nicht gefunden, kein Datensatz gefunden)- zu bedeuten, wenn ich das richtig versteh.
 

Anhänge

Du musst angemeldet sein, um die Anhangsliste zu sehen.
Zuletzt bearbeitet:
Bei mir läuft der Test. Ich drücke öfter mal auf Refresh Entitlements. Heute haben sich die Entitlements noch nicht verändert. Auch scheint es so als werden heute laut Übersicht alle geskipped. Sicher bin ich mir nicht seit wann es so ist aber jetzt hatte ich 27 skipped und 0 written bevor sie mit dem Refresh wieder auf 0 gesetzt wurden.

Gesendet von meinem SM-G930F mit Tapatalk
 
Die Karte lehnt die EMMs ab.
Wie bereits gestern im Logfile ersichtlich antwortet die Karte mit: 94 04

Lt. Doku von oben:
Code: 
94 04 - It find by card - instruction rejected ( FILE, it find ) kordu
Heißt eigentlich, dass die Karte den Inhalt bereits kennt und die Anweisung skipped.
Kommentar im Source-Code an der Stelle: // emm already written before, entitlement / key is already up to date -> skipped

Bei Erfolg antwortet die Karte mit 90 00:
Code: 
90 00 - Errand executed, OK

Es könnte sein, dass die Karte dann irgendwann einfach komplett zu macht und alle Shared-EMMs rejected.
Lass das erstmal weiterlaufen.

Evtl. können das auch noch andere Testen und das Ergebnis hier posten. Danke.
Und immer schön die Shared-EMMs speichern.
 
Zuletzt bearbeitet:
Hi
hier mal ein Zitat von @theparasol aus dem SB
It looks like same as with viaccess class entitlement. If chid already up to date it throws a 9404.
Zum Vergrößern anklicken....

Beim SC-plugin und acamd wird es übrigens so ausgewertet
[core.smartcard] 0: File not found (status: 94 04)

hier mal noch ein interessantes Zitat aus diesem Thread:
ORF emm!s global, share und unique
 
Danke @janni1
Hört sich doch alles gut und logisch an.
Hoffen wir mal das unsere Karten hier das auch so sehen, denn dann müssten ja die entsprechenen Shared-EMMs auch korrekt geschrieben werden und die Verlängerung der Karte darüber problemlos erfolgen.


Auch interessant ist der nachfolgende Teil in dem von @janni1 oben verlinkten Beitrag:

Wie oben schon bemerkt, werden aber selbst durch die geschriebenen EMM-s (Antwort 9000) die CHIDs nicht weiter verlängert.

Im Prinzip lässt das den Schluss zu, dass die EMM-G eine entsprechende Systemzeit oder einen Zeitstempel aktualisieren.
Wenn dann der entsprechende EMM-S kommt, werden vermutlich die CHIDs relativ zu dem über den EMM-G gesetzten
Zeitstempel verlängert.

Als kleines Experiment:

- Karte vollständig aktualisiert - alle EMMs blocken und einen Tag warten
- am Folgetag nur die EMM-S freigeben ... es gibt EMM-S mit 9000 und welche mit 9404
- die Freischaltung wird nicht aktualisiert

Nächster Schritt:

- Alle EMMs blocken und nur die EMM-G freigeben
- einen halben Tag warten und 2000+ EMM-G auf die Karte schreiben
- danach alle EMM blocken und nur die EMM-S freigeben
- die EMM-S mit 9000 verlängern nun die Entitlements

Ich denke derselbe Mechanismus kann u.a. verhindern, dass man die Karte mittels Replay quasi mit alten EMM Daten versorgen kann

Bin mal auf die Testergebnisse hier gespannt, ob das so bestätigt wird.
 
Zuletzt bearbeitet:
Ich stehe auch gerne zu umfassenden Tests zur Verfügung.

Ich habe ja die folgende Konstellation:

- PI B+ mit Oscam (mit dvbapi Unterstützung) 11353 oder 11272 und CCcam Protokoll (cs378x auch eingerichtet)
- Karten: V14, ORF C841 (Irdeto), HD01, MTV
- als AU Client dienen wahlweise DM900, GigaBlue Quad und DVB Viewer per dvbapi über den PI

Wegen der besseren Überwachung der User bezüglich der zu sendenden EMM‘s haben die Client‘s für jede Karte am Pi einen separaten Reader. (Configs dann später)

Ansich rennt der Pi absolut stabil. Nur mit den EMM‘s für die verschiedenen Karten gibt es immer wieder sich veränderte Probleme, die ich nie endgültig lokalisieren könnte.

Wenn ich in die Tests mit einsteigen soll, besser in einem neuen Thread?
 
Hi,
@pehedima
das ist wirklich sehr interessant.
Ich denke aber auch, dass die EMM-G eine Voraussetzung irgendeiner Art mitbringen/Auslösen, die uU. das Schreiben der EMM-S bzw. das Verlängern der Entis erst ermöglicht.
 
Das sieht zumindest so aus.
Würde gerne genau wissen welche EMM-G evtl. als Vorbereitung für die Verlängerungs EMM-S zuständig sind. Evtl ist das ja auch nur ein Global-EMM.
Mit einer speziellen Update-Funktion für 0D98 Karten könnte man das dann von oscam automatisch erledigen lassen.
Mal sehen was da rauskommt.

@Smiley007
Denke das Problem tritt nur bei CAID 0D98 (cyptoworks) auf. Da deine Karte im Irdeto-Mode läuft, kannst du das Problem sicher so nicht nachstellen.
Lasse mich aber auch gerne eines bessern belehren.
 
Zuletzt bearbeitet:
Mach das bitte.
Denke deinen Fall sollten wir separat zu diesen Aktionen hier analysieren.
Bleibt dann übersichtlicher.
 

Genau so scheint es zu sein. Bis jetzt seit heute Früh wurden alle Shared geskipped (laut Übersicht, trotzdem steht immer ACTIVE bei au), nach Refresh haben sich auch die Entitlements nicht geändert. Alle Shared seit gestern vormittag sind geloggt, Speicherverbrauch gerade mal 274kB, kann ich gern weiterlaufen lassen. Wir werden die Lösung schon finden. Nachdem die Enties immer gute 8 Monate gelten kann man zur Not ja mal kurz Globals durchlassen.

Es wäre der Hammer wenn wir das Global-EMM (oder mehrere) finden das die Shared wieder durchlässt und das Verlängern wieder automatisieren könnten ohne alle Globals durchzulassen was die ECM-Zeiten teilweise erhöht.

Trotzdem wundert es micht dass manche behauptet haben es reichen die Shared. Entweder sind sie noch nicht draufgekommen (wie ich am Anfang) oder es funktioniert mit manchen Karten doch, oder es waren nicht alle 0D98.
Ob es nur beim Raspi so ist (Threadtitel) wissen wir auch noch nicht.
 
Zuletzt bearbeitet:
Meine Karte 0D98 sieht seit ich sie habe nur die shared Emms. Keine Probleme mit der Verlängerung.
Allerdings kein RPI.
 
Ich kann mir nicht vorstellen, dass der RPI hier das Problem sein soll.

@d2z
- Wie ist der emmcache eingestellt?
- Bei Verwendung von emmcache 0,0,0,0 werden bei dir dann noch Shared-EMMs geskipped?
- Welche oscam Version hast du auf welcher Kiste laufen?
 
Mein alter Server ist ein Igel 5/4 oder so, Oscam 11420.
emmcache = 1,1,2,0
Schrieb problemlos die Shared Emms.

Habe seit einer Woche ca. einen neuen Server, einen Dell Optiplex 740 mit Oscam 11424.
Gerade Mal nachgesehen, habe vor zwei Tagen neu gestartet, seit dem wurden die shared Emms nur geskipped.
Muss mal beobachten, ob sie dort auch geschrieben werden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

S
ORF Karte P auf IRDETO umstellen was beachten?
Antworten
4
Aufrufe
556
Derek Buegel
S
Dreambox 7080 als Streamingserver - ORF in OSCAM - Irdeto Mode problematisch
Antworten
5
Aufrufe
313
satdxler
S
gelöst HD01 Verlängerung über globales emm?
Antworten
9
Aufrufe
419
Roadman
A
Problem mit Oscam und ORF Karte, Dvbapi OK cccam geht nicht.
2
Antworten
25
Aufrufe
979
Kind regards
habe auch nach 5 Jahren die neue ORF Karte mit der Nummer: K2XXX XXXX XXXX 4 bekommen
2
Antworten
25
Aufrufe
4K
ohmza
O
Menü
Anmelden
Registrieren
Für die Nutzung dieser Website sind Cookies erforderlich. Du musst diese akzeptieren, um die Website weiter nutzen zu können. Erfahre mehr…