Opened 12 years ago

Closed 9 years ago

#2148 closed defect (expired)

CCcam protocol maxdown violation problem

Reported by: aigars Owned by: x
Priority: minor Component: Protocol - CCCam
Severity: medium Keywords:
Cc: stefansat@… Sensitive: yes

Description

Revision

5967, and probably in everyone before

Issue Description

Occam "reshares" shares where maxdown is 0

When the issue occurs

OScam as CCCam proxy with multiple shares with same caid but different maxdown

How the issue is reproducible

I have several shares with the same caid, one of them is with maxdown=1 others maxdown=0. When server received ecm request(cccam protocol), oscam forwards often it to shares with maxdown=0.

I'm not attaching the log, because is huge, but this is probably relevant line:
2011/10/03 13:40:58 41074050 c user (0100&000068/32DC/64:1DDF): found (559 ms) by server.dyndns.org (of 1 avail 88)
(server.dyndns.org have corresponding share with maxdown 0).

I lost few peers because of this, therefore I'm marking this problem critical.

Aigars

Attachments (1)

4686_maxdown0.patch (16.5 KB ) - added by zywo 12 years ago.
Here's the diff between aigars source and 4686 trunk, maybe there are some backport from current trunk

Download all attachments as: .zip

Change History (72)

comment:1 by BurnMasterRecords, 12 years ago

This is not a Bug, because OSCam is not a Cardrouter its a ECM Router.

comment:2 by xing0r, 12 years ago

Resolution: invalid
Status: newclosed

use "cccmindown = 1" for cccamproxys and all cards with maxdown=0 filtered out.

and don't use "ignorereshare" or "cccignorereshare"! this option remove reshare rules!

regards

comment:3 by aigars, 12 years ago

Resolution: invalid
Status: closedreopened

Sorry, but I have to reopen this ticket, because:

About cccmindown=1: that is workaround, not a solution. Because I also want to use shares with "no reshare" localy with dvbapi, just not to give to others. Like CCcam does.

Sorry,but about "ECM Router" I did not understood. Does it mean that I can't use it for normal server.

If yes, publish this note on the oscam site, so for people not to use it. At least two if my peers is also using oscam and their ecm rate 3x-4x higher than others (with loadbalancing enabled). And I suspect it is related this problem.

I'm also C developer, and "quickly" went through the code, and found the function matching_reader in oscam_chk.c where reader seems to be chosen. This function doesn't contain any functionality regarding reshare rule of CCCam protocol.

Aigars

comment:4 by BurnMasterRecords, 12 years ago

If you have at least one Card with Reshare an other Card with the same CAID Oscam asks all Cards because OScam choose the Cards not the Client.
If you dont want this, you have to use Forward origin card: 1

But aware this disables the LB and make OScam to a stupid emu like CCcam.

comment:5 by aigars, 12 years ago

I'm still want to use LB and caching in case if I have several cards of same providers with reshare.
Why not simply add one more check at matching_reader to check reshare of the card.

What a use of these "clever" solution (LB and caching), if at the end card of peer get overloaded.

Aigars

comment:6 by corsair, 12 years ago

Resolution: wontfix
Status: reopenedclosed

matching_reader selects the reader, not the card. A reader can have many cards, the card selection is done, when the reader is selected and invoked. The cccam reader then selects the best card for the request. Also the reader does not know where the request came from; local or remote is just the same for the reader. So there is nothing we could do here.

comment:7 by aigars, 12 years ago

Resolution: wontfix
Status: closedreopened
Type: defectenhancement

There long was no any response, so I fixed by myself and forgot about this problem. Just now accidently opened this ticket.
My question: yes it selects the reader, but why not check reader cards?
Here what I added inside matching_reader of oscam version 4686 (sorry, had no time to check with newer versions):

==================

if((er->client) && (strncmp(rdr->ph.desc,"cccam",5)==0)) {

int canUse0Maxdown=((strncmp(ph[er->client->ctyp].desc,"dvbapi",6)!=0)
(er->client->account->cccignorereshare));

struct s_client *cl=rdr->client;
struct cc_data *cc = cl->cc;
LL_ITER *it;
it = ll_iter_create(cc->cards);
struct cc_card *ncard;
int found=0;
while ((ncard = ll_iter_next(it))) {

if(ncard->caid == er->caid) {

if(canUse0Maxdown) {

found=1;
break;

}
else if(ncard->maxdown>0) {

found=1;
break;

}

}

}
ll_iter_release(it);
if(!found)

return 0;

}

=============

and following check I added into cccam modules cc_send_ecm function

=============

if((ncard->maxdown<1) &&

(cur_er->client) &&
(strncmp(ph[cur_er->client->ctyp].desc,"dvbapi",6)!=0) &&
(!cur_er->client->account->cccignorereshare))

continue;

============

And now I have no problems with my cccam peers and no-one is complaining that I use Oscam.
Aigars

comment:8 by john_28, 12 years ago

@aigars
Despite the ticket subject ,Since u provide a patch and mentioned , u are C developer , I think u are very welcome and want to respectfully invite u to join oscam dev team if u want , u just need send a pm to admin of streamboard , He makes access to commit oscam svn ,... for u.
Best Regards.

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

comment:9 by zywo, 12 years ago

@aigars:

Many thanks, this is a very good solution.

comment:10 by corsair, 12 years ago

@aigars: Good idea, but it needs some improvements

comment:11 by zywo, 12 years ago

@aigars:

please, can you post a patch against 4686 svn?

thanks

comment:12 by aigars, 12 years ago

@john_28

Sorry, have very limited time and mostly I in Java and C++. Maybe later if I will find something more to fix :-)

@corsair

Of course: this is just quick fix by me. I even not sure if this is applicable with newer versions.

@zywo:

Over the past year, I changed many things in 4686. If you like I can give complete source tree.

comment:13 by zywo, 12 years ago

