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.

ECM Abfragen mit unterschiedlichen ECM Prüfsummen

cylus1

Ist gelegentlich hier
Registriert
25. August 2010
Beiträge
60
Reaktionspunkte
9
Punkte
28
Moin Leute,

ich habe heute zusammen mit einem Sharepartner ein Problem erkannt. Einige Sharepartner fragen hin und wieder (vor allem HD+) ECMs ab die eigentlich schon im Cache liegen, aber in der einen Anfrage des besagten Clienten steht eine andere ECM-Checksumme. Meistens kommt hier dann ein "not found" oder interessanterweise ein Found aber erst laaange später. Diese Anfragen sorgen bei den Proxies scheinbar auch zum Freezen der eigenen Karte.

Hier ein konkretes Beispiel, User NORMAL funktioniert tadellos, User LAPPEN klappt meistens auch, ab und an kommt aber (wie man sieht) eine Abfrage mit einer anderen Checksumme:

Code: 
Sep 26 21:20:37 NORMAL (1830@000000/0000/EF11/92:95A3905E09CE94CEEA3F0E9E1895800B): cache3 (325 ms) by cache-proxie - VOX HD (cw count 5)
Sep 26 21:20:38 LAPPEN (1830@000000/0000/EF11/92:78073F61F35213169AD19195068C55B3): timeout (5000 ms) by proxie (F/2/2/6) - VOX HD (wait_time over)
Sep 26 21:20:47 NORMAL (1830@000000/0000/EF11/92:B35E8DF71E39BE56DD31765FC3DDC26C): cache3 (311 ms) by cache-proxie - VOX HD (cw count 3)
Sep 26 21:20:57 NORMAL (1830@000000/0000/EF11/92:AFF7616A7CA34C336E66A3B361A36B52): cache3 (321 ms) by cache-proxie - VOX HD (cw count 3)
Sep 26 21:21:07 NORMAL (1830@000000/0000/EF11/92:4A26F187DB3F5234785211296D8BE6C4): cache3 (319 ms) by cache-proxie - VOX HD (cw count 3)
Sep 26 21:21:17 LAPPEN (1830@000000/0000/EF11/92:07EF7E9C322341FDEA4F3E33B487BD10): cache3 (288 ms) by cache-proxie - VOX HD (cw count 6)
Sep 26 21:21:17 NORMAL (1830@000000/0000/EF11/92:07EF7E9C322341FDEA4F3E33B487BD10): cache3 (331 ms) by cache-proxie - VOX HD (cw count 6)
Sep 26 21:21:23 LAPPEN (1830@000000/0000/EF11/92:AF5976591683D471A0DBB064B38A113A): not found (730 ms) by proxie (F/1/1/6) - VOX HD (wait_time over)
Sep 26 21:21:27 NORMAL (1830@000000/0000/EF11/92:AA040B6D11175A328588083F6314C0AA): cache3 (318 ms) by cache-proxie - VOX HD (cw count 5)
#####
Sep 26 21:22:25 LAPPEN (1830@000000/0000/EF11/92:69DA2439B3DEAFA584CF182FABC4E64A): cache3 (4497 ms) by cache-proxie (F/1/1/6) - VOX HD (wait_time over) (cw count 3)
Sep 26 21:22:27 NORMAL (1830@000000/0000/EF11/92:A6E375FCF2DCFB20D5DAF0339CBACC54): cache3 (316 ms) by cache-proxie - VOX HD (cw count 4)
#####
Sep 26 21:26:47 NORMAL (1830@000000/0000/EF11/92:8AE33701DFABFF2179F2E47642E56407): cache3 (319 ms) by cache-proxie - VOX HD (cw count 4)
Sep 26 21:26:54 LAPPEN (1830@000000/0000/EF11/92:7B2F006BC55CA80BA3B36027FCE9A7FE): found (3206 ms) by proxie (F/1/1/6) - VOX HD (real 2855 ms)
Sep 26 21:26:57 LAPPEN (1830@000000/0000/EF11/92:9ED2962946C65B5B407FAB7A396D752A): cache3 (154 ms) by cache-proxie - VOX HD (cw count 3)
Sep 26 21:26:57 NORMAL (1830@000000/0000/EF11/92:9ED2962946C65B5B407FAB7A396D752A): cache3 (311 ms) by cache-proxie - VOX HD (cw count 3)
Sep 26 21:27:07 LAPPEN (1830@000000/0000/EF11/92:F64B109DAF0E45B370A842877A83FD1B): cache3 (277 ms) by cache-proxie - VOX HD (cw count 5)
Sep 26 21:27:07 NORMAL (1830@000000/0000/EF11/92:F64B109DAF0E45B370A842877A83FD1B): cache3 (325 ms) by cache-proxie - VOX HD (cw count 5)
Sep 26 21:27:13 LAPPEN (1830@000000/0000/EF11/92:7B2F006BC55CA80BA3B36027FCE9A7FE): found (3508 ms) by proxie (F/1/1/6) - VOX HD (real 3145 ms)

