Opened 5 years ago

Last modified 5 years ago

#4062 new defect

EMM Updates (newcamd -> oscam)

Reported by: marrik Owned by:
Priority: major Component: Reader
Severity: high Keywords: emm first card triple reader
Cc: Sensitive: no

Description

r10122

Oscam with triple reader only sends EMM updates to first reader but when first reader AU is disabled and restarted. All updates seem to be delivered without any problems to the second card in the same reader.

When the issue occurs

Unknown

How the issue is reproducable

Use triple reader (argolis) and enable AU on al cards

Included EMM Logging

Attachments (4)

prt2.txt (746 bytes) - added by marrik 5 years ago.
Same reader - prt 2 accepts EMM
prt1.txt (1.1 KB) - added by marrik 5 years ago.
Port 1 accepts EMM and port2 doesn't
1.png (7.6 KB) - added by marrik 5 years ago.
2cards.png (7.9 KB) - added by Jan Gruuthuse 5 years ago.
One Card active: both similar updated

Download all attachments as: .zip

Change History (19)

Changed 5 years ago by marrik

Attachment: prt2.txt added

Same reader - prt 2 accepts EMM

Changed 5 years ago by marrik

Attachment: prt1.txt added

Port 1 accepts EMM and port2 doesn't

comment:1 Changed 5 years ago by marrik

Addition: For testing purposes. I have placed 2 identical cards in the triple reader with both the same entitlements.

comment:2 Changed 5 years ago by marrik

Used config:

[reader]
label = triple-USB0
protocol = smargo
device = dev/ttyUSB0
smargopatch = 1
caid = 0604
boxkey =
rsakey =
detect = none
mhz = 600
cardmhz = 600
group = 1
emmcache = 1,3,31

[reader]
label = triple-USB1
protocol = smargo
device = dev/ttyUSB1
smargopatch = 1
caid = 0604
boxkey =
rsakey =
detect = none
mhz = 600
cardmhz = 600
group = 1
emmcache = 1,1,0

[reader]
label = triple-USB2
enable = 0
protocol = smargo
device = dev/ttyUSB2
caid = 0604
boxkey =
rsakey =
detect = none
mhz = 600
cardmhz = 600
group = 1
emmcache = 1,3,2

comment:3 Changed 5 years ago by theparasol

The emmdata catched by filters from reader1 is send to reader2 too.
Since the card irdeto base is different from the card in reader 1 the emm is skipped by reader2

Just wait until a filter setup by reader2 catches emmdata for reader2
That emmdata will be skipped by reader1 :)

comment:4 Changed 5 years ago by marrik

Are you sure?.. After 2 days the 2nd card still isn't updated.

comment:5 Changed 5 years ago by theparasol

Perhaps newcamd only sends updates for first card.
As long as you cant reproduce it with oscam dvbapi I dont consider this as a bug!

comment:6 Changed 5 years ago by marrik

Did some test with other protocols as well. But this is interesting:

Newcamd (client ) --> OSCAM1 --> OSCAM2 --> Triple Reader
I Have separated the readers/users/groups from oscam1 --> oscam2 --> cards
oscam1 readerX1 --> oscam2 readerY1 - card1
oscam1 readerA1 --> oscam2 readerB1 - card2

EMM's are being sent to OSCAM1 from the client
OSCAM1 sends emm's to BOTH readers to OSCAM2 (EMM's written increments equally)
OSCAM2 only updates 1 card in triple reader.

That seems strange because OSCAM1 shows global/unique emm's being written to both readers.

comment:7 Changed 5 years ago by theparasol

As said before, the base/hex serial of both cards in triple reader are different.
Therefor the emms are ignored by one of the cards.

Do the following test:

attach the triplereader to a local box with oscam dvbapi.
You will see both cards get updated. Reason for this is that oscam dbvapi sets multiple emm filters while newcamd only sets one, I presume for the card being used to decode.

comment:8 Changed 5 years ago by marrik