@aigars:

It would be interesting to test your changes, or at least you give us the two files "oscam.chk.c" and "module-cccam.c"

comment:14 by aigars, 12 years ago

How? Maybe you can send me PM at streamboard or oscam.to forum

comment:16 by today, 12 years ago

@aigars: can you send me your source or patch via PM at oscam.to or streamboard?

regards

by zywo, 12 years ago

Attachment: 4686_maxdown0.patch added

Here's the diff between aigars source and 4686 trunk, maybe there are some backport from current trunk

comment:17 by zywo, 12 years ago

up

comment:18 by avs1978, 12 years ago

Priority: criticalminor
Severity: highmedium

I have two questions:

The suggested feature still doesn't exists in in revision 7500 and up?

Did someone test the patch of zywo?

comment:19 by zywo, 11 years ago

Hi,

The suggested feature is not exist in any official revision.

This is not my changes, I just made a patch from aigars modified sources (svn 4686).

comment:20 by avs1978, 11 years ago

Ok noted. I am wondering, does this bug still exists? In the newer revisions.

Because, I think this "bug" is fixed.

Can someone confirm or proof with a log for newer version this bug still exists.

grtz

comment:21 by Nimloth, 11 years ago

Resolution: fixed
Status: reopenedclosed

No reply so seems to be fixed

comment:22 by zywo, 11 years ago

Resolution: fixed
Status: closedreopened

The bug is not fixed yet, it was never fixed.

comment:23 by ni hao, 11 years ago

CCcam maxdown...? I do not think such a fucntion exist. And if it would exist maxdown does not mean not to send ECM, but he/she who receives the ECM is only allowed to use it local. There is a 'reshare' function; however reshare=0 does not mean not to send ECM but - again - only for local use. For me there is nothing to be fixed; I think it is invalid.

Last edited 11 years ago by ni hao (previous) (diff)

comment:24 by zmeura, 11 years ago

It's hard to explain how this is happening.If you give only local card to a user (CCC Maxhops=0) he will receive only this card,but all ECM request for that CAID that your local card can't open is forward to de other cards from your server (cccam lines).It should ask only the local card,not to forward this request to other readers with no reshare.

comment:25 by BurnMasterRecords, 11 years ago

That is not a Bug.
If u want that OScam use only Cards with Reshare then use: Forward origin card:

comment:26 by zmeura, 11 years ago

I want oscam to send request only to hop0 where is my local.This is happening only for caid of your local,even if that user sees only your card and I have set CCC Maxhops=0 for him, he gets respons from other hop if your local is not able to respond.It's also written in description of this ticket.

comment:27 by BurnMasterRecords, 11 years ago

Thats not possible.
I write it in my first Post here.

comment:28 by zywo, 11 years ago

I think you have not understood yet the problem of maxdownhop=0

Please, reread the first aigars's post.

comment:29 by stefansat sat, 11 years ago

I Think You missed something

If You use reshare 0 by oscam this does mean that the next hop will not be able to reshare the card You actually still reshare it

If You do not wan't You're local card to be reshared,

just add to the reader
of you're local card

cccreshare = -1

Note there was a bug into all versions which made the use of this parameter not possible by non ccam protocol readers. this is now fixed since version.

8535

comment:30 by stefansat sat, 11 years ago

Oeps sorry seems that also something changed and that is that when using -1 it takes the global reshare value before it was no reshare for that card.

I'll recheck that

comment:31 by stefansat sat, 11 years ago

Hello indeed when using cccreshare by reader or user, 0 means reshare but the client will not be able to reshare

But You still can set into cccam global config - 1 ,this means the card can't be reshared trough cccam and will only work locally if by the reader You also added -1.

By each reader which can be reshared You add 0 for cccreshare that's just one hop
with 1 You're client will be able to reshare it one times. and so on.

Further there is such a parameter called group, also here You can limit a user to a couple of groups only, Off course it's best to give each reader an other group nummer for that.

The ignore reshare is standard 0, But You can set 1 and then the reshare limit off incoming card will be disregarded, This parameter is actually needed If You for example run you're oscam on a pc then You need this, Off course You only use this for you're local box connected to the pc. Yes it can be abused this parameter but those who are doeing that are fooling themselve as they will be cicked out faster then they are in.
But for a perfect oscam it's a requirement. running server on you're box which you also wach video's and do a lot of other stuff is to heavy for the box.

Further already mentionned it's an ecm server not a card server.
But setting in global config ccam section

reshare_mode = 4

will solve the problem of forwading the ecm. to another card if the caid/povid is present.

There are plenty off config options. They are very well explained in txt. But Indeed You need to read them troughfully. The posibilities are so big that it's not very easy to configure . But all is possible.

comment:32 by stefansat sat, 11 years ago

And yes again a small prob against reshare but the docs are wrong.

for oscam.conf.txt

It must be

reshare = level

reshare level for CCcam clients (default:10):

-1 = no resharing
0 = resharing for direct peer only
1 = resharing for direct peer and next level
x = resharing for direct peer and next x level

For oscam.server.txt

It must be

cccreshare = hop

set reader's CCcam reshare hop, default:0

-1 = reshare value of cccam in global config
1 = resharing for direct peer and next level
x = resharing for direct peer and next x level

So it work's in real

comment:33 by stefansat sat, 11 years ago

for oscam server sorry xtra correction

For oscam.server.txt

It must be

cccreshare = hop

set reader's CCcam reshare hop, default:0

-1 = reshare value of cccam in global config

0 = reshare for direct peer only

1 = resharing for direct peer and next level
x = resharing for direct peer and next x level

So it work's in real

comment:34 by zywo, 11 years ago

We're not talking about any cccreshare parameter, but about the cards having maxdownhop 0

comment:35 by stefansat sat, 11 years ago

Maxdown hop has nothing to to with reshare. this means there is no fault at all.

