Настройка шаринга: CCcam и OScam с нуля (2026)

At first glance, setting up sharing seems simple — you copy a line, restart the daemon, and everything works. In practice, half of the instructions are outdated, and the other half explains "what to write," but not "why exactly this way." Let's break it down properly, with an explanation of each parameter.

What is sharing and what does it consist of

Card sharing is not magic and not hacking. It is a specific technical process of data exchange between a client and a server over a network.

Principle of operation: ECM, CW, and key exchange

The receiver receives an encrypted stream from the satellite. To decrypt it, a Control Word (CW) is needed — a pair of 8-byte keys that change every 10 seconds. The receiver forms an ECM request (Entitlement Control Message) and sends it to the server. The server processes the ECM through a real smart card and returns the CW. The receiver decrypts the picture.

The entire cycle must fit within a few hundred milliseconds. If the response takes longer — freezes begin, because the old CW has expired, and the new one has not yet arrived.

Roles of the client and server

The server holds the physical card in the reader and listens for incoming connections. The client is your receiver, which connects to the server, sends ECM, and receives CW back. The client knows nothing about the card — it simply makes requests.

In OScam, the same daemon can work simultaneously as a client (through the reader section) and as a server for other devices. CCcam works similarly, but is less flexible in terms of configuration.

What are the differences between CCcam, newcamd, and CS378x protocols

CCcam is a proprietary protocol, default port 12000. Widely supported by Enigma2-based receivers. Easy to set up, but closed and with limited diagnostics.

Newcamd is an older open protocol, with the port usually in the range of 10000–15000. Used in many OScam configurations as an alternative to CCcam. CS378x (also known as camd35) is another protocol, less common, but found on some servers. In OScam, all three are natively supported through theprotocol parameter in the reader section.

Setting up the CCcam client: CCcam.cfg file

CCcam.cfg is the main configuration file for the client. Here you specify server connections, reshare settings, and restrictions. This is where most questions arise during the initial setup of sharing.

File location: /var/etc/CCcam.cfg

On Enigma2 receivers (Dreambox, VU+, Formuler, and others), the file resides in/var/etc/CCcam.cfg. Some images (for example, OpenPLi or OpenATV of certain versions) may place it in/etc/CCcam.cfg or even in/usr/etc/CCcam.cfg.

If you are not sure — executefind / -name CCcam.cfg 2>/dev/null via SSH. It will find it in a second. It is more convenient to edit via FTP using FileZilla or WinSCP than through telnet.

C: line — syntax and parameters

The client line looks like this:

C: hostname 12000 username password no { 0:0:0 }

Each field has meaning. Do not copy the line blindly — break it down once, and then everything will be clear.

Parameters hostname, port, username, password

hostname — the domain name or IP of the server. Use the domain if the server provides it — it is more resilient to IP changes.port — the port on which the server listens for CCcam connections, most often 12000, but it can be anything.username andpassword — credentials provided by the service provider.

After the password comesno — this is the EMM activity flag (card management messages).no means that EMMs are not sent — in most cases, this is exactly what the client needs.

Options hop, no-emm and share limits

Curly braces{ 0:0:0 } define the hop parameters, minimum and maximum hop during reshare. The value0:0:0 means "no restrictions". If the server is set up for reshare with hop=1, then in your config this will be the first level of the chain.

Long hop chains (hop 3, 4 and above) are a direct path to freezes. Each additional node adds latency. A local card (hop 0) is ideal, first-level reshare (hop 1) is still acceptable.

Global parameters in CCcam.cfg are set by separate directives:

CLIENTMAXHOPS: 3

CCCAM RESHARE: 0 prohibits your receiver from sharing the card further. For a regular client — correct.

OScam configuration: oscam.server, oscam.user and oscam.conf

OScam is more complex than CCcam in configuration, but it provides full control and proper diagnostics. Setting up sharing through OScam requires correct interaction of three files — miss one parameter, and nothing will work.

Directory /etc/tuxbox/config or /var/etc/oscam

OScam configs are located in one of two places depending on the image:/etc/tuxbox/config/ (old images, Dreambox) or/var/etc/oscam/ (OpenPLi, OpenATV, VTi). Some builds place them in/usr/keys/.

Run OScam with an explicit directory specification:oscam -b -c /etc/tuxbox/config. The key-b — background mode,-c — path to the directory with configs. This way you know exactly where it reads the files from.

Section [reader] in oscam.server for connecting to the server

Fileoscam.server describes which servers to connect to. For the CCcam server, the section looks like this:

[reader]

label — arbitrary name of the reader, used in logs.protocol = cccam specifies the protocol.device — host and port separated by a comma without spaces.cccversion affects how the reader is presented to the server — some servers are picky about this parameter, try 2.3.0 or 2.2.1.

For the newcamd server, the protocol changes tonewcamd, the parameterkey with a DES key (14 bytes in hex) is added. For CS378x —protocol = cs378x.

The oscam.user file and the group parameter for linking readers

This is where most stumble. The parametergroup inoscam.server andoscam.user must match. If the reader is in group 1, and the user is in group 2 — CW will not be received. This is often what causes the situation "connected, but channels do not open."

Example of a user inoscam.user:

[account]

If you have multiple readers in different groups, you can assign multiple groups to the user:group = 1,2,3.

Web interface: oscam.conf and httpport (usually 8888)

The OScam web interface is the main diagnostic tool. It is enabled inoscam.conf:

[webif]

After restarting the daemon, open a browser athttp://ip-receiver:8888. There you can see the statuses of the readers, the ECM table in real time, and logs. Diagnosing problems without the web interface is a torment.

httprefresh = 10 — auto-refresh of the page every 10 seconds. Convenient for debugging.

Checking operation and reading logs

Started, not working. What next? Checking the logs is the only correct answer. Guessing what went wrong without a log is a waste of time.

Where the log is located: /var/log/oscam.log and CCcam logs

OScam writes the log to the location specified inoscam.conf in the section[global]:

[global]

Iflogfile is not specified — the log goes to stdout. CCcam writes to/tmp/CCcam.log, if the parameter is setLOGFILE: /tmp/CCcam.log in the config. To monitor the log in real time:tail -f /var/log/oscam.log.

How to understand the card status via the OScam web interface

In the web interface, the "Readers" section shows the status of each reader.connected — network connection established.emu or a specific CAID list next to the reader's name — the card is active and providing keys.

If you seedisconnected — network problem: incorrect host, port, or credentials. Ifconnected, but the card column is empty — the server is connected, but either there are no rights or it does not provide the required CAID to this account.

Decoding ECM time and found/not found messages

In the OScam log, ECM lines look something like this:

2026/03/15 21:43:02 c (account) ECM 09C4 found (123 ms) by myserver

09C4 — CAID (conditional access system identifier).found — CW received. The number in parentheses is the response time in milliseconds.

ECM time up to 300 ms — good. 300–600 ms — acceptable. Above 700 ms — freezes will start on channels where CW changes every 10 seconds. If you seenot found — the server could not decrypt this ECM. Either there are no rights for this channel, or the CAID is not supported.

Typical errors and their resolution

Most problems fall into a few scenarios. Here they are in order from the most common.

Server connected, but channels do not open

This is classic. The network connection is there, but the CW does not arrive. There are several reasons:

• Invalid parametergroup in OScam — the reader and user are in different groups
• The required CAID is missing from the server's output — the server does not hold a card for this package
• Reshare restrictions on the server — the account is set up without rights to specific channels
• In CCcam.cfg, the CAID filter is incorrectly specified in curly braces

First of all, check the log forECM not found. If this is the case — the problem is not with the connection, but with the rights.

Connection error: incorrect port or firewall

To check if the port is accessible from your machine, the easiest way is through:

telnet hostname 12000

or

nc -vz hostname 12000

If the connection hangs or immediately fails — the port is closed. Possible reasons: firewall on the server, firewall on your router, the provider blocks non-standard ports. Try from another network (mobile internet) — it will become clear immediately whether your provider is blocking or not.

If the receiver is behind NAT/CGNAT and port forwarding is needed for incoming connections — contact your provider for a dedicated IP. With CGNAT, port forwarding on the router will not help because the external IP is shared with other subscribers.

Freezes and high ECM time

High ECM time is the first thing to measure during freezes. Check the log or the ECM table in the OScam web interface. If the time is consistently above 600–700 ms, the reasons are:

• Long hop chain (hop 3–5) — each node adds delay
• High ping to the server — checkping hostname
• Server overload — too many clients, ECM queue is growing
• Unstable communication channel — packet losses

Solution: look for a server with a local card, minimal hop, and stable response time. Limiting the number of active readers in OScam throughmaxhops also helps.

Conflict of several readers and priorities

If you have two readers with the same CAID, OScam will query them by default in the order declared inoscam.server. To explicitly set the priority, use thecaid parameter in the reader section and thelb_mode parameter in[global]:

[global]

Load balancing mode 1 — OScam selects the best reader based on ECM time statistics. This works well when the servers are genuinely different in quality.

For fallback (primary + backup), specify priorities throughweight in the reader section. A reader withweight = 10 will be used more often than one withweight = 1.

A special case is a local card in the receiver's card reader plus an external server. The local reader should have a higher priority. In OScam, this is configured throughcacheex and the order of sections[reader]. Place the local reader first.

Sharing configuration: how to choose a server based on technical criteria

Without a good server, even the perfect config won't help. But you need to choose based on specific parameters, not on a nice website.

Stability of ECM time and uptime

ECM time is the main indicator of quality. A good server consistently provides 50–200 ms. A bad one fluctuates from 100 to 2000 ms throughout the day. Fluctuations are more important than the average value: they cause occasional freezes.

Check uptime not over a day, but over a week or month. A server with 95% uptime means ~36 hours of downtime per month. For normal use, you need 99%+.

Support for required packages and local cards

Make sure the server holds the local card (hop 0) for the packages you need — this can be checked in the OScam web interface or from the provider's information. Reshare of the second level and above means it's someone else's card that someone else is sharing. The quality is predictably worse.

The list of supported CAIDs should match what your receiver needs to open specific channels. Standard CAIDs for popular European packages are 0x0500 (Viaccess), 0x0D00 (Cryptoworks), 0x1800 (Nagravision), 0x0B00 (Conax).

Backup servers and overload protection

A normal provider gives at least two addresses — primary and backup. In OScam, this is implemented through two readers with the same parameters and load balancing. In CCcam.cfg — two C: lines with different hosts.

Limiting the number of connections per account is standard practice. One account per device is a reasonable expectation. If the provider allows multiple simultaneous connections on one account, clarify the limit — exceeding it usually leads to blocking or degradation of quality.