Opened 6 years ago

Last modified 3 years ago

#3510 reopened defect

oscam reader cache should consider srvid as well

Reported by: lancey Owned by:
Priority: major Component: Cache-EX
Severity: Please fill in Keywords:
Cc: Sensitive: no

Description

Revision

svn trunk

Issue Description

When comparing cached ECMs, the srvid should also be considered, as there is no guaruantee the results is the same for the same ECM payload, but for different SIDs.

When the issue occurs

When you try to decode two services using the same ECM PID which use codeword calculation including SID.

How the issue is reproducable

Tune to a transponder where channels are encoded with the same ECM PID and try to decode two of them. Example transponder: 10744.00 H 22000 QPSK @ 28.2°E Astra 1N/2A/2B / Eutelsat 28A, try to decode simultaneously RTE One and RTE Two. You will get fake (non-working) codewords on the channel you get cached responses for.

A fix is attached. Maybe should be made configurable per-caid / reader.

Attachments (4)

ecm-srvid-check.diff (540 bytes) - added by lancey 6 years ago.
Compare srvid when checkinf if cache entry is valid
ecm-srvid-check-2.diff (1.2 KB) - added by lancey 6 years ago.
Revised patch
ecmmatching.patch (1.1 KB) - added by theparasol 6 years ago.
does this work too?
ecmmatching.2.patch (1.1 KB) - added by theparasol 6 years ago.
does this work too (fixed compile)?

Download all attachments as: .zip

Change History (13)

Changed 6 years ago by lancey

Attachment: ecm-srvid-check.diff added

Compare srvid when checkinf if cache entry is valid

Changed 6 years ago by lancey

Attachment: ecm-srvid-check-2.diff added

Revised patch

comment:1 Changed 6 years ago by theparasol

I'm not too sure, only way this could happen if on two seperate channels the ecm is the same but the controlword answer is different. This is a very unlikely scenario.
Even the caid check could be discarded but I presume its still there too speed things up.

Can you provide an ecm dump of both channels including the md5 hashes?
If you are right the md5 hashes should be same and controlword different.
What I presume happens is that ecmd5 is zero in cache and the controlword is delivered by csp. If ecmd5 is zero we should evaluate its csphash too. That would be a much tighter check.

Changed 6 years ago by theparasol

Attachment: ecmmatching.patch added

does this work too?

Changed 6 years ago by theparasol

Attachment: ecmmatching.2.patch added

does this work too (fixed compile)?

comment:2 Changed 6 years ago by thatfellow

I am not 100% if this is the same issue but it looks a bit too coincidental to not be related in some way.

In my situation with 0963 card & cacheex enabled
RTE One (0963:2581) clears 100% of the time but RTE Two (0963:2582) is glitchy at best..

If I remove cacheex group from clients & retest, both channels clear without fail..

If you can tell me what is the best debug level to log, I will upload logs for this scenario..
@theparasol, ecmmatching.2.patch did not have an effect on this problem...

comment:3 Changed 6 years ago by theparasol

@thatfellow: I think the cache is already defect for these two example srvid at your cache-ex peer due to same issue. only local patching wont work.

comment:4 Changed 6 years ago by tarzon

I also having the same problem and I am not sure if it has anything to do with the latested emm update

comment:5 Changed 6 years ago by lancey

Sorry, looks like i'm not getting updates about posts on this ticket...

Yes, the RTE problem is exactly this - the ECM is the same, so caching makes channels not clear fine. I can confirm the problem with RTEs is gone by using my second patch.

Tomorrow I'll set up a test environment and test the other patches suggested, then report back here the results.

comment:6 Changed 6 years ago by lancey

Example ECMs which otherwise get cached and show the problem - the only difference I see besides the SID is the table ID as well:

RTE One
=======
2013-11-27 19:59:14 | ECM | SID 0x2581 CAID: 0x0963 PID 0x0500 Table: 0x81 Length: 116 Data: 81 70 71 00 00 01 0e ca 1b 97 62 ff ff 00 81 ..
2013-11-27 19:59:14 | CW | SID 0x2581 CAID: 0x0963 CW_recv: 122 ms LastKey?: 8005 ms Data: 00 00 00 00 00 00 00 00 4e e1 44 73 58 ad 99 9e

RTE Two
=======
2013-11-27 19:59:12 | ECM | SID 0x2582 CAID: 0x0963 PID 0x0501 Table: 0x80 Length: 116 Data: 80 70 71 00 00 01 0e ca 1b 97 62 ff ff 00 81 ..
2013-11-27 19:59:12 | CW | SID 0x2582 CAID: 0x0963 CW_recv: 116 ms LastKey?: 7991 ms Data: 4e e1 44 73 58 ad 99 9e 00 00 00 00 00 00 00 00

comment:7 in reply to:  5 Changed 6 years ago by CapNCooK

Component: ReaderCache-EX
Priority: Please fill inmajor

Replying to lancey:

Sorry, looks like i'm not getting updates about posts on this ticket...

Cache should not be matched by provid/srvid, but soleley by CSPHash. Since odd/even info is not hashed, multiple same ECM (odd/even) can hit same CW and one is wrong. This problem hits oscam's cache-ex design, and also hits CSP and MCS.

In 9036 a workaround is already committed, so you should have freeze-free TV while using DVBAPI. This wont fix cache-ex transport, since it still does not contain odd/even for each CW.

For this you'll have to wait, as a joined (CSP/Oscam) solution is beeing made by developers if i understood all correctly.

See: http://www.streamboard.tv/wbb2/thread.php?threadid=39678

comment:8 Changed 5 years ago by Deas

Resolution: expired
Status: newclosed

comment:9 Changed 3 years ago by hacktavist

Resolution: expired
Status: closedreopened

This is still happening. I've tried using the patch but oscam-ecm.c has changed so much that I can't see where to add the modified code.

It has nothing to do with cache-ex as i'm not using it

Note: See TracTickets for help on using tickets.