Opened 12 years ago

Closed 9 years ago

#2440 closed defect (expired)

SCs not reshared using cccam proto after au was enabled

Reported by: geohei Owned by:
Priority: major Component: Protocol - CCCam
Severity: low Keywords: cccam entitlements
Cc: Sensitive: no

Description

Revision

OSCAM 1.20-unstable_svn build #6460

Issue Description

SCs in load balancing not showing properly in list of entlitlements of client when au=0 on server connected for that client.

When the issue occurs

Always when SCs are shared in load balancing.

How the issue is reproducable

I only tested the issue while using cccam-ext (2.2.1-3316).

Test 1:
oscam client - oscam server/client (au=1 for client) - oscam server (2 SCs in load balancing)
ecm.info on client shows hop2. Correct!
The client shows the SCs correctly in the list of entitlements.

Test 2:
oscam client - oscam server/client (au=0 for client) - oscam server (2 SCs in load balancing)
ecm.info on client shows hop3, NOT CORRECT!
The client doesn't show the SCs in the list of entitlements.

When I set au=0 in the server for a user (oscam client), the client doesn't show the 2 SCs which are used in load balancing in the entitlements. Other cards (in the same server) are shown properly. Hence, the issue is related to load balancing. Despite the fact that the SCs are not shown in the entitlements, the server provides the client with the SCs from the oscam server holding the SCs. In other words, the client shows that the sent CWs are sent from a server 3 hops away but real life, they come from a server hops 2 away.

When I enable au (au=1), the entitlements show the SCs in load balancing 2 hops away and the ecm.info reports hop2, which is correct.

Also, when I disable load balancing (lb_mode=0), the autoupdate option (au=0|1) doesn't matter. The SCs are always shwon properly in the list of entitlements.

Autoupdate has nothing to do with the the display of the SCs in the list of entitlements. Therefore this is most likely a bug.

It only appears in combiunation of au=0 with lb_mode!=0.

All cccam options in all 3 oscam boxes above are default, except when mentioned otherwise.

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

Change History (15)

comment:1 by geohei, 12 years ago

Severity: Please fill inlow

comment:2 by geohei, 12 years ago

Summary: SCs in load balancing not showing in entitlements of clientSCs in load balancing in conjenction with au=0 not showing in entitlements of client

comment:3 by geohei, 12 years ago

Summary: SCs in load balancing in conjenction with au=0 not showing in entitlements of clientSCs in load balancing in conjunction with au=0 not showing in entitlements of client

comment:4 by geohei, 12 years ago

Addendum ...

(Comment about CCcam server deleted since confusing ...)

Last edited 12 years ago by geohei (previous) (diff)

comment:5 by geohei, 12 years ago

Addendum 2 ...

New findings.
Parts of comments above might be misleading.
However most of it remains true.

Details are described here:
http://www.streamboard.tv/wbb2/thread.php?threadid=33957

The bug can be reproduced easily using 3 oscam.

oscam_s1/s2 - physical servers, no dvbapi, e.g. for 1702 SC and 1843 SC
oscam_m - oscam which serves as manager, dvbapi
oscam_c - oscam client

Since oscam_s1/s2 have no dvbapi, I need to feed oscam_s1/s2 with EMMs from oscam_m (which has dvbapi). Hence, autoupdate is enabled between oscam_s1/s2 and oscam_m.

However I don't want to relay the serials of the 1702 and 1843 SCs to oscam_c, therefore autoupdate is disabled between oscam_m and oscam_c.

This is translated into the following configuration

oscam_s1/s2:

oscam.user - au=0 (for oscam_m).

oscam_m:

oscam.servers - audisabled=0 (for oscam_s1/s2)
oscam.user - au=0 (for oscam_c).

This constellation generates the bug, but makes that the shares from oscam_s1/s2 initially appear in the list of entitlements for oscam_c, but disappear (some SCs only) after some time (immediately of up to 30 minutes). If the shares disappear, they are not usable anymore by oscam_c.

Last edited 12 years ago by geohei (previous) (diff)

comment:6 by geohei, 12 years ago

Tested now with 1.20-unstable-6528.
Bug seems fixed (tested ran for some hours).
I just can't spot any fix between #6460 and #6528 which might have been responsible.

Version 1, edited 12 years ago by geohei (previous) (next) (diff)

comment:7 by geohei, 12 years ago

Resolution: fixed
Status: newclosed

comment:8 by geohei, 12 years ago

Resolution: fixed
Status: closedreopened

comment:9 by geohei, 12 years ago

The bug still exists ... in #6528
The premature closing of the ticket was due to a config mistake during testing from my side.

To make it easy and be able to reproduce the phenomena:

