Opened 11 years ago

Closed 9 years ago

#3422 closed defect (expired)

rev 8887/8888 no EMM's written

Reported by: Netview Owned by:
Priority: Please fill in Component: ! Please select...
Severity: Please fill in Keywords:
Cc: Sensitive: no

Description

something is wrong with AU!
8886 was writing EMM's successfully but 8888/8889 didn't.

EMM error EMM written
UK / G / S / UQ UK / G / S / UQ

G09 stapi 1 0 / 0 / 0 / 0 0 / 0 / 0 / 0

I'm using a G09 card (caid 09C7)on a sh4/stapi device (octagon 1028P) pmt_mode=5.


Attachments (8)

bigemmfixv1.patch (28.1 KB ) - added by theparasol 11 years ago.
emm update network readers
bigemmfixv2.patch (29.5 KB ) - added by theparasol 11 years ago.
most important component was missing in the v1 patch -> corrected
bigemmv3.patch (29.6 KB ) - added by theparasol 11 years ago.
global emms incorrect filtered on share readers -> fixed
bigemmv4.patch (33.4 KB ) - added by theparasol 11 years ago.
Get rid of nullfree... filters only need recreated on physical card change
bigemmv5.patch (34.2 KB ) - added by theparasol 11 years ago.
release emm filters on card init / eject
bigemmv6.patch (36.5 KB ) - added by theparasol 11 years ago.
betatunnels and normal irdeto tunnels, just start them both!
providfixv1.patch (6.5 KB ) - added by theparasol 11 years ago.
provid is 3 bytes, dont use 4 + cccam au enhencement
provid_v2.patch (3.3 KB ) - added by theparasol 11 years ago.
provid in oscam-chk, cccam ua data provid + shifting fix

Download all attachments as: .zip

Change History (47)

comment:2 by Netview, 11 years ago

Resolution: fixed
Status: newclosed

comment:3 by twintool, 11 years ago

The issue exists still for me. I updated a ~week old version.
I use the latest version OSCAM 1.20-unstable_svn build r8891.

My setup:

2 cards behind load balancer with au enabled cccam client.

Last edited 11 years ago by twintool (previous) (diff)

comment:4 by twintool, 11 years ago

Resolution: fixed
Status: closedreopened

comment:5 by pr2, 11 years ago

Have you tried to change this parameter in the user configuration:

http://www.streamboard.tv/wiki/OSCam/en/Config/oscam.user#emmreassembly

comment:6 by twintool, 11 years ago

I try this later and give you feedback.

comment:7 by twintool, 11 years ago

I did set the parameter "emmreassembly = 0" for both readers without luck.
Surprisingly the ~week old version did work. I did no changes to the config files.

If you need more information, please let me know.
Thanks.

Last edited 11 years ago by twintool (previous) (diff)

comment:8 by twintool, 11 years ago

With Version "OSCAM 1.20-unstable_svn build r8832" emm write works.

comment:9 by newbeginner2, 11 years ago

the emmreassembly is an user parameter, not reader parameter.

comment:10 by ni hao, 11 years ago

Resolution: fixed
Status: reopenedclosed

emm write works here (always use latest svn), so closed

Last edited 11 years ago by ni hao (previous) (diff)

comment:11 by hapeba, 11 years ago

Resolution: fixed
Status: closedreopened

rev 8891 no EMM's written, it's not for forum, it's an error

comment:12 by BigGyros, 11 years ago

EMMs are working with all my cards (r8891) the only 'problem' is that if you have multiple cards only one of them will receive shared and unique emms without changing channel. and i am not sure if this ever has worked. so this topic should be discussed in forum!!!

comment:13 by ni hao, 11 years ago

Exactly !!! Here the same, all cards no problem with emm's (seca2, seca3, cryptoworks, viaccess, betacrypt). Also i have soms identical cards and with those cards also no problem with emm's. So discuss in forum and inform which cards have no emm's written.

Last edited 11 years ago by ni hao (previous) (diff)

comment:14 by hapeba, 11 years ago

Bullshit, the most use cards are S02 and I02(I12) and no AU ...
Your special cards ... LOL

comment:15 by BigGyros, 11 years ago

