Patch - 09C4/098C bad CW Erkennung - proxy + cacheex

[tecfreak]

show_me_the_bad_guy_3.patch
Der patch erlaubt es bei den NDS Sendern (z.Zt. nur Sky SAT) mit den neuen 64bit CWs die potenziell ungültigen anzeigen und sie wahlweise auch verwerfen zu lassen.

Folgendes ist zu beachten:
- aktiviert wird die Funktion nur mit "disablecrccws_only_for" und nur in der oscam.server in der reader config
- mit "dropbadcws = 1" in der reader config kann man dafür sorgen, dass das potenziell falsche CW verworfen wird, sonst gibt es nur eine Logmeldung und keine Aktion
- die bad CW Erkennung funktioniert prinzipbedingt "nur" mit einer 99.998% Genauigkeit und kann somit theoretisch eine Falschmeldung liefern
- ansonsten ist das Verhalten wie mit dem aktuellen trunk mit der Außnahme, dass es bei Sendern die weiterhin ein 48bit CW nutzen zu einer Falschmeldung kommt
- eine Falschmeldung in Verbindung mit "dropbadcws = 1" führt dazu, dass es kurz freezt oder der Sender dauerhaft dunkel bleibt wenn es sich um 48bit CWs handelt.

Sendergruppen welche man auf der NDS Karte gebucht haben kann und welche nach wie vor das 48bit CW nutzen wären HD+, ORF, HD Austria und PYUR.
Also aufpassen mit dem Parameter dropbadcws und wie ihr das log intepretiert.
An der Stelle nochmal Danke an @kabeltod für diesen Hinweis.

EDIT: Version 3 des patches mit einer höheren Genauigkeit (99.9985% statt 99.61%).

Im log sind dann folgende Meldungen zu sehen:

(ecm) Probably got bad CW from reader: *reader_label*, caid *caid*, srvid *srvid* (*ecm_md5*)
(ecm) Probably got bad CW from reader: *reader_label*, caid *caid*, srvid *srvid* (*ecm_md5*) - dropping CW

log_bad_cacheex_cw_2.patch hinzugefügt

Ähnlich wie der Patch oben mit der selben Erkennung, nur speziell für cacheex.

Folgendes ist zu beachten:
- bei cacheex mode 1 & 2 readern mit "dropbadcws = 1" werden die CWs direkt verworfen und landen nicht im cache
- bei cacheex usern im mode 3 wird dagegen grundsätzlich nur geloggt
- aktiviert wird die Funktion im reader über "disablecrccws_only_for" (für cacheex mode 1 oder 2 reader) oder in der user config über "disablecrccacheex_only_for" (für cacheex mode 3 user)
- geloggt wird nur nach debug_log 512 (CACHEEX logging)

Ansonsten auch die Anmerkungen weiter oben beachten - vor allem die zu den Sendergruppen mit den alten 48bit CWs.

Bitte beachten, dass ggf. die CPU Last deutlich steigen kann wenn viel gefiltert wird. Daher am besten nur für die Fehleranalyse nutzen um die bad peers zu identifizieren.
EDIT: CPU Last scheint gleich zu bleiben bzw. nicht signifikant anzusteigen. Theoretisch müsste sie sogar wenn am reader die CWs verworfen werden etwas zurückgehen.

Im debug_log 512 sind dann folgende Meldungen zu sehen:

(cacheex) Probably got pushed bad CW to cacheex reader: *reader_label*, caid *caid*, srvid *srvid*
(cacheex) Probably got pushed bad CW to cacheex reader: *reader_label*, caid *caid*, srvid *srvid* - dropping CW
(cacheex) Probably got bad CW from cacheex user: *user*, caid *caid*, srvid *srvid*

Bitte keine Fragen wie ein Patch eingespielt wird. Wenn ihr das nicht wisst, dann ist das hier vermutlich nichts für euch.

 

[Hannes0009]

Frage, angenommen man hätte jetzt 2 Karten. Ein Reader mit Skip... umgestellt den anderen nicht. Es werden mittels LB beide angefragt. Nun stellt sich raus, dass einer einen Bad-CW geliefert hat, würde dann der andere automatisch genommen werden oder würde dann (je nach Einstellung) der schnellste genommen werden ?

 

[tecfreak]

Musst du schauen was der LB macht. Das habe ich nicht getestet. Aber eigentlich ist der eine Reader dann für die bestimmte SID erstmal für eine bestimmte Zeit gesperrt wenn ich mich nicht täusche.

 

[Hannes0009]

Bin momentan nicht zuhause, deshalb frage ich.
Die Leute, die mit dem Cachex Probleme haben und eine zusätzliche lokale Karte haben, könnten so vielleicht weniger Freezer dann bekommen.
War nur so ne Idee von mir

 

[tecfreak]

Ja, testet und berichtet. Gedacht ist das aber erstmal nur als reine Erkennung.

 

[GTD Bastion]

Ich hab es mir den Patch mal reingebaut.
Schaut bislang gut aus...

Anbei hier noch die Binary für Native Linux Systeme und Rasperry HARD FPU

 

[GTD Bastion]

Noch ein Nachtrag:
Der ein Vorschlag ist:
Wäre es für das Logging nicht Sinnvoll wenn er auch den betreffenden ECM ausgibt?
Beispiel:

Probably got bad CW from reader: SkyReader1 [4CFF7922474D21A18D23D51583DB5D3A]
Das würde das Loggen definitiv ein wenig wenig erleichtern.

 

[Tec-Hi]

Hi

