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)
Change History (47)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 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.
comment:4 by , 11 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:5 by , 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:7 by , 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.
comment:10 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
emm write works here (always use latest svn), so closed
comment:11 by , 11 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
rev 8891 no EMM's written, it's not for forum, it's an error
comment:12 by , 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 , 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.
comment:14 by , 11 years ago
Bullshit, the most use cards are S02 and I02(I12) and no AU ...
Your special cards ... LOL
comment:15 by , 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!
comment:16 by , 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)
comment:17 by , 11 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
comment:18 by , 11 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
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..
comment:19 by , 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 , 11 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
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 , 11 years ago
I have the same problem with #8895,no emm's being sent to the card (0963 card)
comment:22 by , 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 , 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 , 11 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
comment:25 by , 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 , 11 years ago
could the same be done by selecting 2,64,128 in switch debug on the webif?
by , 11 years ago
Attachment: | bigemmfixv2.patch added |
---|
most important component was missing in the v1 patch -> corrected
by , 11 years ago
Attachment: | bigemmv3.patch added |
---|
global emms incorrect filtered on share readers -> fixed
by , 11 years ago
Attachment: | bigemmv4.patch added |
---|
Get rid of nullfree... filters only need recreated on physical card change
comment:29 by , 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 , 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 , 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 , 11 years ago
Attachment: | bigemmv6.patch added |
---|
betatunnels and normal irdeto tunnels, just start them both!
comment:32 by , 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 , 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.
comment:34 by , 11 years ago
Yes, that's the way forward. A solution to the real problem, not introducing magic.
comment:35 by , 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.
by , 11 years ago
Attachment: | providfixv1.patch added |
---|
provid is 3 bytes, dont use 4 + cccam au enhencement
comment:36 by , 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:38 by , 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?
by , 11 years ago
Attachment: | provid_v2.patch added |
---|
provid in oscam-chk, cccam ua data provid + shifting fix
comment:39 by , 9 years ago
Resolution: | → expired |
---|---|
Status: | reopened → closed |
http://www.streamboard.tv/oscam/changeset/8890