it's just useless to talk to you my S02 are working! and you can see in the forum that other cards are working too! if your cards are really not working post logs or send them to devs or noone will care!

Last edited 11 years ago by BigGyros (previous) (diff)

comment:16 by ni hao, 11 years ago

All S02 cards working good here, i have 3x S02 seperated, so different OScam runnng, All cards AU updated, so working good. Open thread in forum and discuss.

BTW use at least r8892 for having max. EMM output in log and log with "-d192 -S" (-S for displaying sensitive data) and send the log by PM to theparasol (because of sensitive data, which should not be published at forum)

Last edited 11 years ago by ni hao (previous) (diff)

comment:17 by ni hao, 11 years ago

Resolution: worksforme
Status: reopenedclosed

comment:18 by thatfellow, 11 years ago

Resolution: worksforme
Status: closedreopened

This issue is still not sorted in latest version #8894. EMM's still not getting logged or forwarded to cards. I have had to revert to last working (For me) #8825 and all is well.. I have 3x 0963 card locally in the same instance of oscam (only 1 set to receive EMM's). The same oscam configs that work in #8825 do not in recent versions..

Also worth mentioning that I am compiling oscam with modern webif.
I would not think this has any bearing on the issue but I would like Netview twintool & hapeba to confirm that they are or are not using modern webif..

Last edited 11 years ago by thatfellow (previous) (diff)

comment:19 by lattjo, 11 years ago

Re-opening a ticket without a log is a waste of time for everyone.
Do you really think every developer has access to every card?!
And hapeba's comment is as bright as usual. He seems to think he is representative for all users and everyone has the same card as he and therefor he never feel the need to provide any useful input, like a log.

comment:20 by drno, 11 years ago

Resolution: worksforme
Status: reopenedclosed

Same thing here. All cards working as expected on mipsel and linux with modern webif.
I fully agree with ni_hao and lattjo, use the forum to discuss your specific issue!

comment:21 by ibcus, 11 years ago

I have the same problem with #8895,no emm's being sent to the card (0963 card)

comment:22 by lattjo, 11 years ago

And where are the logs?
I do not claim there is no problem, but it won't be solved by complaining alone, logs, logs and more logs are needed.

But since it's an EMM problem and a log will reveal sensitive information it could be a good idea to send a PM on the streamboard forum to the developer who introduced the problem.

comment:23 by twintool, 11 years ago

Yesterday i compiled the latest release r8895 and set the parameter "emmreassembly = 0" for the au enabled user. Until know emm write does not work.

In my logfiles (without debug) is nothing suspicious. If debug logs needed, i need to know how to compile the software and start the service in debug mode.

If any other information is needed, i will provide it.

Thanks for your help.

comment:24 by twintool, 11 years ago

Resolution: worksforme
Status: closedreopened

comment:25 by lattjo, 11 years ago

start oscam with parameter -d194 to get debug info for EMM as well as dvbapi. No need to do any compiling.

comment:26 by ibcus, 11 years ago

could the same be done by selecting 2,64,128 in switch debug on the webif?

by theparasol, 11 years ago

Attachment: bigemmfixv1.patch added

emm update network readers

by theparasol, 11 years ago

Attachment: bigemmfixv2.patch added

most important component was missing in the v1 patch -> corrected

comment:27 by ibcus, 11 years ago

I'll try it now, v1 didn't work but I guess you know that now

by theparasol, 11 years ago

Attachment: bigemmv3.patch added

global emms incorrect filtered on share readers -> fixed

comment:28 by ibcus, 11 years ago

trying v3

by theparasol, 11 years ago

Attachment: bigemmv4.patch added

Get rid of nullfree... filters only need recreated on physical card change

by theparasol, 11 years ago

Attachment: bigemmv5.patch added

release emm filters on card init / eject

comment:29 by ibcus, 11 years ago

Just compiled again with v4 patch.
v5 popped up as I was typing, I'll compile with that now.

comment:30 by ibcus, 11 years ago

I don't normally have debug level 194 so have never seen this before, is it normal?

Using CCcam connected to Oscam server 8899.

cccam(s) testuser: EMM Request received!

[videoguard2] EMM: caid 0963 has no provider
emm: <snip>

