Hi Leute,
Ich bin was mein Wissen über Programmierung und CS im Detail angeht weiß Gott kein Anfänger, nur dieses Problem lässt mich nicht in Ruhe.
Folgendes:
Derzeit verwende ich Acamd im DVBViewer mit 3 Lines, für jede CAID einzeln. Problem: teilweise gleich 3 Logins auf ein und dem selben User.
Nun Versuche ich es so ins laufen zu kriegen, wie ich es bisher auch bei vielen Receivern mit Newcamd (mgclient, extended Newcamd) mache, über einen Port mehrere CAIDs übertragen.
Acamd bietet hier die newcamd2-Line für an. Das funktioniert auch, bei allen Kartensystemen, die vollständige Kontrollwörter liefern.
Bei Sky (V14) jedoch, wird immer nur eine Hälfte des Kontrollwortes gesetzt. Nun scheint laut Monitor in Acamd das leere Kontrollword in den meisten Fällen durch ein Zufälliges aufgefüllt zu werden.
Somit kommt es bei jedem Keywechsel zu einem Freezer von etwa einer halben Sekunde, äußert sich wie schlechter Empfang.
In ganz wenigen Fällen, läuft es mal 3-4 Abfragen gut, dann wird der CW in Acamd mit Nullen aufgefüllt. Was auch korrekt ist.
Das Netzwerkprotokoll von Oscam habe ich bereits überprüft, es wird an den Client defnitiv das komplette Kontrollword übermittelt, die andere Hälfte ist jeweils als Nullbytes.
Beispiel Sky, geloggte CW:
Hier sieht man, dass die Kontrollwordhälften (odd und even) abwechselnd übertragen werden und die andere hälfte genullt ist.
Im gegensatz bei den HD+ sendern über die HD02 karte:
Hier wird zwar auch immer nur eine Hälfte aktualisiert, aber die andere hälfte wird "mitgeschleift" und nicht genullt sondern aktualisiert.
Die Logfile in Acamd sieht übrigens so aus bei Sky mit ganz normalen Newcamd, wo alles fehlerfrie läuft:
HD+:
Bei HD+ sieht es genauso aus, weil Acamd hier offenbar auch immer nur den teil aktualisiert, der gerade neu ist, bei Key sieht man das auch deutlich, dass hier das komplette CW immer vollständig ist.
bei newcamd2, sieht es dagegen anders aus.
SendDCW wird immer für odd und even ausgeführt. Dabei ist die gerade abgefragte hälfte korrekt, die andere immer irgendwie etwas zufälliges. Das Problem, die alte CW-Hälfte ist eine gewisse Zeit lang
noch gültig (ca 500ms, das timeout für die Sky v14 karte) Wenn jetzt aber das alte CW durch einen zufälligen ungültigen Wert getauscht wird ist es klar, dass dort Müll bei herauskommt:
Das einzige was bei Sky hilft, ist entweder warten, oder mehrfach auf "rescan" klicken, dann fängt er sich irgendwann für ein paar Minuten, bis dann das gleiche Problem erneut auftritt:
Ich habe hier einmal einen Ausschnit aus der Logfile,
Ist jetzt aus einer Logfile in der in ca 60 Sekunden 15MB zurecht gekommen sind, denn zu dem o.g. Problem kommt noch, dass Acamd jeden einzelnen EMM rausschickt, auch wenn dieser nicht zur Karte passt, alles was er empfängt.
Lustigerweise kommen diese bei Oscam nie an. Aufgrund der schieren Größe der Logdatei müssen die Zeitangaben nicht stimmen.
Wenn ich AU bei Acamd deaktiviere (habe ich einmal testhalber gemacht) kommt etwas anderes bei heraus. In dem Fall gibt es nur 2 SendDCW, nicht Drei, immer noch einer zu viel.
EMMs funktionieren bei HD+ ganz normal. Laut Logfile von Acamd werden die Seriennummern der Karten auch korrekt übertragen, für beide Karten.
Dennoch macht Acamd 6.2.0 Müll.
Alle anderen Clients mit Extended Newcamd-Protokoll funktionieren Fehlerfrei.
CCCam kommt für mich nicht in Frage, da Acamd hier beispielsweise bei Sky Select nur eine Abfrage macht, und Anschließend nicht mehr entschlüsselt, damit habe ich schonmal eine Sky Select Bestellung verhauen, hätte ich keinen Transponder-Dump angefertigt und nachträglich entschlüsselt.
Zusätzlich kann ich von Hadu auch nur abraten, da dieser nur CCCam kann. EMMs habe ich hier noch nicht getestet. Problem ist jedoch, dass bei mehr als 2 Instanzen (DVBViewer Recording-Service)
Fehler beim Entschlüsseln entstehen, das liegt an einer nicht Threadsicheren Implementierung des CSA-Algorithmus oder übrigen Komponenten von Hadu.
Das ist erst einmal eine Menge Stoff, aber vielleicht gibt es ja den ein oder anderen Experten hier, der mir weiter helfen kann, oder mir bescheid geben kann wo ich die Sourcen von Acamd zwecks weiterentwicklung / Fehlerkorrektur finde.
Gruß
t5b6
Nachtrag, ein ideales beispiel:
Oscam log:
Dazugehörende Acamd-Log
Die dort freigestellte Anfrage erzeugte keinen Freeze.
Hier wurde kein "zufälliger" Wert gesetzt.
Anhand der Oscam-Log kann genau gesehen werden, welche CWs falsch sind, ich habe diese der Einfachheit mal farblich markiert. Grün korrekt, Rot falsch.
Wie komme ich darauf, dass es zufällig ist?
-> Ganz Einfach, Klick auf den Rescan button forciert erneut einen SendDCW. Beide CW-Hälften werden geschrieben. Die korrekte, derzeit gültige Hälfte bleibt immer gleich, die andere hälfte variiert zufällig.
Ich bin was mein Wissen über Programmierung und CS im Detail angeht weiß Gott kein Anfänger, nur dieses Problem lässt mich nicht in Ruhe.
Folgendes:
Derzeit verwende ich Acamd im DVBViewer mit 3 Lines, für jede CAID einzeln. Problem: teilweise gleich 3 Logins auf ein und dem selben User.
Nun Versuche ich es so ins laufen zu kriegen, wie ich es bisher auch bei vielen Receivern mit Newcamd (mgclient, extended Newcamd) mache, über einen Port mehrere CAIDs übertragen.
Acamd bietet hier die newcamd2-Line für an. Das funktioniert auch, bei allen Kartensystemen, die vollständige Kontrollwörter liefern.
Bei Sky (V14) jedoch, wird immer nur eine Hälfte des Kontrollwortes gesetzt. Nun scheint laut Monitor in Acamd das leere Kontrollword in den meisten Fällen durch ein Zufälliges aufgefüllt zu werden.
Somit kommt es bei jedem Keywechsel zu einem Freezer von etwa einer halben Sekunde, äußert sich wie schlechter Empfang.
In ganz wenigen Fällen, läuft es mal 3-4 Abfragen gut, dann wird der CW in Acamd mit Nullen aufgefüllt. Was auch korrekt ist.
Das Netzwerkprotokoll von Oscam habe ich bereits überprüft, es wird an den Client defnitiv das komplette Kontrollword übermittelt, die andere Hälfte ist jeweils als Nullbytes.
Beispiel Sky, geloggte CW:
- 098C:000000:0026, CW:0000000000000000EA13E4E1871143DB
- 098C:000000:0026, CW:EB3BFB214B1B65CB0000000000000000
- 098C:000000:0026, CW:000000000000000009BE5F2668DA2F71
Im gegensatz bei den HD+ sendern über die HD02 karte:
- 1843:000000:EF10, CW:48CADAEC94C068BC9A9DCC03A9489687
- 1843:000000:EF10, CW:4328FA653BF7DB0D9A9DCC03A9489687
- 1843:000000:EF10, CW:4328FA653BF7DB0D4FF7EE34338438EF
- 1843:000000:EF10, CW
195D63CF2F5AE954FF7EE34338438EF - 1843:000000:EF10, CW195D63CF2F5AE95CFB20C8D78746A56
Die Logfile in Acamd sieht übrigens so aus bei Sky mit ganz normalen Newcamd, wo alles fehlerfrie läuft:
21:49:50.287: Newcamd 1: ECM [1A0F][098C/00000000] Pro (0.092)
21:49:50.287: [00] SendDCW Odd: :0AAFF8B1595AB063
21:49:57.287: Newcamd 1: ECM [1A0F][098C/00000000] Pro (0.093)
21:49:57.287: [00] SendDCW Even: 081D98BD5DBD031D:
21:50:04.283: Newcamd 1: ECM [1A0F][098C/00000000] Pro (0.091)
21:50:04.283: [00] SendDCW Odd: :9E99EF2609940EAB
21:49:50.287: [00] SendDCW Odd: :0AAFF8B1595AB063
21:49:57.287: Newcamd 1: ECM [1A0F][098C/00000000] Pro (0.093)
21:49:57.287: [00] SendDCW Even: 081D98BD5DBD031D:
21:50:04.283: Newcamd 1: ECM [1A0F][098C/00000000] Pro (0.091)
21:50:04.283: [00] SendDCW Odd: :9E99EF2609940EAB
HD+:
21:54:16.723: Newcamd 0: ECM [19EC][1843/00000000] Pro (0.382)
21:54:16.723: [00] SendDCW Odd: :038D42D27306F46D
21:54:23.717: Newcamd 0: ECM [19EC][1843/00000000] Pro (0.379)
21:54:23.717: [00] SendDCW Even: C7B6F7747BB1234F:
21:54:30.714: Newcamd 0: ECM [19EC][1843/00000000] Pro (0.376)
21:54:30.714: [00] SendDCW Odd: :5A2A4BCF8D6C2D26
21:54:16.723: [00] SendDCW Odd: :038D42D27306F46D
21:54:23.717: Newcamd 0: ECM [19EC][1843/00000000] Pro (0.379)
21:54:23.717: [00] SendDCW Even: C7B6F7747BB1234F:
21:54:30.714: Newcamd 0: ECM [19EC][1843/00000000] Pro (0.376)
21:54:30.714: [00] SendDCW Odd: :5A2A4BCF8D6C2D26
Bei HD+ sieht es genauso aus, weil Acamd hier offenbar auch immer nur den teil aktualisiert, der gerade neu ist, bei Key sieht man das auch deutlich, dass hier das komplette CW immer vollständig ist.
bei newcamd2, sieht es dagegen anders aus.
SendDCW wird immer für odd und even ausgeführt. Dabei ist die gerade abgefragte hälfte korrekt, die andere immer irgendwie etwas zufälliges. Das Problem, die alte CW-Hälfte ist eine gewisse Zeit lang
noch gültig (ca 500ms, das timeout für die Sky v14 karte) Wenn jetzt aber das alte CW durch einen zufälligen ungültigen Wert getauscht wird ist es klar, dass dort Müll bei herauskommt:
Das einzige was bei Sky hilft, ist entweder warten, oder mehrfach auf "rescan" klicken, dann fängt er sich irgendwann für ein paar Minuten, bis dann das gleiche Problem erneut auftritt:
Ich habe hier einmal einen Ausschnit aus der Logfile,
23:36:38.367: Newcamd2 0: -> ECM [1A01][098C/00000000]
23:36:38.479: Newcamd2 0: <- ECM [1A01][098C/00000000] (0.115)
23:36:38.482: [00] SendDCW Odd: :582F30B79053EACD
23:36:38.558: [00] SendDCW Even: 18B72FFEB218C791:
23:36:38.634: [00] SendDCW Odd: :582F30B79053EACD
23:36:44.588: Newcamd2 0: -> ECM [1A01][098C/00000000]
23:36:44.700: Newcamd2 0: <- ECM [1A01][098C/00000000] (0.115)
23:36:44.707: [00] SendDCW Odd: :7B273CDED37066A9
23:36:44.783: [00] SendDCW Even: A0BA80DA9053EACD:
23:36:44.859: [00] SendDCW Odd: :7B273CDED37066A9
23:36:50.972: Newcamd2 0: -> ECM [1A01][098C/00000000]
23:36:51.077: Newcamd2 0: <- ECM [1A01][098C/00000000] (0.108)
23:36:51.085: [00] SendDCW Even: B23E5B4B4A9BE8CD:
23:36:38.479: Newcamd2 0: <- ECM [1A01][098C/00000000] (0.115)
23:36:38.482: [00] SendDCW Odd: :582F30B79053EACD
23:36:38.558: [00] SendDCW Even: 18B72FFEB218C791:
23:36:38.634: [00] SendDCW Odd: :582F30B79053EACD
23:36:44.588: Newcamd2 0: -> ECM [1A01][098C/00000000]
23:36:44.700: Newcamd2 0: <- ECM [1A01][098C/00000000] (0.115)
23:36:44.707: [00] SendDCW Odd: :7B273CDED37066A9
23:36:44.783: [00] SendDCW Even: A0BA80DA9053EACD:
23:36:44.859: [00] SendDCW Odd: :7B273CDED37066A9
23:36:50.972: Newcamd2 0: -> ECM [1A01][098C/00000000]
23:36:51.077: Newcamd2 0: <- ECM [1A01][098C/00000000] (0.108)
23:36:51.085: [00] SendDCW Even: B23E5B4B4A9BE8CD:
Ist jetzt aus einer Logfile in der in ca 60 Sekunden 15MB zurecht gekommen sind, denn zu dem o.g. Problem kommt noch, dass Acamd jeden einzelnen EMM rausschickt, auch wenn dieser nicht zur Karte passt, alles was er empfängt.
Lustigerweise kommen diese bei Oscam nie an. Aufgrund der schieren Größe der Logdatei müssen die Zeitangaben nicht stimmen.
Wenn ich AU bei Acamd deaktiviere (habe ich einmal testhalber gemacht) kommt etwas anderes bei heraus. In dem Fall gibt es nur 2 SendDCW, nicht Drei, immer noch einer zu viel.
EMMs funktionieren bei HD+ ganz normal. Laut Logfile von Acamd werden die Seriennummern der Karten auch korrekt übertragen, für beide Karten.
Dennoch macht Acamd 6.2.0 Müll.
Alle anderen Clients mit Extended Newcamd-Protokoll funktionieren Fehlerfrei.
CCCam kommt für mich nicht in Frage, da Acamd hier beispielsweise bei Sky Select nur eine Abfrage macht, und Anschließend nicht mehr entschlüsselt, damit habe ich schonmal eine Sky Select Bestellung verhauen, hätte ich keinen Transponder-Dump angefertigt und nachträglich entschlüsselt.
Zusätzlich kann ich von Hadu auch nur abraten, da dieser nur CCCam kann. EMMs habe ich hier noch nicht getestet. Problem ist jedoch, dass bei mehr als 2 Instanzen (DVBViewer Recording-Service)
Fehler beim Entschlüsseln entstehen, das liegt an einer nicht Threadsicheren Implementierung des CSA-Algorithmus oder übrigen Komponenten von Hadu.
Das ist erst einmal eine Menge Stoff, aber vielleicht gibt es ja den ein oder anderen Experten hier, der mir weiter helfen kann, oder mir bescheid geben kann wo ich die Sourcen von Acamd zwecks weiterentwicklung / Fehlerkorrektur finde.
Gruß
t5b6
Nachtrag, ein ideales beispiel:
Oscam log:
2015/10/01 00:23:41 7EAD7107 c (ecm) user (098C:000000:0083, CW:0D1E75A066DDC2050000000000000000): cache2 (0 ms) by v14
2015/10/01 00:23:45 7EAD7107 c (ecm) user (098C:000000:0083, CW:0000000000000000B00AA45E712962FC): cache2 (90 ms) by v14
2015/10/01 00:23:52 7EAD7107 c (ecm) user (098C:000000:0083, CW:BA388D7F256A1DAC0000000000000000): found (87 ms) by v14
2015/10/01 00:23:59 7EAD7107 c (ecm) user (098C:000000:0083, CW:00000000000000006005E24717360C59): cache2 (86 ms) by v14
2015/10/01 00:24:06 7EAD7107 c (ecm) user (098C:000000:0083, CW:EEA28616283E369C0000000000000000): cache2 (89 ms) by v14
2015/10/01 00:24:13 7EAD7107 c (ecm) user (098C:000000:0083, CW:000000000000000072154FD6B3C4F168): found (83 ms) by v14
2015/10/01 00:24:20 7EAD7107 c (ecm) user (098C:000000:0083, CW:6938D374D6332A330000000000000000): found (87 ms) by v14
2015/10/01 00:23:45 7EAD7107 c (ecm) user (098C:000000:0083, CW:0000000000000000B00AA45E712962FC): cache2 (90 ms) by v14
2015/10/01 00:23:52 7EAD7107 c (ecm) user (098C:000000:0083, CW:BA388D7F256A1DAC0000000000000000): found (87 ms) by v14
2015/10/01 00:23:59 7EAD7107 c (ecm) user (098C:000000:0083, CW:00000000000000006005E24717360C59): cache2 (86 ms) by v14
2015/10/01 00:24:06 7EAD7107 c (ecm) user (098C:000000:0083, CW:EEA28616283E369C0000000000000000): cache2 (89 ms) by v14
2015/10/01 00:24:13 7EAD7107 c (ecm) user (098C:000000:0083, CW:000000000000000072154FD6B3C4F168): found (83 ms) by v14
2015/10/01 00:24:20 7EAD7107 c (ecm) user (098C:000000:0083, CW:6938D374D6332A330000000000000000): found (87 ms) by v14
Dazugehörende Acamd-Log
00:23:39.004: connecting to 10.0.0.2:33999/tcp (10.0.0.2)00:23:40.318: Newcamd2 0: CaID=1843 admin=1 srvUA=00000000******** provider 008011/00000000******** <unhandled> 000000/00000000******** <unhandled> 003411/00000000******** <unhandled>
00:23:40.318: Newcamd2 0: Change to Chameleon2 mode:
00:23:40.495: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:40.504: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.012)
00:23:40.509: [00] SendDCW Odd: :030000033D3E0580
00:23:40.509: [00] SendDCW Even: 0D1E75A066DDC205:
00:23:44.001: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:44.097: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.099)
00:23:44.099: [00] SendDCW Odd: :B00AA45E712962FC
00:23:44.099: [00] SendDCW Even: B0EA57F180EB57C2:
00:23:50.999: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:51.101: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.104)
00:23:51.103: [00] SendDCW Even: BA388D7F256A1DAC:
00:23:57.997: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:58.095: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.100)
00:23:58.105: [00] SendDCW Odd: :6005E24717360C59
00:23:58.105: [00] SendDCW Even: 204576DB6E3A20C8:
00:24:04.996: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:24:05.092: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.099)
00:24:05.101: [00] SendDCW Odd: :30343599364442BC
00:24:05.101: [00] SendDCW Even: EEA28616283E369C:
00:24:11.994: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:24:12.086: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.095)
00:24:12.095: [00] SendDCW Odd: :72154FD6B3C4F168
00:24:12.095: [00] SendDCW Even: 204576DB6E3A20C8:
00:24:19.007: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:24:19.101: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.096)
00:24:19.106: [00] SendDCW Odd: :30343599364442BC
00:24:19.106: [00] SendDCW Even: 6938D374D6332A33:
00:25:53.097: socket: EOF on read
00:23:40.318: Newcamd2 0: Change to Chameleon2 mode:
00:23:40.495: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:40.504: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.012)
00:23:40.509: [00] SendDCW Odd: :030000033D3E0580
00:23:40.509: [00] SendDCW Even: 0D1E75A066DDC205:
00:23:44.001: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:44.097: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.099)
00:23:44.099: [00] SendDCW Odd: :B00AA45E712962FC
00:23:44.099: [00] SendDCW Even: B0EA57F180EB57C2:
00:23:50.999: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:51.101: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.104)
00:23:51.103: [00] SendDCW Even: BA388D7F256A1DAC:
00:23:57.997: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:23:58.095: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.100)
00:23:58.105: [00] SendDCW Odd: :6005E24717360C59
00:23:58.105: [00] SendDCW Even: 204576DB6E3A20C8:
00:24:04.996: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:24:05.092: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.099)
00:24:05.101: [00] SendDCW Odd: :30343599364442BC
00:24:05.101: [00] SendDCW Even: EEA28616283E369C:
00:24:11.994: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:24:12.086: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.095)
00:24:12.095: [00] SendDCW Odd: :72154FD6B3C4F168
00:24:12.095: [00] SendDCW Even: 204576DB6E3A20C8:
00:24:19.007: Newcamd2 0: -> ECM [1AB6][098C/00000000]
00:24:19.101: Newcamd2 0: <- ECM [1AB6][098C/00000000] (0.096)
00:24:19.106: [00] SendDCW Odd: :30343599364442BC
00:24:19.106: [00] SendDCW Even: 6938D374D6332A33:
00:25:53.097: socket: EOF on read
Die dort freigestellte Anfrage erzeugte keinen Freeze.
Hier wurde kein "zufälliger" Wert gesetzt.
Anhand der Oscam-Log kann genau gesehen werden, welche CWs falsch sind, ich habe diese der Einfachheit mal farblich markiert. Grün korrekt, Rot falsch.
Wie komme ich darauf, dass es zufällig ist?
-> Ganz Einfach, Klick auf den Rescan button forciert erneut einen SendDCW. Beide CW-Hälften werden geschrieben. Die korrekte, derzeit gültige Hälfte bleibt immer gleich, die andere hälfte variiert zufällig.
Zuletzt bearbeitet:
