Meldung "classD1 ins32: failed"

[Reiner123]

Habe ich schon mit Sky Cinema HD getestet, das selbe. 4 Stunden, 12 min.
Hat das was mit dem icam byte im ecm zu tun?

 

[DarkStarXxX]

Was soll ICam damit zu tun haben?

 

[Reiner123]

sag´s du mir. Was ist es

 

[Hellacopters]

Das kommt doch schon seit Jahren bei mir auf dem Receiver und trotzdem wurde ich nicht gepairt oder sonstiges.

 

[Reiner123]

@
Hellacopters, und? Schön das du für andere antwortest, aber weil es seit Jahren so ist, ignorieren wir es? Und gepairt sind wir doch alle. :mask: Also wenn du nix beizutragen hast, gehe wieder in deine Kammer Sky schauen.

 

[Hellacopters]

Wenn du meinst- Aggressivität mochte ich noch nie

 

[parasonic]

Jetzt kommt mal wieder runter. Überlegt lieber was das sein könnte.

Also der Sender ist wohl auch egal, danke fürs Testen.
Ist hier auch so, völlig wurst ob Syfy, Cinema Premieren oder sonstwas, oder ob mehrere Anfragen parallel rein kommen oder nicht.
ICam Bytes im ECM sind (jottseidank) weiterhin 00 00.
Passiert übrigens auch mit V14! Gesehen auf Eurosport 1 HD, also nicht mal n Sky Sender! Mode 81.

Es geht für die gleiche Karte immer zur gleichen Zeit los. Aber für ne andere Karte zu einer anderen Zeit.
Dauert immer 11,4 Minuten (97-98 ECM) lang. (Bei V14 ca. 8 Minuten). Wenn Kartenzeit still steht (=ohne ECMs) passiert's gar nicht.
Ein EMM, Reset oder Powerloss der Karte zwischendurch macht auch keinen Unterschied, der ursprüngliche "Takt" wird danach beibehalten.
Habe z.B. meine Karte heute für 5 Minuten stromlos gemacht, und was soll ich sagen, die nächste Periode kam trotzdem wieder auf die Sekunde genau.

Hm, wenn das wirklich schon seit Jahren so abläuft kann es eigentlich soo wild nicht sein... stimmt schon.
Vermutlich war dieser 4-Std-Takt schon immer so, wurde bis jetzt nur nie so genau in der Öffentlichkeit untersucht.

[Brainstorm-Mode ON]
Hm, die "Startzeit" klebt an der Karte... hat jede Karte ihren eigenen "unique Zeitpunkt"? Also zu welchen Timestamps sie ihre "dollen 12 Minuten" bekommen SOLL?
Ein Zusammenhang zwischen Karten-ID und diesem "unique Zeitpunkt"? Möglich.
Evtl. sehen wir hier den Effekt eines Versuchs der Himmlischen, um die Karten in Cardservern im Netz besser identifizieren zu können...
vielleicht haben die das eingebaut um die erhöhte ECM Zeit während der 12 Min zu messen... und den"unique" Uhrzeiten zuordnen zu können...?
Krass, jetzt hab ich auch schon nen Aluhut auf
Naja, selbst wenn das so wäre, CacheEX und ähnliche Techniken sollten solche Analysen doch eigentlich ziemlich gut aushebeln, oder?
Mag denn echt keiner mal einen Season-Log (Auszug) aus ner halbwegs aktuellen Himmelskiste hierzu beisteuern? Da müsste zumindest der 5C Status ja auch drin vorkommen, oder nicht!?

Naja, vielleicht ist es ein schlichter "scheduled task" auf den Karten, getriggered im gleichen Intervall (jedes ECM trägt ja ne Uhrzeit mit sich rum)...? Selbst-Test? Call-Home trigger? ...?

Oder nur ein plumper regelmässiger Test seitens der Karte, prüft so alle 4 Stunden ob sie sich noch in ner Himmelbox befindet.
Wurde die Abfolge ins5C,5E, 78, 32 deshalb in Oscam "übernommen"., weil die Karten sonst nach 4 Std. rumgezickt haben...?
Wenn wenn wenn, warum dauert das dann 12 Minuten lang?
[Brainstorm-Mode OFF]

Seltsam alles. Wahrscheinlich liegt's am Osterhasen.

 

[barci]

Wie kommst du auf 12 Minuten? bei mir dauert es immer exakt 8 Minuten.

 

[Reiner123]

hast eine V14? da 8 min. V13 sind es 12 min.

 

[barci]

Nope. V13 genau 8min

 

[Reiner123]

ok, dann also auch da Unterschiede. Macht das ganze nicht einfacher.

 

[parasonic]

Ich konnte jetzt endlich mal ein längeres Seasonlog einer V13 und einer V14 in die Finger kriegen. Von nem Pace 866.
Interessant! Die Himmelskiste ignoriert den Status 11 0B 00 01 einfach!
Während Oscam den Status (5C) alle 12 Sekunden abfragt, macht der Pace das sogar 1-2 mal pro Sekunde.

