Cline to oscam

When working good with cccam than working with oscam too

when I use homesharing use protocol cs378x and all fine

@SpN1986 :

Well, unfortunately I don't know the ARM binaries of the CCcam Softcam. I wrote about the MIPSEL processor / chipset architecture. Sorry. You can try the CCcam binary v2.3.2 or an older version.

Quote from .atari.

When working good with cccam than working with oscam too

when I use homesharing use protocol cs378x and all fine

You have apparently never programmed microprocessors in Assembler or system programming (C language + Assembler). CCcam softcam is diametrically different from Oscam and works in quite different principles. The CCcam algorithm contains outdated source code. Since its source code is closed (it is not open source and is not freely available on the Internet), it is not even possible to improve this code. Oscam Softcam is the exact opposite. Oscam is constantly improving - also in terms of the principles of communication protocols (cccam, newcamd, cx3xxx and others). What you wrote definitely doesn't apply. In softcam algorithms, there are a lot of differences in algorithms, modules, dependencies on system libraries, ... that work differently. However, the main reason is that no one regularly updates CCcam Softcam for Enigma. It has its advantages and disadvantages. For example, the advantage is good and stable functionality, but the disadvantage is many BUGs that hackers and crackers know (guys who read literally machine code under Assembler and know the specific platform under which the code works).

with the stability of the oscam i have never had any problems yet i have addressed the protocol and not the softcam itself!

and yes i know the code i said but that is not the topic here

The speaker never said whether it was a problem locally or as a client!

but as a client there is not much he can do besides looking for the right server :goodevening:

Quote from s3n0

@SpN1986 :

Well, unfortunately I don't know the ARM binaries of the CCcam Softcam. I wrote about the MIPSEL processor / chipset architecture. Sorry. You can try the CCcam binary v2.3.2 or an older version.

I manually installed v2.3.2 for arm, and so far no problems anymore. :)

Quote from .atari.

The speaker never said whether it was a problem locally or as a client!

but as a client there is not much he can do besides looking for the right server :goodevening:

I'm connecting as a client.

Again, thanks for the help guys! :thumbup:

Quote from .atari.

with the stability of the oscam i have never had any problems yet i have addressed the protocol and not the softcam itself!

and yes i know the code i said but that is not the topic here

However, I did not write about the stability of OSCam. The OSCam itself runs fine in Enigma.

Problems only occur when using a particular module or function - in some precise context with something else. Thus, under certain well-defined circumstances, OSCam, for example, may freeze as a client. It can be an error in the incompatibility of system libraries, it can be an error in differences in versions of the cccam / newcamd protocol, it can be an error of specifically used microprocessor instruction sets (mips, mips32el, mips-el, ...), it can be an error of added new special and little tested functions in OSCam, etc. ... the mistake can be anywhere.

You probably don't do very well programming and if so, not as a system programmer ... so you don't even understand the context in different types of algorithms (OSCam-softcam vs. CCcam-softcam). Sorry :-/.

The main problem is that OSCam is constantly evolving and renewing. However, CCcam-softcam is forgotten (I mean cccam as a softcam and not as a protocol). But even the cccam protocol simply needs different types of improvements. However, they may not be compatible with different versions of OSCam. It is complicated.

I am not saying that the problem cannot be solved. But it would have to be solved by some developer of DVB systems who understands DVB technology. It's not me. It is necessary to debug and search for the cause of the freeze, on a specific : device brand and device model, Linux kernel and its libraries, configuration, .... I'm not stupid either :) and I tried an huge number of configurations in 2 weeks. The result was always a frozen OSCam-Softcam in the position of the client (on any protocol). So it's an OSCam binary bug in this particular case.

.atari.

One of the examples that I noticed as a big problem in the connection of two Oscams (in the primary box as an Oscam server and in the secondary box as an Oscam client, CCCAM connection). Here is it:

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

Problem with large times in case of ECM requests:

(on the Oscam softcam side, which is in the position of cccam-client)

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

If I initialize Oscam as a softcam-server on the main box

+ initializing Oscam as a softcam-client on the secondary box,

and as a communication softcam protocol I will use CCCAM,

then there is a problem with too large ECM response times (approx. 200-3000 ms),

on the Oscam softcam side, in the position of cccam-client, in the secondary box.

I tried to solve this in several standard ways.

Restarting the Oscam server and restarting the Oscam client did not help.

Changes in the cccam version of the communication softcam protocol do not help either.

They do not help any other configuration changes on both sides.

However, one trick will help here, as I have found so far:

---------------------------------------------------------------------------------

On the secondary box side, I switch the softcam from Oscam to Cccam (v2.3.0, mipsel) - just for a few seconds.

Then back again - I switch the softcam from the temporary Cccam, again to Oscam.

And from now on, the ECM responses in the secondary box (via Oscam) will be normal again - i.e. approx. 80-90ms.

I don't know why.

Apparently the Cccam-mips-2.3.0 softcam (in client position - on the secondary box) will start sending some "correct" packets via the CCCAM protocol.

It will probably send something to the softcam server that it cannot send to Oscam softcam as a cccam client.

As if this special setting was set by this Cccam-softcam client, in the Oscam-softcam server, via a regular old functional reliable CCCAM protocol.

And then the ECM responses are OK again (approx. 80-90 ms).

-------------------------------------------------------------------------------------

--- devices: Vu+ Solo SE V2 & Formuler F4-Turbo (mipsel chipset at both of them)

--- enigma: OpenATV 6.4

--- softcams: Oscam 11689 & CCcam v2.3.0

--- DVB: SAT / IRDETO

Quote from s3n0

LOL, read my entire post and follow the colors in the text.

The c-line format is:

C: hostname_or_IP port_number your_username your_password

Translated into oscam.server file:

[reader]

label = remote_card_reader

protocol = cccam

device = hostname_or_IP,port_number

user = your_username

password = your_password

cccversion = 2.1.3

audisabled = 0

However, this information should be provided to you by the administrator of the softcam server.

Display More

nice hint, but what do I do having 8 clines? should I write 8 similiar blocks divided by an empty line or something?

Hi.

Exactly so. Just separate them with an empty line for better clarity. It is simple.

You have just to create 8 these readers in the "oscam.server" file. OSCam alone, then selects automatically from the available readers, depending on which one has which CAID provider and available services. OSCam should handle it himself.

However, it will help if you know the CAID for individual readers and add a line to specify the CAID everywhere ( https://wiki.streamboard.tv/wi…/Config/oscam.server#caid ). But it is not necessary.

Also, don't forget to create an internal dvbapi user for local access if you use this OSCam of yours as a softcam-client and at the same time as a softcam+server for your own set-top box.