Frage, angenommen man hätte jetzt 2 Karten. Ein Reader mit Skip... umgestellt den anderen nicht. Es werden mittels LB beide angefragt. Nun stellt sich raus, dass einer einen Bad-CW geliefert hat, würde dann der andere automatisch genommen werden oder würde dann (je nach Einstellung) der schnellste genommen werden ?

da der Patch auf nur der neusten svn basieren sollte, was sonst, wäres nicht der Falll, da die Anfragen auf hard wech sind,
oder solls hier nur alle verwirren.

was sollte man mit dem Fake CW anfagen, loggen was keiner gebrauchen kann ?

HF

 

[tecfreak]

@Tec-Hi
Es gibt Leute die das gebrauchen können. Wenn du persönlich nichts damit anfangen kannst, dann ist das doch ok, nur muss man das auch gleich ins Board schreiben?

Wäre es für das Logging nicht Sinnvoll wenn er auch den betreffenden ECM ausgibt?

Gute Idee. Werde ich gleich einbauen, testen und im OP einfügen.

 

[GTD Bastion]

Geb bitte bescheid wenn das erledigt ist.

@Tec-Hi

was sollte man mit dem Fake CW anfagen, loggen was keiner gebrauchen kann ?

Ganz einfach:
Damit können wir heraus finden von welchen Peers das beispielsweise im Cacheex kommt.
Das ermöglich zum einen eine Aufklärung und zum anderen eine bessere Kommunikation.
Aus meiner Sicht.

 

[GTD Bastion]

Patch funktioniert.
Ich habe hier noch die neuen Binarys für Nativ Linux und Raspberry

 

[pehedima]

EDIT: Nicht umgestellte Sender scheint es nicht mehr zu geben, also sind keine Fehlalarme mehr zu erwarten.

Es gibt sehr wohl Fehlarlarme. Das liegt einfach daran, dass man ein CW ja nicht 100% auf Gültigkeit prüfen kann.
Also kann diese Ausgabe im Logfile erscheinen, obwohl das CW korrekt war. Wenn man das dann natürlich dropped, hat man auch Freezer.
Sozusagen selbst gemachte.

Also ich habe mir die betreffenden Code Zeilen angeschaut und kann dir mit 100% Sicherheit sagen, dass beide Optionen das selbe bewirken was auch dein Patch tut. Da schlüpft nix durch o.ä. was zu einem Freezer führen könnte, egal ob mit deinem patch oder einer der beiden Optionen.

Wenn diese Aussage so stimmt, dann wundere ich mich, warum durch diesen Patch hier die folgende Abprüfung geändert wurde:

-            if(!(chk_if_ignore_checksum(er, &cfg.disablecrccws_only_for) + chk_if_ignore_checksum(er, &reader->disablecrccws_only_for)))
+            if(!chk_if_ignore_checksum(er, &cfg.disablecrccws_only_for) && !chk_if_ignore_checksum(er, &reader->disablecrccws_only_for))

Aber, ihr wisst ja, was ihr tut.

 

[tecfreak]

Es gibt sehr wohl Fehlarlarme. Das liegt einfach daran, dass man ein CW ja nicht 100% auf Gültigkeit prüfen kann.

Das ist richtig, aber die Wahrscheinlichkeit, dass das eintritt ist sehr sehr gering. Ich werde aber nochmal nachbessern und nur dann das CW als ungültig markieren wenn auch wirklich beide checksum bytes stimmen, also das CW damit verändert wurde und ungültig ist. Dann ist es statt zu 99,99% dann zu 99,99999999% sicher.

Ist wie gesagt eh alles nur für die Fehlersuche und nicht für den Dauereinsatz.

Wenn diese Aussage so stimmt, dann wundere ich mich, warum durch diesen Patch hier die folgende Abprüfung geändert wurde:

Hat sich in der Funktion dieser if-Abfrage denn etwas geändert? Ist das Verhalten jetzt anders?
War für mich nur reine Kosmetik da ich es hasse wenn einer das auf diese weise macht. Kannst es also ignorieren.

 

[pehedima]

Mein letztes Statement dazu:

Ich habe den Fehlalarm bekommen und weiß sicher, dass mein Server feherfrei läuft.
Die Wahrscheinlichkeit ist genau 1/256, das der Alarm auch bei korreten CW ausgegeben wird, wenn nur ein CRC-Bypte geprüft wird.

War für mich nur reine Kosmetik da ich es hasse wenn einer das auf diese weise macht. Kannst es also ignorieren.

Da es in der Programmierung nicht um Kosmetik, sondern um Funktion geht, kann man das nicht ignorieren.
Das solltest du als Enwickler wissen, das diese Anweisung vom Compiler anders interpretiert wird und somit nicht zum gleichen Machinencode führt.
Da es auch Compiler Bugs gibt....

Aber, wem sage ich das denn alles.....

 

[tecfreak]

Die Wahrscheinlichkeit ist genau 1/256

Ich habe aber wie gesagt geschrieben, dass es zu verbessern ist und das wird auch geschehen und ich werde noch anfügen, dass es nicht auszuschliueßen ist, dass auch mal ein gültiges CW als fehlerhaftes erkannt wird. Dann liegt die Wahrscheinlichkeit bei ~ 1/256² und das sollte doch wohl für diesen Zweck ja reichen.

Da es in der Programmierung nicht um Kosmetik, sondern um Funktion geht, kann man das nicht ignorieren.
Das solltest du als Enwickler wissen, das diese Anweisung vom Compiler anders interpretiert wird und somit nicht zum gleichen Machinencode führt.
Da es auch Compiler Bugs gibt....

Aber, wem sage ich das denn alles.....

Merks du noch was?