Sorry don't have a box where oscam can be installed on, using/testing it on a debian pc.

But look at this. I have installed cccam (2.3.0) and configured the reader to work with cccam. Then an Oscam server connects to this CCcam. Oscam shows the following in the log while connected to the CCcam server (take notice of the xxxx & yyyy:

2015/01/10 09:23:05 1ED5FD0 c srv [cccam] EMM: reader_caid 0000 != emmpid caid 0604 -> SKIP!
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: caid 0604 UA: 00001Exxxxxx0000
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000000:########
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000001:########
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000002:########
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000003:########
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: caid 0604 UA: yyyyyy1E00000000
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000000:########
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000001:########
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000002:########
2015/01/10 09:23:05 1EE52D0 p cccam(r) srv: au info: provider: 000003:########

And in CCcam both cards are shown as:

Cardserial 1111111111111111111 (yyyyyy)
Cardserial 2222222222222222222 (xxxxxx)

Card xxxxxx is being updates with emm's
Card yyyyyy isn't updated

Shouldn't both cards return information like this:

UA: 00001Exxxxxx0000
UA: 00001Eyyyyyy0000

instead of ?
UA: 00001Exxxxxx0000
UA: yyyyyy1E00000000

comment:9 Changed 5 years ago by theparasol

Well known issue: cccam serial is leftbased, oscam serial is rightbased
Including all issues with preleading zero's
Not going to put any effort in deprecated cccam protocol.
If you want your cards to be updated better setup something that does work.
Client using oscam dvbapi, share protocol camd35.

comment:10 Changed 5 years ago by dbox2

It is not a reader problem, it is the problem of two identifical cards in server(same caid-and ident) on the newcamd protocol.

Do this:
set reader1(slot1) > group 1
set reader2(slot2) > group 1,2

set user1 with access to group 1, user2 to group 2 only. Connect to oscam with both user (user1+user2), and you will get your cards with UA, so now you can send emm's to both cards. It works perfect with mgcamd. I don't know how oscam's dvbapi handle emm's with two newcamd reader, with the same caid (and ident). Let's try it.

comment:11 Changed 5 years ago by Jan Gruuthuse

It works with c378x: STB1 views on STB2 with 2 nearly similar cards (same provider 0100:00006C) both cards gets updated. I disabled this, as I wanted only local dvapi to update its local cards in its box. Dvapi has au with internal card reader labels only. Preventing other users to update these cards.

comment:12 Changed 5 years ago by marrik

@jan Gruuthuse.. Thanks... This setup works indeed.. Only Oscam still sends EMM's only to the card 'used to decode the channel' maybe there should be an option to always accept "all emm's"?

This way expired cards can be revived without a 'supported' decoder!

Changed 5 years ago by marrik

Attachment: 1.png added

comment:13 Changed 5 years ago by marrik

Even with this config.. 1st reader has priority... See attachment 1.png

Last edited 5 years ago by marrik (previous) (diff)

Changed 5 years ago by Jan Gruuthuse

Attachment: 2cards.png added

One Card active: both similar updated

comment:14 Changed 5 years ago by Jan Gruuthuse

If it does not work: either it does not work like for that provider or it is a triple reader issue.

comment:15 Changed 5 years ago by marrik

After some more testing i have the following results with c378x:
Oscam/Server? reboots every night to start all 'clean/fresh'.

Readers updated:
DAY1: Reader X & Y
DAY2: Reader Y
DAY3: Reader Y
DAY4: Reader Y
DAY5: Reader X
DAY6: Reader X & Y (some emm's not as many as other days)
DAY7: Reader Y
DAY8: Reader Y
DAY9: Reader Y
DAY10: Reader X

Config hasn't changed and sometimes reader x accepts emm's and and then for some reason only reader y accepts them.
Seems that when oscam reboots and receives its first ecm to decode. That reader will be updated for the rest of that day.

Note: See TracTickets for help on using tickets.