ECM Länge 98 versus 9B

[Alfredo01]

AW: ECM Länge 98 versus 9B

Nein - so ist das nicht. Wenn ich nur 97 und 98 in meiner Whitelist stehen habe, dann würden alle anderen Längen als:

• 2015/07/09 22:52:44 B0A20 c user_01 (098C&000000/00CA/001C/98:02E11E6890A112BA2E7F23F0C3CFD447:0F06000000): rejected group (0 ms) - Disney XD (no matching reader)

erkannt werden und damit einhergehend würde es logischerweise zu Bildstörungen kommen. Zusätzlich würden zu lange ecms die nicht in der whitelist stehen unter ECMs ignored hochgezählt. Beides ist bei mir bei keinem Sender der Fall.

In obigem Beispiel habe ich mal die 98 aus der Whitelist entfernt.

Ich kann nur sagen, dass ich noch NIE auf den genannten - oder auch allen anderen außer eben Eurosport HD - etwas Anderes als Länge 98 erhalten habe und auch keine Bildstörungen und Hänger kenne.

Ich bin davon überzeugt das es sich um ein dvbapi Problem bei der verwendeten Version handelt die nicht rund auf dem Receiver läuft. Einen Test zur Überprüfung habe ich ja schon aufgezeigt: Ein oscamlog anlegen mit loglevel 2 - da wird jeder einzelne ecm angezeigt und wenn einer länger sein sollte, muss auch die Längenangabe im ecm verändert sein. Als weiteren Anhaltspunkt - ich verwende NUR ältere Versionen, die neueren sind einfach eher Alfa als Beta und gerade die dvbapi ist reichlich ausufernd in neueren Versionen. Einen Versuch mit z.B. 9848 bis 9957 wäre unter Umständen hilfreich.

 

[geohei]

AW: ECM Länge 98 versus 9B

Ich stelle mir zuerst einmal die Frage warum der Client überhaupt 9B schickt. Ich habe im Moment ...

# tail -f /var/log/oscam.log | grep "098C&000000/..../..../9B"

... auf einem Client laufen und hoffe jetzt einmal auf Cinema auf Treffer. loglevel=0 reicht. OSCam Version ist übrigens 10076 (Server und Client).

Wie alt sind deine Logs denn? Kannst du den hier einmal auf dem Server und Client drüber laufen lassen.

# cat oscam.log* | grep "098C&000000/..../..../9B"

Bin gespannt ...

Ich habe das dumpfe Gefühl Sky hat beide ECM Längen gleichzeitig mit 2 verschiedenen ECM_PIDs (beide SID 098C) geschickt.

 

[DarkStarXxX]

AW: ECM Länge 98 versus 9B

Loglevel 0 reicht nicht.
Es muss mindestens 2 sein.

Dein Gefühl täuscht dich es gibt nur eine ECM Pid für die 098C.

 

[Alfredo01]

AW: ECM Länge 98 versus 9B

Ich bin sicher nicht gemeint - ich logge ja nicht unnötigerweise ein oscam.log da bei mir alles problemlos funktioniert (;-)

Der Loglevel 0 hilft natürlich in sofern nicht viel weiter, weil so keine Aussage getroffen werden kann, ob ein 9B ECM nun als 9B gesendet wurde, oder von oscam fälschlicherweise "generiert" wurde. Die "effektive" ecm Länge befindet sich ja an Position 3 im ECM nach 80 70 LE bzw. 81 70 LE. Nur wenn man sich den ECM als Hexdump ansieht, könnte man feststellen ob nun Sky ab und an mal einen längeren ECM verschickt oder der längere 9B eine Fehlleistung von oscam ist.

Ich persönlich tendiere eindeutig zu letzterem denn meine "Whitelist" auf dem Server besteht nur aus den Einträgen 97,98 und es kommt bei meinen beiden Receivern zu keinen Aussetzern wegen abweichender ECM Längen. Falls es zu solchen längeren ECMs kommen sollte, würden die automatisch im Webif des Readers unter ECM,s ignored gezählt.

 

[DarkStarXxX]

AW: ECM Länge 98 versus 9B