Der Status normal (so kennt man's von OScam):

Spoiler

[20.48.20] > D1 5C 00 00 04 (5C) 00 00 00 00 [90 00]

[20.48.21] > D1 5C 00 00 04 (5C) 00 00 00 00 [90 00]

[20.48.21] > D1 5C 00 00 04 (5C) 00 00 00 00 [90 00]

[20.48.22] > D1 5C 00 00 04 (5C) 00 00 00 00 [90 00]

Wenn die Karte ECM bekommt und "ihre Zeit gekommen ist", dann sieht das irgendwann so aus:

Spoiler

[22.19.40] > D1 5C 00 00 04 (5C) 11 0B 00 01 [91 00]

[22.19.40] > D1 5C 00 00 04 (5C) 11 0B 00 01 [91 00]

[22.19.41] > D1 5C 00 00 04 (5C) 11 0B 00 01 [91 00]

[22.19.42] > D1 5C 00 00 04 (5C) 11 0B 00 01 [91 00]

Kennen wir schon. Aber die Himmelskiste interessiert dieser Status nicht die Bohne. Keine Reaktion weit und breit, kein 5E, kein 78, kein 32...
Also ob da ein 110B0001 kommt, oder ein 00000000, das ist dem Pace einfach nur schnurzegal, wird ignoriert.

Warum nun dieser Code in Oscam ist? Gute Frage. Das ist wohl seit Rev10376 da drin, das war anfang 2015 von "gf" und/oder "BigGyros" (hehe, haben die Griechen auch NDS Karten?).
Dieser Code macht was! Er sorgt dafür, dass die Karten (wenn in OScam) nach einiger Zeit wieder "normal" werden.
8 Minuten bzw. 12 Minuten... steht ja bereits im Raum. In Oscam ist es nach dieser Zeit wieder vorbei und alles wieder cool wie vorher, wie man's gewohnt ist.
In der Himmelskiste ist das aber anders. Da bleibt das, DAUERHAFT! 5C bleibt auf 110B0001, auch das SW bleibt permanent auf 91 00! Bzw. 91 20 mit "passender" Karte.
Es ist also in der Himmelskiste EBEN NICHT nach 8 oder 12 Minuten wieder vorbei, sondern (nach max. ein paar Stunden Betriebszeit) der Normalzustand!
Selbst Stunden später. Bis zum Neustart. Wer hätte das gedacht? Ich nicht.

Ob das nur in der Pace Box so ist? Vielleicht kann ja mal jemand *bitte* auch CI+ oder andere aktuelle Reci loggen, und für uns Neugierige nachschauen wie's da ist? *danke für die Mühe*

Wenn es sich überall so verhält wie oben beschrieben, dann wäre das wohl der endgültige Beweis:
- wer die Meldung jahrelang ignoriert hat (ich selbst auch, bis kürzlich) - der hatte schon immer recht :laughing:
- OScam gehört aufgeräumt, oder zumindest für die SkyDE Karten so angepasst, dass da keine Fehler auftauchen wo keine sind
- 5-10 ms mehr, wen juckt's

Also wohl ein gefaktes Osterei. Jetzt könnt Ihr "wir haben's ja schon immer gesagt" sagen :grinning:

 

[Reiner123]

Das klärt es aber nicht, warum immer zur selben zeit. Und warum aller 4 Stunden? Und was soll das überhaupt? Und warum bei einigen Karten 8 min, bei anderen 12 minuten?
Man kann es ignorieren, aber wird da nicht schlauer bei.

 

[parasonic]

Wüsste ich auch gern.
Vielleicht ist es ja in anderen Boxen oder CI+ anders und wird dort anders verarbeitet.
Diese Info kann ich aber nicht liefern. Vielleicht jemand anderes...?

Könntest auch mal die Hotline anrufen und dort nachfragen :laughing:

 

[parasonic]

Noch eine neue Erkenntnis dazu.

Offenbar ist die ins32 der Grund, warum dieser komische Zustand mehrere Minuten andauert (bei manchen 8, bei manchen 12...)
Wenn man aber in Oscam an der entsprechenden Stelle den ins32 Aufruf komplett weglässt, dann tritt dieser merkwürdige Status gar nicht mehr minutenlang auf.
Sondern nur noch ganz kurz, genau 1x den Statusloop... Der 11 0B 00 01 wird von der ins5E/ins78 Abfolge also "gecleared", aber nur wenn darauf KEIN ins32 gesendet wird.
Danach ist der Zustand direkt wieder normal, normale ECM Zeit, und die Fehlermeldung im Log ist logischerweise auch verschwunden.

Das erklärt natürlich immer noch nicht WAS dieser Kartenstatus genau anzeigt.
Aber auf die Weise bekommt man die erhöhten ECM Zeiten maximal für ein paar Sekunden, und keine Fehlermeldungen.
Mein Workaround-Patch, für alle die es interessiert:

Spoiler

--- ../oscam-svn/reader-videoguard2.c   2020-03-26 09:55:03.484385848 +0100
+++ reader-videoguard2.c        2020-04-20 11:38:34.312457143 +0200
@@ -556,13 +556,16 @@
                                                rdr_log(reader, "classD1 ins78: failed");
                                        }

-                                       uint8_t ins32[5] = { 0xD1, 0x32, 0x00, 0x00, 0x01 };
-                                       const uint8_t payload32[1] = { 0x25 };
-                                       l = do_cmd(reader, ins32, payload32, NULL, cta_res);
+                                        if (reader->caid != 0x9C4 && reader->caid != 0x98C && reader->caid != 0x98D)  // skip ins32 for SkyDE cards V13,V14,V15
+                                        {
+                                               uint8_t ins32[5] = { 0xD1, 0x32, 0x00, 0x00, 0x01 };
+                                               const uint8_t payload32[1] = { 0x25 };
+                                               l = do_cmd(reader, ins32, payload32, NULL, cta_res);

-                                       if(l < 0 || !status_ok(cta_res + l))
-                                       {
-                                               rdr_log(reader, "classD1 ins32: failed");
+                                               if(l < 0 || !status_ok(cta_res + l))
+                                               {
+                                                       rdr_log(reader, "classD1 ins32: failed");
+                                               }
                                        }
                                        break;
                                }

Works for me...