Was ich auch sehr interessant finde, obwohl der Client LAPPEN um 21:27:07 bereits ein gültiges CW bekommen hat, fragt er 6 Sekunden später nach einem neuen (erneut mit anderer ECM-Checksumme), obwohl das alte ja noch 4 Sekunden gültig war. Auch zu sehen daran, dass der Client der korrekt läuft erst um 21:27:13 nach dem neuen fragt.

Für mein Verständnis würde hier auch keine ECMWhitelist helfen, da die Länge des ECMs ja bei beiden gleich ist. Wie kann man das also wohl verhindern? Hat das schonmal jemand gesehen?

Habe schon versucht dem User per services und CAID direkt zu sagen was er abfragen darf. Leider kommt das immer noch.

Vielleicht hat das Verhalten ja schon einmal jemand gesehen und weiß Abhilfe.

Beste Grüße
 
Zuletzt bearbeitet von einem Moderator:
Was der User denn für einen Receiver bzw. welche Arten von Receivern hängen an seinen Server?
 
Das war auch meine erste Frage an den User. Leider wusste er es auf die schnelle nicht. Er wollte dann mal schauen. Ich dachte mir aber da ich das nun schon bei einigen "hin und wieder" gesehen habe, dass ich mal rausfinden müsste was sich dahinter verbirgt.

Meine erste Vermutung war ja auch Billig-Receiver sendet bescheuerte Abfragen, aber auch wenn dem so ist, wie kann man solche Abfragen denn gleich verwerfen? Abgesehen vom Rauswurf des Sharingpartners ;-)
 
Das kann auch einfach am Wetter liegen.
Ist der Empfang beeinträchtig können die ECM nicht sauber empfangen werden und werden Fehlerhaft an OSCam weitergeleitet und die Karte kann dann logischerweise nichts damit anfangen.
 
Kann man denn serverseitig parametertechnisch sinnvoll etwas gegen solche Probleme/Anfragen/Zusammenhänge machen? Wenn ich jetzt den LB an hab und er die Timeouts speichert ,etwas in den cache rutscht und stört.
 
Zuletzt bearbeitet:
DarkStarXxX schrieb:
Das kann auch einfach am Wetter liegen.
Ist der Empfang beeinträchtig können die ECM nicht sauber empfangen werden und werden Fehlerhaft an OSCam weitergeleitet und die Karte kann dann logischerweise nichts damit anfangen.
Zum Vergrößern anklicken....

Ich habe zuerst gedacht du möchtest mich verklappsen...

Aber ja, möglich ist das Theoretisch. Da stellt sich die Frage ob da das DVB-S nicht schon eine interne Prüfsumme für die ECMs hat damit falsche ECM Abfragen erst gar nicht rausgehen.

Wie dem auch sei, bleiben dabei noch zwei Fragen offen:
1. Wie kann man sich davor schützen?
2. Warum freezt dann die lokale Karte eines Proxies, wenn er so eine Anfrage bekommt und wie kann man dies unterbinden?


Ergänzung:

Ich habe noch etwas dabei beobachten können. Diese falschen Anfragen tauchen häufiger von verschiedenen Partnern auf. Ich habe schon eine "Quarantäne-Gruppe" dafür. Ich kann mir nicht vorstellen das es am Wetter liegt.
Die ECM-Prüfsumme sollte für ein ECM immer gleich sein, wenn soetwas wie schlechtes Wetter einzelne Bits verändert, müsste die Prüfsumme gleich komplett anders aussehen. Diese falschen Anfragen kommen allerdings häufig mit der gleichen Prüfsumme von mehreren Clients zu unterschiedlichen Zeiten. Das wäre wohl des Zufalls zuviel.

Noch einmal zur Veranschaulichung:
Eine ECM-Prüfsumme (Der Teil zwischen ECM-Länge (92) und dem "cache" oder "found") ist ziemlich eindeutig und wäre schon extremer Zufall wenn diese überhaupt mehrfach auftaucht bei dieser Zeichenlänge.
Normalerweise taucht also eine Prüfsumme genau einmal auf. Bzw. ist für einen genau definierten Zeitraum gültig (HD+ 10 Sekunden).

Beispiel:
Ich durchsuche das Log nach einer ECM-Prüfsumme eines von mir entschlüsselten Senders:

Code: 
grep "27B899DAC6D70645B9DD1079C77D43B6" /var/log/oscam-devils.log
Sep 27 09:21:48 user2 (1830@000000/0000/EF77/92:27B899DAC6D70645B9DD1079C77D43B6): cache3 (245 ms) by proxie
Sep 27 09:21:48 user1 (1830@000000/0000/EF77/92:27B899DAC6D70645B9DD1079C77D43B6): cache3 (325 ms) by proxie
Die Prüfsumme ist einzigartig.
Sie taucht hier zwar zwei mal auf, aber zum gleichen Zeitpunkt - Der Sender wurde also von zwei Usern zur gleichen Zeit abgefragt. Hier passt also alles.