Ich hatte das bei meiner G09 auch am Server bemerkt das Peers da manchmal so komische Längen schicken.
Mit meiner Dream hatte ich sowas nie, jetzt mit der VU+ hatte ich das ganze bisher auch einmal bemerkt.

Bin mir da nicht sicher das sowas vom Provider kommt.

 

[geohei]

AW: ECM Länge 98 versus 9B

Ha ... ich habe jetzt zwei 9Bs auf dem Client erwischt! 9Bs werden geschickt!
Warum loggt ihr nicht einmal selber ... und dann reden wir weiter.
Ihr werded sehen dass die 9Bs tatsächlich existieren.

2015/07/10 20:16:02   8C6208 c dvbapi (098C&000000/012D/000A/9B:2BBBE33B813F031B4B08E5CAEF4B169E): found (78 ms) by office (P/2/2/2)
2015/07/10 21:54:48   8C6208 c dvbapi (098C&000000/012D/000A/9B:E4946740D5112CDD940C90581B8624FC): found (88 ms) by office (P/2/2/2)

Das sollte ja jetzt eindeutig sein ... !!!

Loglevel 0 reicht nicht.
Es muss mindestens 2 sein.

Dein Gefühl täuscht dich es gibt nur eine ECM Pid für die 098C.

Warum reicht loglevel=0 nicht?
Was willst du dass ich in loglevel=2 checke?
Wenn nur eine ECM_PID, dann schickt Sky von Zeit zu Zeit ECMs mit anderer Länge!

Ich bin sicher nicht gemeint - ich logge ja nicht unnötigerweise ein oscam.log da bei mir alles problemlos funktioniert (;-)
...

Diese 9Bs kommen ja nicht massenweise. Sie sind vereinzelt ... etwa jede Stunde einer. Also wenn due nicht Aufnahmen tätigst und diese dann durch Project.X (SD) jagst, wird du diese Freezer u,U, visuel überhaupt nicht detektieren können.

Ich hatte das bei meiner G09 auch am Server bemerkt das Peers da manchmal so komische Längen schicken.
Mit meiner Dream hatte ich sowas nie, jetzt mit der VU+ hatte ich das ganze bisher auch einmal bemerkt.

Bin mir da nicht sicher das sowas vom Provider kommt.

Ich sehe beim besten Willen nicht was (und wieso) OSCam da eigenständig etwas an der ECM Länge ändern soll/kann. Ausserdem ... wenn dem so wäre ... wieso macht die eine V14 die 9Bs hell und die andere nicht? Ausserdem sind die 9Bs ja auch im ecmwhitelist WIKI für die V14 vorgesehen!

 

[DarkStarXxX]

AW: ECM Länge 98 versus 9B

Das sagt doch gar nichts aus.
Loglevel 0 bring Garnichts.....

 

[Alfredo01]

AW: ECM Länge 98 versus 9B

wird du diese Freezer u,U, visuel überhaupt nicht detektieren können.

Das ist doch Unsinn... Wenn ich NUR die ECM Längen 97 und 98 erlaube und es käme auch nur ein einziger 9B, dann würde mindestens ein CW ausbleiben und eine Bildstörung in Länge von max. 7 Sekunden wäre die sichere Folge. Dazu benötigt man keine Aufnahme und auch ProjectX. Außerdem würde das auch unter Readers ecm´s ignored geloggt werden.

Es ist ja auch nicht so, dass der ECM Stream nur alle 7 Sekunden ein ECM sendet - der Stream sendet ununterbrochen ECMs, sonst wäre beim Umschalten auf einen anderen Kanal jedes Mal eine Zwangspause von maximal 7 Sekunden einzulegen.

Ich bleibe dabei - diese "eingestreuten" längeren ECM´s sind eine Fehlleistung vermutlich der dvbapi die die ECM´s aus dem ECM Stream fischt. Bis vor Kurzem lieferte oscam beim EMM auch haufenweise Müll und reagierte auf alle möglichen EMMs die gar nicht an die eigene NDS Karte gerichtet waren. Das Problem zog sich schon mindestens 2000 Versionen durch oscam und man hatte da sogar mal dran "gebastelt" - nach einer Minute fehlerhafter EMMs wurde einfach die PID gekillt. Warum sollte dann die ECM Verarbeitung in jedem Falle fehlerfrei sein?

