Bug #5099

cccam protocol 2.3.0 - Ignore ECM request

Added by Alpay Yildiray about 5 years ago. Updated over 1 year 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 about 5 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. over 4 years ago

'--trace cccam,descrambler' ?


Updated by Ricardo Rocha over 4 years ago

here's a log!


Updated by Jaroslav Kysela over 4 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 over 4 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 over 4 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 over 4 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 over 4 years ago

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


Updated by Ricardo Rocha over 4 years ago


Updated by Jaroslav Kysela over 4 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 over 4 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 over 4 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!


Updated by Chris F over 1 year ago

Did this ever get resolved ?

Also available in: Atom PDF