Then

comment:36 by stefansat sat, 11 years ago

And just because that. There is also a change added very long time ago by schlocke.

reshare_mode = 4

cause with 0 it is possible that like for incoming card x which has 0 furtherdown, it will not be further in list from another client. But any other card with somwhere a service = xxx in containing this will cause that the ecm coming from a hop further will at the end be send to this card .

When using

reshare_mode = 4 this does not happens.

again it's ecm server

comment:37 by stefansat sat, 11 years ago

Yes and to solve the problem from comment 25

It's hard to explain how this is happening.If you give only local card to a user (CCC Maxhops=0) he will receive only this card,but all ECM request for that CAID that your local card can't open is forward to de other cards from your server (cccam lines).It should ask only the local card,not to forward this request to other readers with no reshare.

this is indeed not possible on the way he thaught it would work. The maxhop wil only reflect to the cardlist. but the oscam where his local card is will forward it to other readers if it finds same caid/provid and it's faster in response.

Wheater he must do like BurnMasterRecords told forward orig card by server where his local is. Or he can also adding service block's to the other readers services = !xxx

Or this is also very possible Thta's creating by server where local is more cccam accounts of which one for example only containes the group from his local card.
another account with his otther groups

Then by his client box creating a reader to the account with only local card
another reader to the account with rest off card's.

And add services by local card account for only that card services = xxxx
And by the reader to the account for other card's creating services = !xxxx

So plenty off options.
You can not change the basic behaviour from ecm server. the only thing You will succeed is bugging the whole good working oscam cccam module now
It's just a mather of advanced configuration.

This topic is not a bug and nothing can be changed a propose to close this one.
As it's a configuration issue.
And Yes the documentation about reshare and cccreshare was wrong as well. That leads to confusion.
They should be modified like explained in comment 33 and 34

Last edited 11 years ago by stefansat sat (previous) (diff)

comment:38 by zywo, 11 years ago

@stefansat:
I think you're a C developer, then have a look at this:

http://www.streamboard.tv/oscam/ticket/2148#comment:7

comment:39 by stefansat sat, 11 years ago

Now I'm not a c developper but that will screw the work of the current oscam.

use the configs to solve the problem, They are made for that.

comment:40 by stefansat sat, 11 years ago

I just corrected doc about use off reshare parameter in oscam.conf and cccreshare in oscam.server

comment:41 by zywo, 11 years ago

The title of this ticket is "CCcam protocol maxdown violation problem"

not "CCcam protocol cccreshare parameters problem"

comment:42 by stefansat sat, 11 years ago

As the mather of fact they are related to each other.
And there is no violation at all. The oscam was just wrongly configured that's all.

The maxdown is just for cardlist and is aboslutely not the same as in original cccam.

If You send and ecm to oscam, oscam will tread the ecm. The oscam server needs to be configured as how to.

If You do not wan't to read how to configure You oscam to obatin you're goal You still can use CCcam self then you're problem is solved as well.

comment:43 by stefansat sat, 11 years ago

Resolution: invalid
Status: reopenedclosed

This is not a bug Oscam is ecm router not card router BurnMasterRecords is right
Do never use cccignorereshare or ignore reshare ! xing0r is right. But it maight be needed in some cases (server is not running on box but on pc) to use it that's why I added example configs to explain.

For the case server is running on you're own box :

By oscam.config use : (the easiest way)
reshare_mode = 4
reshare = -1 (no standard reshare of any reader if a reader needs to be reshared wheater it's a proxy or local reader use cccreshare by the reader also use cccreshare by client account as default value is that from oscam.conf)

oscam.server (example) for the case server is running on you're owwn box

[reader]
label = mylocal1
group = 1
protocol = any local cardreader
cccreshare = -1 (or parameter not used is same as -1)

[reader]
label = mylocal2
group = 2
protocol = any local cardreader
cccreshare = 0

[reader]
label = proxy1
protocol = cccam
group = 3
cccreshare = 0

oscam.user (example for case server is running on you're own box)

[account]
user = dvbapi
uniq = 3
au = 1
group = 1,2,3

[account]
user = Ancccamfriend
pwd =
uniq = 3
au = 0
allowedprotocols = cccam
group = 1,2,3
cccreshare = 0 (parameter required otherwise it will take -1 from oscam.conf)

With the upset above,

On you're box You will use the three readers
You're cccam friend will be able to use
Only You're local2 and proxy1 as far there are hops avbl on incoming card's
He will not be able to reshare.

For the case server is running on you're pc and Ypou're box is a client of server

By oscam.config use : (the easiest way)
reshare_mode = 4
reshare = -1 (no standard reshare of any reader if a reader needs to be reshared wheater it's a proxy or local reader use cccreshare by the reader also use cccreshare by client account as default value is that from oscam.conf)

oscam.server (example) for the case server is running on you're pc

[reader]
label = mylocal1
group = 1
protocol = any local cardreader
cccreshare = 0

[reader]
label = mylocal2
group = 2
protocol = any local cardreader
cccreshare = 0

[reader]
label = proxy1
protocol = cccam
group = 3
cccreshare = 0

oscam.user (example for case server is running on you're PC)

[account]
user = Mybox
pwd =
allowedprotocols = cccam
uniq = 3
au = 1
cccignorereshare = 1
group = 1,2,3

[account]
user = Ancccamfriend
pwd =
uniq = 3
au = 0
allowedprotocols = cccam
group = 2,3
cccreshare = 0 (parameter required otherwise it will take -1 from oscam.conf)

Now You're box will be able to :

Receive You're local card1 card2 and the proxy as if the dvbapi would be on server self .That's why cccignorereshare must be used for You're box account ONLY

You're cccam friend will only receive You're local card 2 and proxy1 like it is by cccam and must be used. The local card one will not be send to hime as he does not have acces to group 1 .

Hope You'll understand how oscam server cccam work's this ticket is set back to invalid as it is not a bug. The maxdownhop by a cccam client work's if you connect to a real cccam. But is not made for oscam to oscam trough cccam protocol.

No need to patch or change the source Just configure it like example.

Note :
To avoid that oscam client start's or dvbapi start's using using a remote for channels which are supposed to be decoded on You're local card,

In the first case Oscam server is running on box self use :

preferlocalcards = 1

In oscam config.

For the second case it will require a bit more configuration.
For that we will use services = entry.

First define in oscam.services the services for You're local card's .

in oscam.services ad :

[mylocalcard]
caid=xxxx
provid=xxxxxx
srvid = (all sids ok for you're card separated by , or just ommit this line to tread the full caid provid)

Then You will ad this defined services to the proxy reader into oscam.reader with a !
!

so the config of the proxy will now be :

[reader]
label = proxy1
protocol = cccam
group = 3
cccreshare = 0
services = !mylocalcard


Last edited 11 years ago by stefansat sat (previous) (diff)

comment:44 by zywo, 11 years ago

You still don't understand what we're talking about in this ticket

comment:45 by stefansat sat, 11 years ago

As the mather of fact I do very well, Try self to study difference between oscam and cccam, more likely multi protocol and single protocol, And especially the difference between ecm server or card server.

If You study that and understand it, you will right away see that this topic is wrong and that there is no violation at all. A more detailed config upset about cccam and how to setup is just give in topic http://www.streamboard.tv/wbb2/thread.php?postid=461517#post461517 at the end called :

cccam basic config whitout unwanted share reroutings

oscam is not the same as cccam , but is a multi protocol cam compatible with the cccam protocol. You can let work the cccam server module perfectly like it is in cccam if You configure it wright. It is not the client who decides as what or ho fare to go, it is the server. And that is one of the main differences between ecm or card server not the only but an important an major one.

This topic has already been closed by other persons who do now the correct function understand it and try to explain it, there are even much more similar topics around this misunderstanding which have been closed long long time before. And to my shame there is some one which I opened now I think even more then 3 year's ago when I was a newbie on oscam , in those days I was also thinking as a cccam user but was wrong .

Do not open tickets for not right statements. Like there is a vialoation , as there is not one This is oscam , not cccam, it can be configured to work perfect whitin the limits as cccam and that You must do, if You tell other peers that you are a cccam. You will have no problems at all and as the mather of fact it works much better then cccam which is very very behind for his public versions.

Do not turn upside down the working to come out with an explanation off ...

You still don't understand what we're talking about in this ticket

I really understand what you mean but no that is not oscam even worse bassically cccam even does not really work like You think , it's just a basic setup(config) in their closed public source. And this behaviour can't be changed by the user. But the developpers group are much further and do use the original cccam like oscam.

You are always free to patch any of the source for own use , that's why it's open source. However You will need to do a lot af work each time that You update You're cam and this for an issue which is just a mather of configs ?

Now can somethings be improved Yes always nothing is perfect. As the mather off fact this last year one person did many many improvements in the whole oscam project. Taking out a lot of bug's changing old c code use to the new standard's and so one .....
Into cccam module there is place for some improvement,
Like for example the preferlocalcards does only work for dvbapi clients not for others users. This can be solved using services in oscam , but yes would be nice to adapt the basic cccam.module to do that. For that we actually need a real c expert wich is nowing the cccam module , would be nice if schlocke comes back for that.

comment:46 by zmeura, 11 years ago

Ziwo is right,please don't spam this tiket if you didn't understood.The situation is similar with cards from hop 1-2,if you have one card for a caid,with reshare 1 then oscam ask all cards with that caid,even that all of them are with reshare 0!!

comment:47 by BurnMasterRecords, 11 years ago

You Guys didn't understand that OScam is NOT CCcam.
With OScam it's NOT the Client who choose the Card it's the Server.
If you want the functions like Original CCCam simply use Forward origin Card.

Last edited 11 years ago by BurnMasterRecords (previous) (diff)

comment:48 by zywo, 11 years ago

@BurnMasterRecords:
you still don't understand as stefansat.

The bug was fixed by aigars against svn4686 here: http://www.streamboard.tv/oscam/ticket/2148#comment:7

But I need to adapt this to current trunk, for personal use only.

comment:49 by stefansat sat, 11 years ago

Ziwo is right,please don't spam this tiket if you didn't understood.The situation is similar with cards from hop 1-2,if you have one card for a caid,with reshare 1 then oscam ask all cards with that caid,even that all of them are with reshare 0!!

That's excactly what oscam does and must do, again like BurnMasterRecords That's now an ecm server. However a lot off persons did insert good working things so that You can configure the server as A real cccam behaviour, Use Forward to origin card in server and You're client maxhop asking will be followed. Or take advantage off the benifit off oscam and Work with filters In you're server like explained by me. Be also up to date with You're oscam version as real bugs are threated. By oscam the server descide's, actually the server in any application even cccam descide, but in cccam it's closed configuration concerning this stuff. By oscam open . Read,think an do. And no zywo that comment 7 is not a bug fix but a patch to modify oscam in only very limited change which will screw up the natur off oscam. And destroy the good working cccam module (if configured wright) . Configure You're oscam server.

again

reshare_mode = 4 (very very important do not use the default 0)
That's already a start.

Of course like said before You are free to patch the source for own use or just use cccam That's up to you.

comment:50 by zmeura, 11 years ago

Stefansat you posted at least 5 post one after another in wich your are talking about settings for resharing local card,setings for servers,clients,etc.In every post you reconsider what have already posted before , I can't understand what exactly you want to say.
BurnMasterRecords I understand that oscam is not cccam,many users switch from cccam to oscam and they are facing with a lot of trafic generated by oscam.I don't belive that it can't be a solution for oscam to respect the level of cards and "cccam protocol" from oscam to be closer(I didn't say to be exactly) to the original cccam. Otherwise many users will delete from their serves users with oscam.
Forward origin card it suppose to deactivate loadbalancer,but that is not happen .And has no effect about the issue we are trying to explain.
If I give only my local card to a client an set like this (only local card,for testing):
[account]
user = dm600cccam
pwd = cccam
description = Dm600CCcam
group = 1
cccmaxhops = 0
cccreshare = 0

I'm receiving request like this:
2013/02/18 01:58:15 2BC42240 c dm600cccam (1802&000000/0000/04A1/92:4CF981EA457D4A43B8AA5289D27ED980): found (284 ms) by digi (L/1/7/7) (LOCAL CARD,OK)
2013/02/18 02:11:59 2BC42240 c dm600cccam (1802&000000/0000/0D98/92:7A196D14311A12CA527243AAE6A1ABBC): found (287 ms) by digi (L/1/7/7) (LOCAL CARD,OK)
2013/02/18 01:59:10 2BC42240 c dm600cccam (1802&000000/0000/0618/92:62AB195F6544D7353CBC0AA0FBB4827F): found (379 ms) by alin (P/2/2/6) (NOT FROM MY LOCAL!!)
2013/02/18 02:01:41 2BC42240 c dm600cccam (1802&000000/0000/062C/92:4C07B524D6EA1FA1DB6788C7182DBBDF): found (333 ms) by delta (P/1/1/6) (NOT FROM MY LOCAL!!)

Well,how this is happening and why?The client can see only my card and is not suppose to open that channels.
http://oi47.tinypic.com/2s7hzyb.jpg
Anyway the client gets that answers like is from my local!!Hop1!In my oscam you can see that the last 2 answers are not from my (digi) local reader.
My local card is in the same group with all the cards I'm receiving from other servers,but that should not be a problem.
So,test the situation like I have expose above and see with your own eyes.You can put "Forward origin card",or not,it doesn't matter.

comment:51 by zmeura, 11 years ago

And another thing: some of that cards are with level 0.It should not request from them anyway,first becouse I'm not resharing them and second becouse it has level 0.
I know that now you will say: use services.Well,I use services,on my local reader.When I give only my local it can be done,but this was only for testing purpose,normaly I'm resharings cards from hop1 to that client,differend caid's,packages and I can't make list with services opened from cards I receveive becouse .... I don't know what package has my parteners.Services with ! is hard to make,1802 is used in Hungary,Romania,Slo,Tv Cabo,etc.I don't even know wich card is from what country and again what sids are used and wich not.
So,let's say that is hard to stop oscam not to ask from other cards than local,but if is a router just to route this request (from the clients) only to the cards with level 1 or higher and this to be the option no matter what cards are you resharing or not.That was the request in this tiket,there is even this script posted in the begining and (i think) can help us to have this two options:
1.Request from dvbapi no restriction,can go to cards with level 0
2.Request from clients goes only to cards with level 1 or higher

The situation posted above will not be solved 100%,but it will be much better.With this option if I will give only my local card to a client his request still goes to cards from same caid,but only to the ones with level 1 or higher wich I have the right to reshare.Much better and closer to the original cccam protocol.
The example with local card is to see much easier how oscam sends request to the cards it's not suppose to be sent.All this request are going in the same way when I put back cccmaxhops = 1 ,an is the same for all other cards/caids he's receiving from me.If he receive 0b02 the request from him it suppose to go only to cards with level 1,but goes to all cards,level 0,1,2,etc.Router or not oscam is not doing this corectly and if I realy,realy want to be correct with my parteners .... well ,oscam never let me be.

in reply to:  51 comment:52 by zywo, 11 years ago

Replying to zmeura:

And another thing: some of that cards are with level 0.It should not request from them anyway,first becouse I'm not resharing them and second becouse it has level 0.

That is why this ticket is open for.

level = reshare level = maxdown = maxdownhop

comment:53 by zywo, 11 years ago

Resolution: invalid
Status: closedreopened

comment:54 by stefansat sat, 11 years ago

@zmeura

First yes there are many ways to configure. And I only reviewed the doc's, as they where wrong concerning reshare and cccreshare. The doc's are now corrected. (Someone changed the doc's wrongly at some time about the reshare and cccreshare. Read the doc's from latest versions about the use of reshare and share.

NOTE !!! With reshare = 0 and or cccreshare = 0 You are resharing to direct peer. This has always being like that in oscam and is wright as we are speaking abouting resharing not sharing.

0618/92:62AB195F6544D7353CBC0AA0FBB4827F): found (379 ms) by alin (P/2/2/6) (NOT FROM MY LOCAL!!)

This can be avoided by just configuring another group number for alin reader. Again read doc's. You're server is not configured wright.

Use into globaol cccam config (oscam.conf)

reshare = -1

Use by each user account and reader account the cccreshare parameter.

If in global reshare = -1
And also !!!
reshare_mode = 4

Then when You use into a reader account (oscam.server)

cccreshare = -1

The concerned reader will not be reshared trough cccam protocol.
Only the dvbapi will be able to use it.

This last one is something zywo still does not catch or understand.

Further use services to fine tune when using loadbalance or just forward to rigin card then you're cccam module is degraded to basic cccam (but service filters are still avbl).

Again read the doc's and think, Yes it isn't easy, We are working with a multi protocol cam. This cam is compatible with cccam but is not cccam.

Is there room for improvement , Yes always and oscam is continousely in evolution.

Like for the prefer local card's (by me only work's ok for dvbapi client not for other cccam clients. could be improved)

And yes ... Think I keep further comments for me.

Last edited 11 years ago by stefansat sat (previous) (diff)

comment:55 by zywo, 11 years ago

@stefansat:

Sorry, but you still don't understand the bug of this ticket. your posts are useless and you're off topic.

comment:56 by zmeura, 11 years ago

Well,I said 2-3 times that the situation I give as an example is for testing,it's one of the situation generate by this violation of level (maxdown),but normaly I'm resharing to my client cards from hop1,even from "alin".I have cards 1802 from "alin" with reshare level 0 the request are still going to him becouse my local card 1802 is accesible for clients!!I don't want to put "alin" in other group becouse he gives me other cards with reshare level 1 and I want to reshare that cards.Like this I will put every server in different group ,becouse from everyone I get cards with same caid but with different levels.So,what I'm going to do when I want to give a line to client?Well,I'm gonna put to him all groups and I'm back in the same situation!
BurnMaster said "If you have at least one Card with Reshare an other Card with the same CAID Oscam asks all Cards because OScam choose the Cards not the Client." and that is corect,exactly like this is happening.
If I give one card 1702,when a request is comming to my oscam the server ask from all readers that has this cards.Ofcourse,not from all at the same time because I don't use loadbalacer in mode 0,but oscam send this requests to cards with level (maxdown) 0.Do you understand this?
If my oscam choose than we need somehow oscam not to send this request to the cards (or readers?) that is not suppose to send.The simple way is:
1.Request from dvbapi no restriction,can go to cards with level(maxdown) 0
2.Request from clients goes only to cards with level(maxdown) 1 or higher
I think we allready have enough option NOT to respect the levels of cards,so one for respecting it will not harm anyone.Maybe by default in oscam,like it suppose to be for loadbalacing and not to come by default on 0,after that anybody can change this option or use ignore reshare if he wants and not respect his partners option.

The hard way is for oscam to keep traking the distance from were is receiving request,the rights for the client to acces cards (maxdown 0-1-2),compare the distance from were is this request comming with level of cards and send request to them, only.

I will say again: forward origin card does not help respect the level of the cards,I have no ideea what it does,but not this.Test and see that,practice,not just reading from wiki,and you will see that even loadbalancing is still working.
Example:

  • forward_origin_card = 1
  • restart oscam

-2013/04/22 13:28:28 2B113110 c dvbapi (0B02&000000/0000/7725/4C:8B3A1E448A6E11261D6E5E1E68E1BE37): found (282 ms) by cccam (P/1/1/6) -
2013/04/22 13:28:38 2B113110 c dvbapi (0B02&000000/0000/7725/4C:9D8599A51A43C4EC5D5A3FDD532E4A60): found (275 ms) by delta (P/1/1/6) -
2013/04/22 13:28:48 2B113110 c dvbapi (0B02&000000/0000/7725/4C:0B3B3DD9FFAD157CEF5C015CD83344EC): found (203 ms) by george (P/1/1/6) -

So,no help for level,loadbalancer still working .... stop recomand this option.

comment:57 by zmeura, 11 years ago

Again,example from above with forward_origin_card that is not stop loadbalancig (so oscam is not working like a "stupid cccam") it's just to show that forward_origin_card is an option maybe not clear explained or is not doing what is says in wiki.
Back to "maxdown violation problem",wich is not a bug or something else,it's just that oscam violates maxdown.

comment:58 by zywo, 11 years ago

The solution was here 14 months ago: http://www.streamboard.tv/oscam/ticket/2148#comment:7

It needs only to be ported, or at least a patch against current trunk.

comment:59 by stefansat sat, 11 years ago

Very Fun ??

I will say again: forward origin card does not help respect the level of the cards,I have no ideea what it does,but not this.Test and see that,practice,not just reading from wiki,and you will see that even loadbalancing is still working.

Example:

forward_origin_card = 1
restart oscam

-2013/04/22 13:28:28 2B113110 c dvbapi (0B02&000000/0000/7725/4C:8B3A1E448A6E11261D6E5E1E68E1BE37): found (282 ms) by cccam (P/1/1/6) -
2013/04/22 13:28:38 2B113110 c dvbapi (0B02&000000/0000/7725/4C:9D8599A51A43C4EC5D5A3FDD532E4A60): found (275 ms) by delta (P/1/1/6) -
2013/04/22 13:28:48 2B113110 c dvbapi (0B02&000000/0000/7725/4C:0B3B3DD9FFAD157CEF5C015CD83344EC): found (203 ms) by george (P/1/1/6) -

This does not show at all that forward to origin card does not work it's coming from you're dvbapi . If You wan't to prove that something does not work ,

post You're full config's,

here can just be seen that You're dvbapi found the same channel by three readers and uses them one by one.

comment:60 by stefansat sat, 11 years ago

Resolution: invalid
Status: reopenedclosed

I already guesed it, but since to obtain results showns by zmeura, you really need to change some standard settings. That's why obviousely no complete config's of his setup are posted. However this al leaded me to investigate further, and yes some small bugs where found concerning config's.

The first great issue is that using the standard reshare_mode = 0 while at the same times using by some cccam protocol readers services with an !<xxx> ( a not in front) does create unwanted card's into the passed share list to cccam clients this is actually a bug present since long as from svn 5206 . however for some things it'ts needed. to avoid this unwanted side effect reshare_mode= 4 introduced into svn5208. actually placed by schlocke (but was based on a patch from me adapted by schlocke).

To avoid issues in further svn's leading to invalid tickets as this one, I set the reshare_mode=4 as standard in cccam.

Further the introducing of configs trough web-if (Very very nice and good work)did contained some small errors concerning configuration of share and cccreshare parameters. The problems about cccreshare where already solved by me in svn8535 (cccreshare parameter is not cccam protocol binded but does concern al readers resharable trough cccam protocol). A second one just found when configuring trough web-if in global -1 could not be set while it is a possible and actually important parameter) When using -1 no reshare is possible except if reader and account does have the cccreshare parameter. The lowest of those two will be used by ommiting this parameter in a reader and or account the global will be used and if it's -1 the reader will be not reshared trough ccam protocol. or the account will not have any reshare.

Very extensif test's could not let me reproduce the so called violations which are mentionned here as long standard configs are used.

These are

Global config cccam section (oscam.conf)

minimizecards = 0
reshare_mode = 4
ignorereshare = 1

You can omit them all three and they will be standard.

Account config (oscam.user)

cccignorereshare = 0

Ommiting this parameter it will be standard 0

Any other use or change in one off the above parameters will have some side effects which you not really wan't but fore some reasons You wan't to use parameter change. Well up to you to filter out unwanted side effects. And yes this will require a lot of effort and research work.

The svn8631 does contain all the corrections. Upgrade to that version.

This ticket will now be closed again as it was invalid from the first day. Those so called violations are not at all violations but wanted event's that You requested self trough config's of your oscam server and or client. You're changes perhaps also produced for You personnally unwanted side effects, in that case go back standard basic or filter it out.

comment:61 by zywo, 11 years ago

As usual, your post is useless.

The issue is still there.

comment:62 by zmeura, 11 years ago

I don't have time to write here everyday.

I have local card 1802 in oscam,I just put only one cccam line from a friend of mine and cccam line to another receiver,he can receive cards from oscam and another hop.When client is on a channel that my local card can open is like this:

 2013/04/28 10:14:49 2B15DFB8 c dm600cccam (1802&000000/0000/03F6/92:CC23BD7872A52B922DFF9EC6EB4DC2F1): found (287 ms) by digi (L/1/1/2) - Digi24
2013/04/28 10:14:53 2B15DFB8 c dm600cccam (1802&000000/0000/03F6/92:4417F650E367B4357D8F7FA5FD4D8D71): found (282 ms) by digi (L/1/1/2) - Digi24

Open corect from local reader.

If the client is on another chanel than oscam start to ask from share:

2013/04/28 10:09:51 2B15DFB8 c dm600cccam (1802&000000/0000/062C/92:69A9A48982D4696ED53369A83B896932): found (341 ms) by alin - TV 1000
2013/04/28 10:10:02 2B15DFB8 c dm600cccam (1802&000000/0000/062C/92:17AB83315B71ED0B11A09320DC92B698): found (602 ms) by alin - TV 1000 

But in cccam is says that is from hop1,local in oscam!!!

system: Kudelski SA
caid: 0x1802
provider: [N3] DigiTV (1W)
provid: 0x000
pid: 0x15df
using: CCcam-s2s
address: 192.168.1.13:xxxx
'''hops: 1'''
share: 1010101010101010_10000
ecm time: 0.633 

Testing a chanel that is from caid 0b02 (not identical to my local) everything is ok.In oscam:

2013/04/28 10:13:11 2B15DFB8 c dm600cccam (0B02&000000/0000/778E/4C:1DF41ED9682C51593FEAFF191E43418D): found (171 ms) by alin
2013/04/28 10:13:20 2B15DFB8 c dm600cccam (0B02&000000/0000/778E/4C:B69E903BB3125238AD7A0E7216B4144D): found (175 ms) by alin 

At the client (cccam,it doesn't matter):

system: Conax
caid: 0xb02
provider: [Conax] Focus(1W) / Redlight (13E)
provid: 0x000
pid: 0x15e5
using: CCcam-s2s
address: 192.168.1.13:xxxx
'''hops: 2'''
share: xxxxxxxxxxxxxxxx_142ca
ecm time: 0.174 

Corect.But on caid 1802 like my local all respons are shown like are from local.

Let's put to the client cccmaxhops = 0 so he can receive only my card,so if there is no problem with "Oscam "reshares" shares where maxdown is 0" then it should receive only my local.
Well,everything is the same,oscam still ask from share:

2013/04/28 10:25:42 2B277538 c dm600cccam (1802&000000/0000/062C/92:A69D1FFF8E182A44C29784BFC5D26164): found (506 ms) by alin - TV 1000
2013/04/28 10:25:52 2B277538 c dm600cccam (1802&000000/0000/062C/92:5D58743D94B8811875715E044D403657): found (583 ms) by alin - TV 1000 

and gives to client like is from local card:

system: Kudelski SA
caid: 0x1802
provider: [N3] DigiTV (1W)
provid: 0x000
pid: 0x15df
using: CCcam-s2s
address: 192.168.1.13:xxxx
'''hops: 1'''
share: 1010101010101010_10000
ecm time: 0.557 

Oscam SVN 8631.
oscam.conf:

[global]
logfile = /dev/tty
preferlocalcards = 1
lb_mode = 2
lb_min_ecmcount = 2
lb_max_readers = 2

[cccam]
port = xxxx
nodeid = 1010101010101010
version = 2.1.3
reshare = 2
'''forward_origin_card = 1'''


[webif]
httpport = 81
httpuser = xxxx
httppwd = xxxx
httprefresh = 30
httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255 

Readers:

[reader]
label = digi
description = Digi-lower
protocol = internal
device = /dev/sci0
services = digi
caid = 1802
boxid = xxxx
boxkey = xxxx
rsakey = xxxx
ecmwhitelist = 92
detect = cd
mhz = 2700
cardmhz = 450
ident = 1802:000000
group = 1
lb_weight = 1000 

[reader]
label = alin
description = Alin
protocol = cccam
device = xxxx
user = xxxx
password = xxxx
inactivitytimeout = 30
group = 1
cccversion = 2.1.3
cccmaxhops = 2
ccckeepalive = 1
cccreconnect = 0
audisabled = 1 

User

[account]
user = dm600cccam
pwd = xxxx
description = Dm600CCcam
group = 1
cccmaxhops = 0
cccreshare = 1 

-forward origin card = 1
-reshare mode = 4 default
-minimizecards = 0 default
-ignorereshare = 0 (tested also with 1,but no efect regarding to maxdownhop)
-all other settings default

Offtopic: Forward origin card does disable loadbalancing for clients,not for dvbapi and seems to respect level 0 of cards,but no efect with maxdownhop and tunelling request that cames on the caid of local card.That is not specified in wiki and is hard to understand what is going on when you are testing with dvbapi and you see that nothing happend.

Last edited 11 years ago by zmeura (previous) (diff)

comment:63 by zywo, 11 years ago

We are wasting our time, maxdown violation problem can not be solved by any parameter.

The solution is here: http://www.streamboard.tv/oscam/ticket/2148#comment:7

It's just waiting to be integrated into trunk.


comment:64 by stefansat sat, 11 years ago

At first use group control !
Do not set a local reader in same group as local reader as indeed this does create some unintend issues concerning ecm's. I just define another group for each reader.

[reader]
label = digi
description = Digi-lower
protocol = internal
device = /dev/sci0
services = digi
caid = 1802
boxid = xxxx
boxkey = xxxx
rsakey = xxxx
ecmwhitelist = 92
detect = cd
mhz = 2700
cardmhz = 450
ident = 1802:000000
group = 1
lb_weight = 1000

[reader]
label = alin
description = Alin
protocol = cccam
device = xxxx
user = xxxx
password = xxxx
inactivitytimeout = 30
group = 2
cccversion = 2.1.3
cccmaxhops = 2
ccckeepalive = 1
cccreconnect = 0
audisabled = 1

For the user accounts :

[account]
user = dm600cccam
pwd = xxxx
description = Dm600CCcam
group = 1,2 (if You wan't two readers for that acoount or 1 for only reader one or 2 for only reader 2)
cccmaxhops = 0
cccreshare = 1

Use lb_mode = 1 (the mode 2 has always had some side effects. I did not test that mode recently but more then a year ago I did and always had unwanted issues with 1 no problem)

Here under How You server config work's better. (I will use reshare = -1) This allow's me to set the reshare only Reader and account based, May allow me to not reshare a certain reader att all but th's only ussefull if You work with other protocols as well

first a better global config

[global]
logfile = /dev/tty
preferlocalcards = 1
lb_mode = 1
lb_min_ecmcount = 5
lb_max_readers = 500

[cccam]
port = xxxx
nodeid = 1010101010101010
version = 2.1.3
reshare = -1

[webif]
httpport = 81
httpuser = xxxx
httppwd = xxxx
httprefresh = 30
httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255

Readers

[reader]
label = digi
description = Digi-lower
protocol = internal
device = /dev/sci0
services = digi
caid = 1802
boxid = xxxx
boxkey = xxxx
rsakey = xxxx
ecmwhitelist = 92
detect = cd
mhz = 2700
cardmhz = 450
ident = 1802:000000
group = 1
lb_weight = 1000
cccreshare = 1 (note 1 by oscam is like 2 by cccam 0 by oscam is like 1 by cccam -1 here will give value off global config which in this configuration = -1 or no reshare trough cccam from this reader and the same as 0 by orig cccam)

[reader]
label = alin
description = Alin
protocol = cccam
device = xxxx
user = xxxx
password = xxxx
inactivitytimeout = 30
group = 2
cccversion = 2.1.3
cccmaxhops = 2
ccckeepalive = 1
cccreconnect = 0
audisabled = 1
cccreshare = 1

user account

[account]
user = dm600cccam
pwd = xxxx
description = Dm600CCcam
group = 1,2
cccmaxhops = 0
cccreshare = 1
allowedprotocols = cccam
cccignorereshare = 0

By me with such settings the maxhops are respected as well.

Last edited 11 years ago by stefansat sat (previous) (diff)

comment:65 by stefansat sat, 11 years ago

p.s If You only wan't You're local card, set acount group to 1 instead off 1,2

But with ccmaxhops = 0 it even does work by me only my local is taken even if I set all groups avbl to the account.

Use also the latest svn8631

comment:66 by stefansat sat, 11 years ago

Cc: stefansat@… added
Resolution: invalid
Status: closedreopened
Type: enhancementtask

@zmeura, Thank's to the fact that You sended full config's(instead of just yelling and insulting) , I finally was able to reproduce this problem .

I will now reopen this ticket assign it to me but it will take a couple off weeks before it will be applied as extensive test will have to be done.

comment:67 by stefansat sat, 11 years ago

Owner: set to stefansat sat
Status: reopenednew

comment:68 by zmeura, 11 years ago

Thanks an sorry for being so annoying,it was very hard to explain.Please test if it is the same situation with N lines,I think that is.If you put a N line even with services set on it,if it's in the same group with cccam readers oscam will send requests to cccam lines,despite of seting cccmaxdown.Thanks again.

Last edited 11 years ago by zmeura (previous) (diff)

comment:69 by stefansat sat, 11 years ago

Owner: changed from stefansat sat to x
Type: taskdefect

Looking furhter at the code , It should't act like it does. The filter cccmaxhops is not taken into account at all except for building cardlist. Unfortunately an c expert nowing the cccam.c module and reshare perfectly is needed to solve this.

No the N lines have nothing to do with it. But never assign same group for local reader and cccam protocol reader. It's very important to keep that splited . oscam is a multi protocol server that's why . As a work around To this problem You can use the group's and service block's to sort out this unwanted behaviour.

The cccmaxhops should well work while it doesn't . Note even forward to orig card does not work att all anymore. So yes somewhere there is a fault which crept in but my c knowledge is to small to find it.

I deassign me from this ticket but mark it as a bug as that it is.

p.s. the solution off agairs is total unusable, cccam has been completely transformed and changed between the mentioned versions.

comment:70 by zmeura, 11 years ago

I agree,the solution posted here may not be compatible,not perfect solution,but it's solves request sent to cards with level 0 and requests are going only to cards with level larger then 1. As I said ,it could be closer to what we want,not perfect.
Hope that you guys can find a better solution.:)

comment:71 by Deas, 9 years ago

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