#3198 closed defect (fixed)
Irdeto UNIQUE EMM to provider is filtered out by irdeto_get_emm_filter
Reported by: | malakudi | Owned by: | |
---|---|---|---|
Priority: | major | Component: | Card support |
Severity: | medium | Keywords: | irdeto unique emm provider |
Cc: | Sensitive: | no |
Description
Revision
8427
Issue Description
Irdeto UNIQUE EMM to provider cannot be written to card because it is filtered out by irdeto_get_emm_filter
When the issue occurs
Whenever a UNIQUE EMM to provider (not hex serial) is sent, it cannot be written. It is skipped with message:
EMM: emm skipped, emm_filter() returns invalid
How the issue is reproducable
Whenever there is a UNIQUE EMM to provider.
Attached patch resolves the issue. I commented out shared emm to hex serial, as far as I know this never happens in Irdeto. If it does, then filter structure is not enough, it holds 10 records but 11 are needed (1 global, 1 unique hex serial, 4 unique provider serial, 1 shared hex serial, 4 shared provider serial).
Attachments (2)
Change History (46)
by , 11 years ago
Attachment: | irdeto_unique_emm_to_provider.diff added |
---|
comment:1 by , 11 years ago
This bug used to affect only DVBAPI, but since some revisions, get_emm_filter is used outside DVBAPI too.
comment:2 by , 11 years ago
Looks OK (I'm do not know irdeto and I don't know if the patch is logically correct, but if it is tested I would apply it). Why don't you just remove the wrong shared case?
comment:3 by , 11 years ago
I didn't remove it because I am not 100% sure that shared EMM on hex serial is not available in some excotic irdeto version. I am 99.9% sure though, since I've never seen Irdeto group addressing on hex serial.
Leave it commented out for a while, if noone complains then we can remove it. There is another commented out block, an EMM_GLOBAL where it matches first byte of hex serial, I also haven't seen that in my life!
Patch has been tested and works fine, doesn't break anything too.
comment:5 by , 11 years ago
I don't know if its configuration issue but I am receiving this message now, it was ok before r8431:
2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] EMM: caid 0604 has no provider 2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] EMM: Entered irdeto_get_emm_type ep->emm[3]=02 2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] EMM: SHARED l = 2 ep = ### rdr = ### base = 00 2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] irdeto_get_emm_filter: could not start all emm filter 2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] EMM: emmtype shared. Reader serial ################. 2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] EMM: emm UA/SA: ################. 2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] EMM: emm found in cache: count 16 rewrite 0 2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] EMM: emm found in cache: count 1 rewrite 0
without debug log, constant message repeating:
2013/02/26 03:07:59 60B4B0 c raspi-camd35 [camd35] irdeto_get_emm_filter: could not start all emm filter
comment:6 by , 11 years ago
Well it seems that your filters are working. As malakudi wrote, there is a limit of 10 filters which are not enough in case of irdeto with many provider ids.
comment:7 by , 11 years ago
module-dvbapi have this:
#define MAX_FILTER 24
looks like we might be using more filters?
BTW: The whole emm filter setup is quite bad. We pass uint8_t *data to get_emm_filter() callbacks without passing the length that this can hold :(
comment:8 by , 11 years ago
Afair, the max filters come from the receiver hardware or driver. If you just raise that value, it might give other problems because the receivers don't support so many filters.
I'm wondering more why an incoming emm should start a new emm filter...
comment:9 by , 11 years ago
Other Global & Shared EMMs for Irdeto are also broken, since the get_emm_filter has been added.
I rem out the the whole lot of the do_simple_emm_filter
30 odd lines starting from here..
static int8_t do_simple_emm_filter(struct s_reader *rdr, struct s_cardsystem *cs, EMM_PACKET *ep)
&
/*
if (cs && cs->get_emm_filter) {
if (!do_simple_emm_filter(aureader, cs, ep)) {
rdr_debug_mask(aureader, D_EMM, "emm skipped, emm_filter() returns invalid");
emmnok++;
continue;
}
}
*/
And
from Irdeto.c
/*
if (ep->emm[0] != 0x82) {
rdr_debug_mask(reader, D_EMM, "Invalid EMM: Has to start with 0x82, but starts with %02x!", ep->emm[0]);
return ERROR;
}
*/
&
*
if(dataLen < 7 dataLen > (int32_t)sizeof(ep->emm) - 6 dataLen > (int32_t)sizeof(cta_cmd) - 9) { rdr_debug_mask(reader, D_EMM, "dataLen %d seems wrong, faulty EMM?", dataLen);
return ERROR;
}
*/
&
/*
if(dataLen < 1 dataLen > (int32_t)sizeof(ep->emm) - 5 - l dataLen > (int32_t)sizeof(cta_cmd) - (int32_t)sizeof(sc_EmmCmd) - ADDRLEN) { rdr_debug_mask(reader, D_EMM, "dataLen %d seems wrong, faulty EMM?", dataLen);
return ERROR;
}
*/
Otherwise the replys coming back are bad.
The filter is definately broken and I dont know how to fix. Reming these out fixes most my problem with my irdeto2 cards and a few mates in other countrys, their emms just dont show in the webif as been written.
Davo
comment:10 by , 11 years ago
get_emm_filter was used for dvbapi client to avoid sending (as a client) more EMMs than needed. Then this function was applied outside dvbapi too. irdeto do_emm already has checks for such things, so we are just doublechecking. 10 filters is not enough for irdeto if providers are more than 4.
comment:11 by , 11 years ago
For Ird2 when using NewCS to read, CCcam client can send EMM to update the card
But not with Oscam. Serial not sent.
Mostly need Mgcamd to update.
follow-up: 15 comment:12 by , 11 years ago
I can confirm for an ORF ICE-Card (CAID 0648) in Irdeto Mode with active ORF, AustriaSAT and HDAustria, that the filter is a problem right now.
I still use mgcamd 1.38 for EMM-updates, and i get in the latest trunk loglines like this:
2013/02/27 17:38:00 1022AA0 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/27 17:38:00 E991D8 r orf-ice-irdeto [irdeto] dbox2 emmtype=shared, len=63, idx=75, cnt=1: written (54 ms) 2013/02/27 17:41:52 1022AA0 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/27 17:41:52 E991D8 r orf-ice-irdeto [irdeto] dbox2 emmtype=global, len=29, idx=76, cnt=1: written (40 ms) 2013/02/27 17:41:52 1022AA0 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/27 17:41:53 1022AA0 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/27 17:41:53 E991D8 r orf-ice-irdeto [irdeto] dbox2 emmtype=global, len=77, idx=77, cnt=1: written (65 ms) 2013/02/27 17:41:53 E991D8 r orf-ice-irdeto [irdeto] dbox2 emmtype=global, len=77, idx=78, cnt=1: written (57 ms) 2013/02/27 17:41:53 1022AA0 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/27 17:41:53 E991D8 r orf-ice-irdeto [irdeto] dbox2 emmtype=global, len=77, idx=79, cnt=1: written (56 ms)
comment:13 by , 11 years ago
i use a S02 (1702) Sky German Card (BetaCrypt) and since #8431 no shared EMM was written , but the card need shared EMM´s for updating the date ... unique EMM´s works but the card need this only to activate after this , updates need only shared EMM´s...
server and client #8431
unique ok but no shared...
2013/02/27 14:44:01 2AE0E0E8 c cardserver [cs378x] EMM: caid 1702 has no provider 2013/02/27 14:44:01 2AE0E0E8 c cardserver [cs378x] EMM: Entered irdeto_get_emm_type ep->emm[3]=d3 2013/02/27 14:44:01 2AE0E0E8 c cardserver [cs378x] EMM: UNIQUE l = 3 ep = {86 B0 } rdr = {86 B0 } base = 1a 2013/02/27 14:44:01 2AE0E0E8 c cardserver [cs378x] EMM: emmtype unique. Reader serial ################. 2013/02/27 14:44:01 2AE0E0E8 c cardserver [cs378x] EMM: emm UA/SA: ################. 2013/02/27 14:44:01 2AE0E0E8 c cardserver [cs378x] EMM: emm found in cache: count 1 rewrite 1 2013/02/27 14:44:01 2AE0E0E8 c cardserver [cs378x] EMM: emm is being sent to reader 2013/02/27 14:44:02 2AE0E0E8 c DM8000 (1702&000000/0000/0008/93:6EB13A232A35BD67EB23E66938A9910C): found (905 ms) by cardserver - Sky Comedy
shared ok
2013/02/27 15:08:03 5904E8 c cardserver [cs378x] EMM: caid 1702 has no provider 2013/02/27 15:08:03 5904E8 c cardserver [cs378x] EMM: Entered irdeto_get_emm_type ep->emm[3]=d2 2013/02/27 15:08:03 5904E8 c cardserver [cs378x] EMM: SHARED l = 2 ep = ### rdr = ### base = 1a 2013/02/27 15:08:03 5904E8 c cardserver [cs378x] EMM: emmtype shared. Reader serial ################. 2013/02/27 15:08:03 5904E8 c cardserver [cs378x] EMM: emm UA/SA: ################. 2013/02/27 15:08:03 5904E8 c cardserver [cs378x] EMM: emm is being sent to reader 2013/02/27 15:08:03 58ED60 p cardserver [cs378x] DM8000 emmtype=shared, len=139, idx=0, cnt=1: sent (0 ms) 2013/02/27 15:08:11 5904E8 c DM8000 (1702&000000/0000/0008/93:A24D92E4DE1F9918E839C2FC360A1790): found (793 ms) by cardserver - Sky Comedy
comment:14 by , 11 years ago
OK, so it seems shared to hex serial is used in betacrypt and need to be reenabled (the block I commented).
I suggest to temporary disable completely the irdeto_get_emm_filter since the structure can't handle all cases and discuss what would be the best solution - what we want to achieve.
comment:16 by , 11 years ago
Replying to malakudi:
How many providers are there for ORF ICE-Card (0648) ?
5: 000004,000008,000010,00000C,000000
comment:17 by , 11 years ago
ORF ICE-Card uses actual 3 Providers:
04 = ORF/ATV/ATV2/Puls4 (Provider 1)
08 = HD Austria (only in Irdeto Mode) (Provider 2)
0C = n.c. (Provider 3)
10 = Austria Sat (Provider 4)
comment:18 by , 11 years ago
fixed shared EMM´s by myself
reader-irdeto.c at line 673 and 682 remove /* and */
old:
/* filter[idx++]=EMM_SHARED; filter[idx++]=0; filter[idx+0] = 0x82; memset(filter+idx+2+16, 0xFF, 2); filter[1]++; idx += 32; */
new:
filter[idx++]=EMM_SHARED; filter[idx++]=0; filter[idx+0] = 0x82; memset(filter+idx+2+16, 0xFF, 2); filter[1]++; idx += 32;
after this , shared EMM´s work again on my S02
2013/02/27 19:07:44 58DD60 p cardserver [cs378x] DM800 emmtype=shared, len=139, idx=0, cnt=1: sent (1 ms) 2013/02/27 19:07:49 58DD60 p cardserver [cs378x] DM800 emmtype=shared, len=139, idx=1, cnt=1: sent (1 ms)
follow-up: 20 comment:19 by , 11 years ago
with trunk #8443
still problems with ORF-ICE card in irdeto-mode & mgcamd 1.38:
2013/02/28 16:38:01 1680180 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/28 16:38:01 14D7A88 r orf-ice-irdeto [irdeto] dbox2 emmtype=shared, len=63, idx=3, cnt=1: written (54 ms) 2013/02/28 16:38:47 1680180 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/28 16:38:47 14D7A88 r orf-ice-irdeto [irdeto] dbox2 emmtype=shared, len=63, idx=4, cnt=1: written (63 ms)
comment:20 by , 11 years ago
Replying to MadMaxx:
with trunk #8443
still problems with ORF-ICE card in irdeto-mode & mgcamd 1.38:
2013/02/28 16:38:01 1680180 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/28 16:38:01 14D7A88 r orf-ice-irdeto [irdeto] dbox2 emmtype=shared, len=63, idx=3, cnt=1: written (54 ms) 2013/02/28 16:38:47 1680180 c orf-ice-irdeto [irdeto] irdeto_get_emm_filter: could not start all emm filter 2013/02/28 16:38:47 14D7A88 r orf-ice-irdeto [irdeto] dbox2 emmtype=shared, len=63, idx=4, cnt=1: written (63 ms)
i don´t see the problem here ... shared EMM´s was written , the only prob i see is the "could not start all emm filter" but this is only a message ...
comment:21 by , 11 years ago
Ok the problem here is that we might detect an emm as invalid even if it is valid just because of that limit. The limit at this place (when called from do_simple_emm_filter function) is more or less artificial because we have a variable named dmx_filter which we just sized so big; it is not hardware dependent here. Where it is hardware dependent is when we call the same function from dvbapi_start_emm_filter function.
comment:22 by , 11 years ago
Different hardware filters are for different PIDs, aren't they? Or we apply a hardware filter for a specific 'match' of emm?
comment:23 by , 11 years ago
We need to filter the emms in hardware as we would get way too many otherwise resulting in a tremendous load. Thus, we are setting filters on the emm pids telling what emms should be delivered to the camd. The amount of these filters is limited by hardware but we save the additional ones in a list and cycle through them (at least since a few weeks now) about every minute or so.
comment:24 by , 11 years ago
Excuse my ignorance but why we need hardware filters for that?
If a thread attaches to emm pid and filters in software, it will take too much cpu?
For example, dvbsnoop -npd -ph 2 pid | grep_for_related_emms doesn't take that much cpu (about 5% on a DM800) . And this is not optimal, C code would be faster.
comment:25 by , 11 years ago
5% in the transponder you have tested. There are services that send thousands of EMMs per second and not using the filters that dvbapi provides would be a very bad thing.
comment:26 by , 11 years ago
OK, I understand now.
@MadMaxx: Can you send an output of the list of providers and chids on your ORF-ICE card? Without sensitive information (-S ommited)
comment:27 by , 11 years ago
Here it comes...
2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [mouse] Hist. Bytes: TÄ 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [mouse] detect irdeto card 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [mouse] caid: 0648, acs: 6.08, country code: AUT 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [mouse] providers: 4, ascii serial: 0123456789, hex serial: AABBCC, hex base: 1E 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [mouse] active providers: 4 (aabbff,aabbff,001b00,aabbff) 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [mouse] found card system irdeto 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] entitlements for provider: 1, id: AABBFF 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 0001, date: 2013/03/01 - 2013/11/06 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 7FFB, date: 2013/03/01 - 2013/03/31 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 0002, date: 2013/03/01 - 2013/11/06 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: FFE0, date: 2013/03/01 - 2013/03/31 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: FFD8, date: 2013/03/01 - 2013/04/30 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 7FF7, date: 2013/03/01 - 2013/03/11 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] entitlements for provider: 2, id: AABBFF 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: FFE1, date: 2013/01/20 - 2013/02/28 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 0015, date: 2013/01/20 - 2013/03/25 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 7FFA, date: 2013/01/20 - 2013/02/28 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: FFD9, date: 2013/01/20 - 2013/03/25 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] entitlements for provider: 4, id: AABBFF 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: FFE3, date: 2013/01/20 - 2013/02/28 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 002A, date: 2013/01/20 - 2013/03/25 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 002B, date: 2013/01/20 - 2013/03/25 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 002C, date: 2013/01/20 - 2013/03/25 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 002D, date: 2013/01/20 - 2013/03/25 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: 7FF8, date: 2013/01/20 - 2013/02/28 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] chid: FFDB, date: 2013/01/20 - 2013/03/25 2013/03/01 13:30:04 14D7A88 r orf-ice-irdeto [irdeto] ready for requests
As you can see: 4 Bytes from the HEX-Serial are EQUAL to the Irdeto-Providers 1,2 and 4
comment:28 by , 11 years ago
OK, I can apply two fixes here.
1st fix: If all used providers are the same (as it seems to be here) only add one filter.
2nd fix: If provider doesn't have entitlements (chids), then skip it too. Or if provider has 1st and 3rd byte 00, also skip it. Some cards have ffffff for unused providers, others have 00xx00 (like yours). ffffff are skipped.
We could also apply shared to hex serial only for betacrypt, since it doesn't seem to be used anywhere else.
Can you test this patch?
--- reader-irdeto.c 2013-03-01 15:47:51.000000000 +0200 +++ reader-irdeto.c.new 2013-03-01 15:47:42.000000000 +0200 @@ -683,7 +683,7 @@ int32_t i; for(i = 0; i < rdr->nprov; i++) { - if (rdr->prid[i][1]==0xFF) + if (rdr->prid[i][1]==0xFF || (rdr->prid[i][1]==0x00 && rdr->prid[i][3]==0x00)) continue; filter[idx++]=EMM_UNIQUE; @@ -697,6 +697,11 @@ filter[1]++; idx += 32; + if (filter[1]>=10) { + rdr_log(rdr, "irdeto_get_emm_filter: could not start all emm filter"); + break; + } + filter[idx++]=EMM_SHARED; filter[idx++]=0; filter[idx+0] = 0x82;
comment:29 by , 11 years ago
Because i have no "real" Irdeto2-Card, only ORF-ICE card, -I asume- that all Irdeto/Cryptoworks-Cards use the same ProviderIDs, but i´am not sure.
To be sure the patches don´t affect real Irdeto2-only cards it can make sense to limit
the fixes to CAID 0648 and maybe other Combi-Cards based on "ICE" ?
comment:30 by , 11 years ago
I have here another sample, with -ONLY- ORF on ICE-Card:
2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [mouse] Hist. Bytes: TÄ 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [mouse] detect irdeto card 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [mouse] caid: 0648, acs: 6.08, country code: AUT 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [mouse] providers: 4, ascii serial: 1234567890, hex serial: AABBCC, hex base: 1E 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [mouse] active providers: 4 (aabbff,001600,001700,001800) 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [mouse] found card system irdeto 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [irdeto] entitlements for provider: 1, id: AABBFF 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [irdeto] chid: 0001, date: 2013/03/01 - 2013/11/06 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [irdeto] chid: 0002, date: 2013/03/01 - 2013/11/06 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [irdeto] chid: 7FFB, date: 2013/03/01 - 2013/03/31 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [irdeto] chid: FFD8, date: 2013/03/01 - 2013/04/30 2013/03/01 15:22:42 14D7A88 r orf-ice-irdeto [irdeto] chid: 7FF7, date: 2013/03/01 - 2013/03/11
comment:31 by , 11 years ago
With above patch you will be ok, since you will be using 9 filters total. Can you please check it?
The second part of the patch is really needed to avoid memory overwrite.
If we also allow shared to hex serial only for 17XX, then 10 filters will be enough even for a card that uses all 4 providers.
comment:32 by , 11 years ago
The irdeto-patch above works for ORF/HDAustria/AustriaSat, but now we have a NEW problem:
I have 2 SKY A02 cards which are in the same ProviderGroup. So i can use one newcamd-reader to update BOOTH cards with shared EMMs.
Now after the patches from the last 2 weeks only the first physical card is updated
when mode AU = 1.
We must make sure that shared EMMs reaches all cards, there are in the same Group,
btw. where the first 4 Bytes from the HEX Serial on N3 cards are equal.
comment:33 by , 11 years ago
You do AU from oscam with DVBAPI or other client? (mgcamd/cccam etc)
About the hardware filters, can anyone give an example of an EMM pid that has too much data per second for software filtering?
mgcamd is able to AU at least 20 cards concurrently on a DM500, my guess is that it doesn't use hardware filtering.
comment:34 by , 11 years ago
Always with mgcamd and/or ACamd with newcamd-protocol.
because of the filtering:
when I´am on ORF1 for example, i can normaly update 2 SKY A02 Cards, 1 ORF-ICE Card in CW-Mode, 1 ORF-ICE Card in Irdeto Mode and 1 old ORF-CW card at the same time. never had a problem with dbox2 + mgcamd 1.38 with this.
On a dbox2 i have a typical CPU load of 20-35% only on the mgcamd daemon.
On an MTV Channel i can Update a Technisat Conax Card and a Canal+ NL Card at the same time. The system load is here in the range of 7-12% mostly.
comment:35 by , 11 years ago
Please commit above improved irdeto_get_emm_filter patch. What is does:
- Allow shared to hex serial only for betacrypt. This allows one more free filter slot for Irdeto.
- Skip not initialised providers. They always have first and third byte 0x00.
- Improve exit conditions from provider loop. Previous patch could result in memory overwrite.
- Only display "could not start all emm filters" if we break out of the provider loop. Previously it would display this message even if we haven't skipped emm filters.
comment:37 by , 11 years ago
Please note!
When the TV-Provider First-Time/Initial init with a UNIQUE-EMM via HEX-Serial the "not used" providers, how oscam handle this "new" ProviderIDs "on-the-fly" without the need of a reader coldstart or oscam-restart ?
I see in the past sometimes for Canal Digital (Seca) that ProviderIDs can be "regrouped"
from time to time.
comment:38 by , 11 years ago
Proper way is to read entitlements again after a unique emm that sets provider. But since this is rare for irdeto, you can just restart oscam. Don't know about seca.
comment:39 by , 11 years ago
If each unique emm updates the card we can easily use add_job like bulcrypt reader.
http://www.streamboard.tv/oscam/browser/trunk/reader-bulcrypt.c#L604
comment:40 by , 11 years ago
No, it doesn't, it only happens on initial activation and if provider kills a group of cards and moves some of them to new provider group (very rare).
follow-up: 44 comment:42 by , 11 years ago
I think it can be closed. I still disagree about the need of hardware filtering on EMMs, at least we should have an option for software filtering. mgcamd does software filtering on EMMs and doesn't seem to have any problem, at least on most transponders. But I will open a new ticket for that soon.
comment:43 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:44 by , 10 years ago
Replying to malakudi:
I think it can be closed. I still disagree about the need of hardware filtering on EMMs, at least we should have an option for software filtering. mgcamd does software filtering on EMMs and doesn't seem to have any problem, at least on most transponders. But I will open a new ticket for that soon.
Malakudi I have a similar problem with my irdeto provider. Already opened a ticket but havent received a response yet. Can you help?
http://www.streamboard.tv/oscam/ticket/3506
patch to accept irdeto unique emms to provider