Opened 7 years ago
Closed 4 years ago
#4359 closed defect (fixed)
NDS CWs are dropped when connected to real CCCam servers
Reported by: | ua2Ahfieghah | Owned by: | |
---|---|---|---|
Priority: | blocker | Component: | General |
Severity: | medium | Keywords: | |
Cc: | Sensitive: | no |
Description
Revision
since revision 10005
Issue Description
NDS (e.g. caid 0963, 09C4, 098C) CWs are dropped due to CW half check when
operating as CCCAM client and connected to CCCAM server
When the issue occurs
no picture
How the issue is reproducable
when connected to CCCAM server (I face this issue with every public server available), I am receiving CWs, of following type:
0: XX XX XX XX XX XX XX XX 00 00 00 00 00 00 00 F0
and
1: 00 00 00 00 00 00 00 00 XX XX XX XX XX XX XX XX
the case 0: is currently always rejected by OSCAm as the code expects
that last octet is 00
this is also the case when connected to a OSCAM server operating as CCCAM server
I have already verified (see patch blow), when relaxing the check and accepting in last octet an 0xF0, the channels become "clear".
--- a/oscam-ecm.c +++ b/oscam-ecm.c @@ -2637,8 +2637,15 @@ uint8_t checkCWpart(uchar *cw, int8_t part) { uint8_t eo = part ? 8 : 0; int8_t i; - for(i = 0; i < 8; i++) + for(i = 0; i < 7; i++) if(cw[i + eo]) { return 1; } + if(part) + { + if(cw[i+eo] && cw[i+eo] != 0xF0) { return 1; } + } + else if(cw[i+eo]) + return 1; + return 0; }
The attached log file was created when applying following (for debugging purposes) patch additionally:
--- a/oscam-chk.c +++ b/oscam-chk.c @@ -1036,6 +1036,9 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw) int8_t part1 = checkCWpart(cw, 0); int8_t part2 = checkCWpart(cw, 1); + char tmp[16*3+1]; + cs_log("er->caid=%04X, cw=%s", er->caid, cs_hexdump(1, cw, 16, tmp, sizeof(tmp))); + //check for correct half cw format if(part1 && part2){ return 0;
Attachments (1)
Change History (12)
by , 7 years ago
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Another reason why the CW should be patched is to be able to reshare the CWs with a OSCAM version which include the half CW check enforcement and which does not yet include the fix. Otherwise such a version would "drop" all those CWs. When the CW is patched on the other hand, only the resharing server must include the fix. This means we would not need to wait for the receiver image to include a newer OSCAM version.
comment:3 by , 7 years ago
Thanks for your patches i'll test.
i already posted this issue in the past but i got ignored, at least seems you got exactly where is the issue.
http://www.streamboard.tv/oscam/ticket/4195
comment:4 by , 7 years ago
I can confirm that the proposed patch on oscam-ecm.c restore the same correct behavior of builds <= 10005. The CWs coming from the CCcam servers I tested are not discharged with this fix. Please, consider its inclusion.
comment:5 by , 7 years ago
I can also confirm the the patch oscam-chk.c is working very well. so maybe it is possible to implement it. maybe it is also possible to enable/disable it via webif so it will not disturb something else - but i did not find anything till now, which is not running with this patch anymore.
I'm also very surprised that this "bug" is not already fixed till version 10006, because not only me is struggleing for a while with this problem and costs a lot of time to test verious oscam versions (I already now the answer - IT IS NOT AN OSCAM BUG...)
maybe some of the developer can reply to this ticket?
by the way - very good job ua2Ahfieghah !!! - well done :-)
comment:6 by , 7 years ago
Is there someone that could explain the origin of this spurious 0xF0 byte at the end of such CWs? Is a kind of anticascading counter-measure or a broken server? I've verified that this spurious value was present with revision 10005 but (for a bug fixed in 10006?) it was ignored (read, not checked).
comment:7 by , 7 years ago
Actually I cannot explain. I can only say that the CW check for NDS never worked for me with any version with these CCCam servers. Previously (prior revision 10005), the CW check for NDS actively had to be activated. Thus the check was no real issue. Now, on the other hand, this check is enforced and there exists no way to deactivate it. Thus since version 10005, I was not able to use any OSCAM version any longer. With this patch (the one changing oscam-chk.c), I do not face any issue any more but I cannot guarantee that the 0xF0 value will change into another value in the future as noone reading here knows the root cause of the value or at least is not replying. Can we take this patch anyway in and in case the value changes at some point in the future adapt the code further? Would this be an option?
comment:8 by , 6 years ago
From most recent commit I could see that you are trying to fix oscam working with MCS serers. Actually I do not have any issues as I am using since raising this ticket my patch. You could consider applying this patch as well. Here again the patch for your reference.
--- a/oscam-chk.c +++ b/oscam-chk.c @@ -1033,11 +1033,16 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw) { if(is_halfCW_er(er) && cw){ + uchar cw15 = cw[15]; + if(get_odd_even(er) == 0x80 && cw[15] == 0xF0) + cw[15] = 0; + int8_t part1 = checkCWpart(cw, 0); int8_t part2 = checkCWpart(cw, 1); //check for correct half cw format if(part1 && part2){ + cw[15] = cw15; return 0; } @@ -1051,6 +1056,7 @@ int8_t chk_halfCW(ECM_REQUEST *er, uchar *cw) return 1; } + cw[15] = cw15; return 0; //not correct swapped cw }else
comment:9 by , 6 years ago
I can confirm that the patch is working well. Thank you @ua2Ahfieghah
Why after 14 months, the fix is not yet applied ?
comment:10 by , 6 years ago
comment:11 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Another way of fixing the problem would be to apply the following patch instead:
This would have the advantage that in case replies from OSCAM server (with CCCAM protocol) and CCCam server are available at the same time, both replies can be used together in a DOUBLE CW check. This place is surely not the perfect place to do this kind of "patching" of the CW reply. Unfortunately I do not know the code that well that I could easily find a better location.