card1 [videoguard2] EMM: caid 0963 has no provider
card1 [videoguard2] EMM: UNIQUE
card1 [videoguard2] EMM: emm skipped, do_simple_emm_filter() returns invalid

comment:31 by theparasol, 11 years ago

As the hexserial of your card differs from the hexserial in the emm packet the provider send the unique emm isnt applied and thus invalid.

by theparasol, 11 years ago

Attachment: bigemmv6.patch added

betatunnels and normal irdeto tunnels, just start them both!

comment:32 by lattjo, 11 years ago

Starting betatunnel and normal at the same time might be a really good idea. It should be tested separately.
As for the rest, I have some ideas I plan to test tomorrow

comment:33 by theparasol, 11 years ago

rev 8901 has been reported working for camd35 protocol with multiple cards in the server.
It works due to fact that camd35 already has some code to change hexserial and provid periodical. dvbapi module is now rechecking the reader emm filters every 30 seconds.
Any change in rdr->hexserial rdr->provid and additional dvbapi emmfilters will be started. If this happens previous SA/UQ emm filters of the reader are gone so checking them @client is not a good idea (will abort with invalid!). However the dvbapi stream filters do filter the correct emms so there isnt any need to recheck them again. Any data from such a filter should be correct in first place.
Now the emms are forwared to network reader and the server having the cards local has still correct reader emm filters and will validate and feed correct local card with emms being send.

The cccam module is lacking this code. So if we find a way to implement similar code in CCcam module that protocol can be used too to update multiple cards.
If you ask me: what needs to be done is that cccam share is changing hexserial and provid regulary. Dvbapi will start additional filters for it, emms will be send and the server with the cards will check the emm and serve the right card with correct emms.

Last edited 11 years ago by theparasol (previous) (diff)

comment:34 by lattjo, 11 years ago

Yes, that's the way forward. A solution to the real problem, not introducing magic.

comment:35 by theparasol, 11 years ago

I'm a bit puzzled. Provid = 3 bytes, but oscam code uses sometimes 4, 2 or 3.
Thats not sound. So I scanned through the code and replaced all i2b and b2i commands with 3 bytes provid.

As I dont know why this has been done (on purpose or just coding error) I made a testpatch to correct this situation.
In patch is a cccam au data enhencement added too.

Last edited 11 years ago by theparasol (previous) (diff)

by theparasol, 11 years ago

Attachment: providfixv1.patch added

provid is 3 bytes, dont use 4 + cccam au enhencement

comment:36 by MadMaxx, 11 years ago

I will remind you about an older, still open ticket, for cccam-proxy emm updates:

int32_t get_UA_ofs(uint16_t caid) {
        int32_t ofs = 0;
        switch (caid >> 8) {
        case 0x05: //VIACCESS:
        case 0x0D: //CRYPTOWORKS:
//                ofs = 1;
//                break;
        case 0x4B: //TONGFANG:
        case 0x09: //VIDEOGUARD:
        case 0x0B: //CONAX:
        case 0x18: //NAGRA:
        case 0x01: //SECA:
        case 0x00: //SECAMANAGMENT:
        case 0x17: //BETACRYPT
        case 0x06: //IRDETO:
                ofs = 2;
                break;
        }
        if (caid == 0x5581 || caid == 0x4AEE) //BULCRYPT:
                ofs = 0;
        return ofs;
}

http://www.streamboard.tv/oscam/ticket/3297

this is still needed for correct "shifting" when used with oscam<->oscam and cccam-ext.

comment:37 by theparasol, 11 years ago

ok, forget about this provid patch. "real cards use 4 bytes provid"

comment:38 by theparasol, 11 years ago

reading some code and I think this should be corrected in oscam-chk.c (see v2 patch)
and added some code to cccam UA data to add provids of the cards even if no hexserials are communicated.

added shifting fix of MadMaxx

Can someone test/report/give some feedback on these changes?

Last edited 11 years ago by theparasol (previous) (diff)

by theparasol, 11 years ago

Attachment: provid_v2.patch added

provid in oscam-chk, cccam ua data provid + shifting fix

comment:39 by Deas, 9 years ago

Resolution: expired
Status: reopenedclosed
Note: See TracTickets for help on using tickets.