Bug #5099

cccam protocol 2.3.0 - Ignore ECM request

Added by Alpay Yildiray over 3 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Found in version:
Affected Versions:


This happens with multiple cccam providers. I am testing with their free 24 hour test lines, using the newest protocol. Same line works with dreambox receiver. No config setting changes the behavior.


cccamgate_test-errorlog.txt (1.63 KB) cccamgate_test-errorlog.txt Alpay Yildiray, 2018-05-02 23:21
cccam-free_test-errorlog.txt (34.1 KB) cccam-free_test-errorlog.txt Alpay Yildiray, 2018-05-02 23:21
cccam-full_test-errorlog.txt (7.5 KB) cccam-full_test-errorlog.txt Alpay Yildiray, 2018-05-02 23:21
bosscccam_test-errorlog.txt (11.9 KB) bosscccam_test-errorlog.txt Alpay Yildiray, 2018-05-02 23:21
tvh.log (14.7 KB) tvh.log Ricardo Rocha, 2018-11-30 16:16
a.patch (694 Bytes) a.patch Jaroslav Kysela, 2018-11-30 21:01
trace2.log (11.4 KB) trace2.log new trace Ricardo Rocha, 2018-12-01 09:15



Updated by Alpay Yildiray over 3 years ago

After a lot of fiddling with settings and the like I am still experiencing the same errors. Can anybody point me in the right direction please?


Updated by Pablo R. almost 3 years ago

'--trace cccam,descrambler' ?


Updated by Ricardo Rocha almost 3 years ago

here's a log!


Updated by Jaroslav Kysela almost 3 years ago

Add this patch (also attached) and show the logs again. It seems that tvh does not understand the reply from the server.

diff --git a/src/descrambler/cccam.c b/src/descrambler/cccam.c
index cfb3b1fe8..27a550d68 100644
--- a/src/descrambler/cccam.c
+++ b/src/descrambler/cccam.c
@@ -513,9 +513,12 @@ cccam_read_message0(cccam_t *cccam, const char *state, sbuf_t *rbuf, int timeout
   if (rbuf->sb_ptr >= msglen + 4) {
     memcpy(rbuf->sb_data, hdr, 4);
     cccam_decrypt(&cccam->recvblock, rbuf->sb_data + 4, msglen);
+    tvhtrace(LS_CCCAM, "decrypt: msglen %d", msglen + 4);
+    tvhlog_hexdump(LS_CCCAM, rbuf->sb_data, msglen + 4);
     return msglen + 4;
   } else {
     cccam->recvblock = block;
+    tvhtrace(LS_CCCAM, "decrypt failed: msglen %d sbptr %d", msglen + 4, rbuf->sb_ptr);
     return 0;

Updated by Ricardo Rocha almost 3 years ago

Small doubt... does the constant cw that I use on modified descramble file on data/conf is used also on cccam and newcamd or that only aply to capmt?


Updated by Jaroslav Kysela almost 3 years ago

It applies to the descrambling not for the client code. Anyway, this looks like a specific cccam bug - I've tested the cccam code only against the oscam so the support for other servers might be bad.


Updated by Ricardo Rocha almost 3 years ago

The traces weren't done against oscam but when I first noticed it I was testing against oscam and the cccam also doesn't work at least for me.


Updated by Ricardo Rocha almost 3 years ago

@Jaroslav Kysela still doesn't work! want me to test against oscam, or to make new traces?


Updated by Jaroslav Kysela almost 3 years ago

I probably need more complete log (with requests before the things fail). It seems that something is left in the receive buffer and the cccam packet decoding is malformed.


Updated by Pim Zandbergen almost 3 years ago

Do I understand correctly that current cccam client code was designed to use against
a local oscam server talking cccam protocol, working as an intermediate between tvh and remote cccam servers?
Why would one use cccam to talk to an oscam server, instead of the more obvious dvbapi?

Currently tvh->dvbapi->oscam->multiplecccamservers works fine for me.
It was just curiosity that lead me to test the cccam client in tvh.

Other than bypassing oscam, what could we gain by using cccam directly?


Updated by Ricardo Rocha almost 3 years ago

Jaroslav didn't said it was created only to work against oscam... he said that HE only tested agains oscam.

i will try to grab some more logs to help on debug!

Also available in: Atom PDF