Bug #5099
open
cccam protocol 2.3.0 - Ignore ECM request
Added by Alpay Yildiray almost 7 years ago. Updated over 3 years ago.
0%
Description
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.
Files
| 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 almost 7 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 Pim Zandbergen over 6 years ago
Updated by
Updated by Jaroslav Kysela over 6 years ago
Yes, show above traces. https://tvheadend.org/projects/tvheadend/wiki/Traces
Updated by Ricardo Rocha over 6 years ago
here's a log!
Updated by Jaroslav Kysela over 6 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 6 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 6 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 6 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 6 years ago
@Jaroslav Kysela still doesn't work! want me to test against oscam, or to make new traces?
Updated by Jaroslav Kysela over 6 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 6 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 6 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