Opened 13 years ago

Closed 13 years ago

#1634 closed defect (fixed)

The cccmaxhops loop story.

Reported by: littlejoe Owned by:
Priority: major Component: Protocol - CCCam
Severity: medium Keywords: CCcam maxhops reshare problem
Cc: schlocke Sensitive: no

Description

Revision

4699 but older too

Issue Description

I have SERVER1 and SERVER2 (with about 50 CCcam readers) connected to PEER1 as CCcam users to his local card. PEER1 is also connected to SERVER1 and SERVER2 as user. To avoid PEER1 beeing a potential loop path between the 2 servers, I have set cccmaxhops to 0 (local SC only) for the 2 users accounts SERVER1 and SERVER2 on PEER1.
It seems to be OK excepting for the non subscribed channels of the SC of PEER1 and only for the same caid and ident like the SC.
So from time to time I see in the log of PEER1(see attached) that client SERVER1 is found by SERVER1 itself! or by SERVER2. And this is a reshare/maxhops issue that creates loops and timeouts in such situations of same users as servers in CCcam.

When the issue occurs

When the channel requested is not subscribed.

How the issue is reproducable

See description

<Don't forget to ATTACH (not post here) a log file of oscam in debug mode (start oscam with -d255)!>
The log is a simple log. I can provide a -d255 one if needed.

Attachments (1)

looplog.txt (8.6 KB ) - added by littlejoe 13 years ago.

Download all attachments as: .zip

Change History (6)

by littlejoe, 13 years ago

Attachment: looplog.txt added

comment:1 by schlocke, 13 years ago

Resolution: wontfix
Status: newclosed

This is NOT a cccmaxhops problem. Oscam is not CCcam and does not work like CCcam. Oscam is a ECM router, CCcam a card router. ECM requests from clients are NOT forwarded to the requesting cards, they are forwarded to any matching router, controlled by the loadbalancer. And this loadbalancer ofter tries alternate routes to find faster cards. So a SERVER2 request to SERVER1 also tries SERVER2 if he can't decode a channel. But the loadbalancer discovers this because it's always the slower way. So after a short learning time, SERVER2 does not ask SERVER1 anymore.
Oscam also can send one ECM request to multiple readers to learn ecm response times.

So everything is working as designed.

comment:2 by littlejoe, 13 years ago

Keywords: reshare problem added; loop removed
Resolution: wontfix
Status: closedreopened

Hi, I'm sorry but SERVER2 do not see SERVER1 on PEER1 because it has ccmaxhops to 0. If you verify in the reader entitlements details of PEER1 on the 2 servers, you can see only PEER1 local SC. SERVER2 never try SERVER1 in direct. It tries PEER1 SC and ONLY if PEER1 SC does not decode, PEER1 itself seems to be able to querry the 2 SERVERS (as readers this time) and route the ECM and CW.

This curious effect happens only in the case of a non subscribed channel on the local SC of PEER1. NOT FOR OTHER CAID and IDENTS. So this is maybe correctable. just check in the case of a non decoded channel by the local SC if PEER1 has the right to reshare and if not. just do not route the ECM... ? (ccreshare=0 on both SERVERS in the user account of PEER1 in my case) look the above config please. Thanks.

User account for PEER1 on SERVER1 and SERVER2
[account]
user = PEER1
pwd = PEER1pass
group = 4
uniq = 3
au =
services = !deniedprovid,!viaobsolete,!hd-500-032830
cccmaxhops = 3
cccreshare = 0
keepalive = 0
numusers = 1
penalty = 1

SERVER1 and SERVER2 account on PEER1
[account]
user = SERVERx
pwd = SERVERxpass
group = 1
monlevel = 4
au =
cccmaxhops = 0
cccreshare = 3
numusers = 1
penalty = 1

comment:3 by littlejoe, 13 years ago

Just for info. I have tried to connect SERVER1 and SERVER2 to reader PEER1 with newcamd instead of cccam. Same problem...

comment:4 by Deas, 13 years ago

please try with latest version. there were some fixes in the last few weeks...

comment:5 by littlejoe, 13 years ago

Resolution: fixed
Status: reopenedclosed

Closing. Last versions are OK.

Note: See TracTickets for help on using tickets.