Am Einfachsten wäre es doch für dich - logge mal die genannte eine Stunde mit logleven 2 und schau dir die Hexdumps der ECM´s an... Ich bin der festen Überzeugung, dass es ganz normale 98iger ECMs sind mit einer 80 70 95 / 81 70 95 zu Beginn und einfach ein paar Bytes zu viel am Ende.

 

[geohei]

AW: ECM Länge 98 versus 9B

@Alfredo01
Warum lässt du nicht einfach einmal meine grep Zeile über dein Log des Clients und des Servers laufen wie ich vorgeschlagen habe?
(cat oscam.log* | grep "098C&000000/..../..../9B")
Wie viele Stunden/Tage enthällt das Log in etwa?

2015/07/11 20:55:02  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:9AFEB46132DFD1D04CC03188FE2E1301): found (67 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:09  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:9B1D66D30724168271A8A36E42ACAE3C): found (66 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:16  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:B13F12A80741B2FBA91B3577B4FA24BA): found (66 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:23  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:078D3DBE7A9CCCD64BDD6F53C8932D1A): found (65 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:30  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:49BC7B4C4F434E5C69C226E689AC763D): found (67 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:37  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:65E0FA871490E0B94236464DEC4EA714): found (66 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:44  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:45E5C30F08C49E13D13D3869F8C8EB12): found (67 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:51  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/9B:1CC82736E68A2EBDD59FB7B827E9F93D): found (70 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:58  904F4A8 c      (ecm) dvbapi (098C&000000/100E/007C/98:FE9CF0B519BF39FFA366541D7DC77340): found (67 ms) by office (L/1/2/2) - FOX HD

Bei 20:55:51 kommt ein 9B. Dieser wird vom Server beantwortet. Aber nur von der einen Karte, nicht von der anderen (siehe erstes Posting dieses Treads).

Die nähere Untersuchung (loglevel=2) zeigt:

2015/07/11 20:55:51  9051E40 c      (ecm) oscam-three (098C&000000/100E/007C/9B:1CC82736E68A2EBDD59FB7B827E9F93D): cache2 (60 ms) by office (L/1/2/2) - FOX HD
2015/07/11 20:55:51  9051E40 c      (ecm) cw:
2015/07/11 20:55:51  9051E40 c      (ecm)   15 A9 30 EE 26 05 E7 12 00 00 00 00 00 00 00 00
2015/07/11 20:55:51  903EC90 r   (reader) office [videoguard2] ecm hash: 1CC82736E68A2EBDD59FB7B827E9F93D real time: 69 ms
2015/07/11 20:55:52  904F4A8 c      (ecm) get cw for ecm:
2015/07/11 20:55:52  904F4A8 c      (ecm)   81 70 95 00 00 01 1D 8A 0B 96 F5 02 5B AA 55 05

Was soll das denn jetzt? 98 sollte 95 ergeben und 9B sollte 98 sein. Warum steht dann da 95. Wie kann sich oscam "verzählen"?

Hier stimmt definitiv etwas nicht!

Bleibt trotz allem die Frage warum die eine Karte 9B annimmt und die andere nicht!

Übrigens ... ich habe soeben festgestellt dass das WIKI folgende Einstellungen für die V14 angibt:

ecmwhitelist                  = 098c@000000:52,57,64,6a,7f,91,96,97,98,9b,9c,a1
ecmheaderwhitelist            = 81709800000120,80709800000120,8170950000011d,8070950000011d,8070940000011c,8170940000011c,8170540000011d,8070540000011d

ecmheaderwhitelist deckt aber nur die ECM Längen 57,97,98,9b ab. Was ist mit 52,64,6a,7f,91,96,9c,a1? Somit dürften 52,64,6a,7f,91,96,9c,a1 doch eigentlich überhaupt nicht hell machen!

... later ...

Ich habe soeben festgestellt, daß die zweite Karte jetzt 9B auf einmal auch annimmt. Ich habe nichts (!) an der Konfig geändert! Das kann doch fast nur ein Bug sein!

... later ...

Das Problem scheint schon länger zu bestehen ...
https://www.digital-eliteboard.com/282959-v14-ecm-whitelist.html

KEINE LINKS zu Fremd Foren

 

[DarkStarXxX]

AW: ECM Länge 98 versus 9B

Log Level 2 sieht aber so aus:

2015/07/12 08:16:35 30872A6B c (ecm) Hidden (09C7@000000/0027/C35F/5E:F09079A2DC3558D3D297C070F217B28A): found (81 ms) by Secret (L/1/9/9) - Channel
2015/07/12 08:16:35 30872A6B c (ecm) cw:
2015/07/12 08:16:35 30872A6B c (ecm) CE 9B BA 23 5A D7 82 B3 F6 2B 06 27 EB 47 2D 5F
2015/07/12 08:16:36 30872A6B c (ecm) get cw for ecm:
2015/07/12 08:16:36 30872A6B c (ecm) 81 70 5B 00 00 01 0E 8A 0C 32 0D 00 17 AA 55 05
2015/07/12 08:16:36 30872A6B c (ecm) 20 01 00 00 20 48 7D 13 1C B6 26 D4 C8 9D 33 9C
2015/07/12 08:16:36 30872A6B c (ecm) 9B 00 00 33 F1 59 64 8F CD 3F 0B 90 31 C0 01 18
2015/07/12 08:16:36 30872A6B c (ecm) 7E 98 3B 8B F8 EB D7 55 DF B9 D7 3A 18 6C 3B 17
2015/07/12 08:16:36 30872A6B c (ecm) D6 5B 32 15 33 37 34 90 40 79 2F 2E 2F C8 75 A0
2015/07/12 08:16:36 30872A6B c (ecm) C2 60 E9 A2 DA CA 92 4D 0E 15 FA 56 19 9D

Oh da kam noch ne abgeschnittene Zeile und die besagt keine das was wir sagen.
Die Länge kommt nicht vom Provider sondern der Client schickt sie falsch.
Wenn es OSCam sein sollte das Problem scheint gefixt zu sein, ich hatt es jedenfalls schon 6 Wochen nicht mehr.

Und zur Whitelist sei noch gesagt: Dir ist schon klar das dort wirklich "jeder" User einträge machen kann? Ich könnte dort auch 101 eintragen und trotzdem muss das noch lange nicht so vom Provider kommen.

Vergleich einfach ein 98 & 9B ECM und du wirst sehen dass das 9B hinten einfach etwas länger ist.

 

[Alfredo01]

AW: ECM Länge 98 versus 9B

Dann ist der Fall doch klar...

Das was im hexdump des ecm steht, ist das, was der Sender auch sendet. 81 70 95 .... die 0x95 ist der Zeiger auf den Beginn des "nächsten" ECM. Wobei "nächster" nicht den nächsten sich wechselnden ECM meint, sondern den ECM der im Stream folgt und der ist für jeweils 7 Sekunden identisch damit man beim Zappen zu jedem Zeitpunkt sofort ein ECM mit dem aktuellen CW hat.

Nachdem z.B. von nahezu Anbeginn an bei oscam NDS das EMM Handling definitiv falsch implementiert war und erst eher zufälligerweise vor ein paar Revisionen geändert wurde, ist es durchaus im Bereich des Möglichen, dass auch ein Fehler im Bereich ECM DVBAPI in oscam schlummert. Darüber hinaus liegen viele Probleme auch völlig außerhalb des Einflussbereiches von oscam - zu nennen wäre da die teilweise grottenschlechte Implementierung der dvbapi bei einzelnen Geräteherstellern.

Bleibt natürlich die Frage zu klären, warum sich oscam nicht auf die Längenangabe im ECM - in diesem Falle 82 70 0x95 - verlässt und die ECM Länge auf dieser Basis berechnet. Das wäre eine Frage an die Entwickler...

In Sachen Wiki... Da steht natürlich viel drin was von Usern zusammengetragen wurde. Also auch solche Fälle wie Deiner, ohne das der Ursache auf den Grund gegangen wurde. Aus einem - Meiner Meinung nach - Fehlverhalten wurde dann eben einfach die "Tatsache" das Sky ab und an mal einen 0x9B in seinem Stream einstreut (;-)

 

[DarkStarXxX]

AW: ECM Länge 98 versus 9B

Zum Updaten bringt man solche "Verursacher" Clienten eh nur wenn man strenge Whitelisten benutzt.
Wenn sie Standbilder haben werden sie schon auf die neueste OSCam wechseln.

Im Prinzip haben wir hier in DE noch glück das Sky nicht gleich den Umstand dazu nutzt das solche ungültigen ECM's den Kill Switch der Karte auslösen.

 

[Alfredo01]

AW: ECM Länge 98 versus 9B

Noch eine letzte Nachfrage..

(L/1/2/2) bedeutet was? Loadbalancer? Sind mehrere Karten vorhanden?

Vielleicht mal ausschalten um den Fehler einzukreisen...

Ich vermute da also, dass wohl zwei Karten einem größeren "Publikum" zugänglich gemacht werden sollen und man somit keinen Einfluss auf die "Klienten" hat. Damit ist der Fall für mich ohnehin erledigt...

 

[geohei]

AW: ECM Länge 98 versus 9B

...
Vergleich einfach ein 98 & 9B ECM und du wirst sehen dass das 9B hinten einfach etwas länger ist.

Leider nein. 95 steht im hexdump, 98 ist es (soweit alles ok), und 9B in der dvbapi Zeile (was natürlich nicht stimmt). Das ECM ist also nicht 3 Bytes zu lang, aber die Längenangabe ich der dvbapi Zeile ist falsch!

2015/07/19 03:12:49  9452810 c      (ecm) dvbapi (098C&000000/11F9/0086/9B:A26C4021CC38F2BBF2105C331DF3C77E): cache1 (1 ms) by office - Sky Cinema+1 HD
2015/07/19 03:12:49  9452810 c      (ecm) cw:
2015/07/19 03:12:49  9452810 c      (ecm)   00 00 00 00 00 00 00 00 3A A3 2C 09 91 5A F7 E2
2015/07/19 03:12:50  94514C0 c      (ecm) get cw for ecm:
2015/07/19 03:12:50  94514C0 c      (ecm)   81 70 95 00 00 01 1D 8A 13 09 8B 0B C0 AA 55 05
2015/07/19 03:12:50  94514C0 c      (ecm)   20 01 00 00 80 40 91 A3 37 53 FD 3A E4 98 40 03
2015/07/19 03:12:50  94514C0 c      (ecm)   02 05 02 BC 73 7D 0B 0C FE F0 DD D3 33 C3 5D AD
2015/07/19 03:12:50  94514C0 c      (ecm)   00 00 90 64 C1 01 BA 55 C7 BD A4 F1 0A 2F D7 57
2015/07/19 03:12:50  94514C0 c      (ecm)   A6 63 2A DA 4E 56 2E D9 0B 2F A9 B9 F4 13 A8 72
2015/07/19 03:12:50  94514C0 c      (ecm)   57 33 DC 3C B5 17 43 A7 98 0B AB 89 24 AE 14 6B
2015/07/19 03:12:50  94514C0 c      (ecm)   96 A0 65 26 76 4F 6B C4 58 10 0B 06 2F F3 F4 F8
2015/07/19 03:12:50  94514C0 c      (ecm)   E1 EF AE 77 7F 17 AB AB 8B 3D 56 85 58 A8 60 48
2015/07/19 03:12:50  94514C0 c      (ecm)   83 B8 E6 36 72 E5 13 87 54 74 EE FC 55 D5 2E 3E
2015/07/19 03:12:50  94514C0 c      (ecm)   00 0E FA F4 9F 96 5B C7

Bleibt natürlich die Frage zu klären, warum sich oscam nicht auf die Längenangabe im ECM - in diesem Falle 82 70 0x95 - verlässt und die ECM Länge auf dieser Basis berechnet. Das wäre eine Frage an die Entwickler...

Genau!

Aber wie gesagt ... auf einmal (ohne ersichtlichen Grund), wurden auch 9Bs von der besagten Karte beantwortet. Ich benutze oscam #10076 auf Client und Server. Auf dem OSCam Trac konnte ich keinen Ticket finden und ehrlich gesagt weiss ich nicht so recht nach was ich suchen soll.