LEVEL 1:
oscam_s1 (SC1), oscam.user, au=0 for oscam_m
oscam_s2 (SC2), oscam.user, au=1 for oscam_m

LEVEL 2:
oscam_m, oscam.servers, audisabled=0 for oscam_s1
oscam_m, oscam.servers, audisabled=0 for oscam_s2
oscam_m, oscam.user, au=0 for oscam_c

LEVEL 3:
oscam_c, oscam.servers, audisabled=0 for oscam_m

The error shows in oscam_c. Initially, SC1 and SC2 are visible in oscam_c. But after a while (varies from immediately up to 1 hour), only SC2 is visible.

By visible, I understand that the SC is shown in the list of entitlements and thus, is usable by oscam_c.

The remedy is to switch au=1 for oscam_m (in oscam_s1) or au=1 for user oscam_c (in oscam_m). In other words ... if autoupdate is activated one level down, it needs to be activated from there on all levels down in order to publish the SCs. If autoupdate is interrupted once, the SCs disappear on a server/client further down after a while.

Last edited 12 years ago by geohei (previous) (diff)

comment:10 by geohei, 12 years ago

Summary: SCs in load balancing in conjunction with au=0 not showing in entitlements of clientSCs not reshared using cccam proto after au was enabled

comment:11 by geohei, 12 years ago

To facilitate understanding the issue, here a brief summary:

Level 1 - OSCam with SCs, no dvbapi
Level 2 - management OSCam
Level 3 - client OSCam

  1. level 1 - NO autoupdate - level 2 - NO autoupdate - level 3 client sees SCs from level 1
  2. level 1 - NO autoupdate - level 2 - autoupdate - level 3 client sees SCs from level 1
  3. level 1 - autoupdate - level 2 - NO autoupdate - level 3 client DOES NOT see SCs from level 1
  4. level 1 - autoupdate - level 2 - autoupdate - level 3 client sees SCs from level 1

As said before, 3. might take up to 30 minutes in order to propagate the problem. Initially, the SCs from level 1 are visible but "disappear" gradually.

Hope that helps somewhat that someone manages to simulate the issue.

comment:12 by geohei, 10 years ago

Priority: minormajor

I'd like to confirm this bug still exists in #9000.
It is really not desirable to keep AU on just to get proper sharing using cccam protocol.

To summarize again:

0 - 0 - card from level 1 visible!
0 - 1 - card from level 1 visible!
1 - 0 - card from level 1 NOT visible!
1 - 1 - card from level 1 visible!

The "0" and "1" above represent the "au=" setting of the user.

The only new discovery was now, the I used (for testing purpose) CCcam on level 3 (the client) and as such cccam protocol (as opposed to cccam-ext) between level 2 and level 3.

Hope this encourages someone to fix this nasty bug.

Last edited 10 years ago by geohei (previous) (diff)

comment:13 by BurnMasterRecords, 10 years ago

Resolution: worksforme
Status: reopenedclosed

Works fine for me.

comment:14 by geohei, 9 years ago

Resolution: worksforme
Status: closedreopened

Nope ... doesn't work.

#10076 ... new discoveries which might help.

a.
Initially, clients might show cards from level 1 even if "1 - 0 - card from level 1 NOT visible!" constellation (see comment 12 above) is active, however this might change after some minutes. Scheme not detectable. I didn't see a constant time or some reproducable behaviour. Sometimes the cards stay for hours, somethimes they disappear or don't show up at all.

b.
When all levels (servers [oscam_sx], intermediate servers [oscam_m], clients [oscam_c]) are local, all works fine initially. In my setup, level 1-2 is partially not local but Internet. In this case, level 3 (clients) show cards only if AU=1 on level 2. But this - again (see a. above) - is just initially. After approx. 15 minutes, also locally connected cards (level 1-2) disappear. Fact is however that local cards are longer visible than remote cards.

c.
When cards disappear, they might show up again at a later stage.

d.
If cards are not shown, the ECM is not sent to reader meaning TV remains black! This is very bad!

Bsically, is cards are shown on client's side seems to be pretty much random, but locally connected cards stay longer than remotly connected cards. Reason ... totally unknown!

So the bug still exists.

@BurnMasterRecords
Perhaps your test was entirely local.

... later (25.12.2014) ...

In fact, I have to correct the summary in comment 13 regarding the interaction between level 2 and 3.

0 - 0 - card from level 1 NOT visible!
0 - 1 - card from level 1 NOT visible!
1 - 0 - card from level 1 NOT visible!
1 - 1 - card from level 1 visible!

Last edited 9 years ago by geohei (previous) (diff)

comment:15 by Deas, 9 years ago

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