Nehme ich nun eine "böse" ECM-Anfrage mit falscher Prüfsumme sieht das anders aus:

Code: 
grep "C17566E487FDB2B02F3D1D440FA08C9F" /var/log/oscam-devils.log
Sep 27 07:13:36 user5 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): timeout (5001 ms) by proxie
Sep 27 07:13:36 user6 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): not found (3831 ms) by proxie
Sep 27 07:13:36 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): not found (4292 ms) by proxie
Sep 27 07:14:50 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): not found (3237 ms) by proxie
Sep 27 07:15:20 user5 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): not found (350 ms) - RTLNITRO HD (wait_time over)
Sep 27 07:17:28 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): timeout (5003 ms) by proxie
Sep 27 07:18:27 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): not found (352 ms) - RTLNITRO HD (wait_time over)
Sep 27 07:19:47 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): not found (350 ms) - RTLNITRO HD (wait_time over)
Sep 27 07:29:26 user6 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): cache3 (34 ms) by proxie
Sep 27 07:29:27 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): cache3 (36 ms) by proxie
Sep 27 07:30:27 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): cache3 (18 ms) by proxie
Sep 27 07:30:28 user8 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): cache3 (14 ms) by proxie
Sep 27 07:30:31 user6 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): cache3 (12 ms) by proxie
Sep 27 07:30:59 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): timeout (5000 ms) by proxie
Sep 27 07:31:30 user8 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): found (463 ms) by proxie
Sep 27 07:32:42 user5 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): found (3876 ms) by proxie
Sep 27 07:32:42 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): cache2 (3274 ms) by proxie
Sep 27 07:33:29 user7 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): found (2590 ms) by proxie
Sep 27 07:33:29 user6 (1830@000000/0000/2EAF/92:C17566E487FDB2B02F3D1D440FA08C9F): cache2 (1040 ms) by proxie

Wie man hier sieht, taucht die selbe ECM Prüfsumme mehrfach zu unterschiedlichen Zeiten auf und auch bei unterschiedlichen Clients.
Das erste mal sehe ich die Anfrage um 07:13:36 und das letzte mal um 07:33:29

Die Namen wurden natürlich anonymisiert.
Ich habe keine Lust auf bestimmte Leute mit dem Finger zu zeigen und zu sagen: Du bist Schuld! - Ich möchte das ganze verstehen und am Besten lösen. Auch wenn diese Anfragen immer von den gleichen Usern kommen...
 
Zuletzt bearbeitet von einem Moderator:
Leider hat scheinbar keine eine Idee.

Ich habe allerdings in Selbstversuchen und Analyse des anderen Systems zumindest herausgefunden, wie sich solche Anfragen aufschaukeln, bzw. es zumindest begünstigen.

Und zwar wenn jemand services auf ein Share packt, das diese Kanäle gar nicht erleuchtet.
Beispiel:

Oscam A hat einen Proxie mit Max TV (1830, Kroatien), packt aber fälschlicherweise auch HD+ als service mit drauf.
Oscam B ist mit Oscam A verbunden und bekommt per CCcam_ext die services übertragen und möchte daher über Oscam A Pro7 HD öffnen. Oscam B versucht es über den Proxie mit MaxTV, bekommt aber keine Antwort. Nun vergisst Oscam B das Trennen nach NodeIDs (aufgrund des falschen Services - eventuell auch ein Oscam Bug) und fragt Oscam A nun wieder nach der SID und schon haben wir einen Loop im Share. Ab diesem Zeitpunkt spielt Oscam ein bisschen "verrückt".

Die Ursache sehe ich darin allerdings nicht. Vermutlich sind es wirklich irgendwelche Receiver die kein natives CCCam sprechen, sondern eher etwas "gefrickeltes".

Wenn man alles korrekt konfiguriert hat, also im Prinzip jeder seiner Sharepartner, schaukeln sich diese Anfragen nicht so auf.

Schön wäre aber, wenn jemand noch eine zündende Idee hat, wie man diese Anfragen ganz unterbindet. Ich könnte mir nämlich auch vorstellen, das dies den cwc von Oscam durcheinander bringen kann. Auf jeden Fall ist es unnötiger Ballast.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

F
Umschaltzeiten ICAM -> Pyur HD hoch
Antworten
8
Aufrufe
1K
FaiX
F
  • Frage Frage
CAID 1838 Abfragen
Antworten
8
Aufrufe
837
Scrubsss
S
O
gelöst [Erledigt] UM02 ECM Timings
Antworten
12
Aufrufe
2K
RuckZuck
B
gelöst ORF Karte Fehlermeldung
2
Antworten
18
Aufrufe
1K
buzzard
B
C
gelöst HD05 keine Freischaltung in Easymouse 2 IPC OSCAM 11730
Antworten
8
Aufrufe
1K
ceulem
C
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…