What is a satellite TV subscription: CCcam and OScam card sharing

In short, what is a subscription to satellite TV viacard sharing: it is when the right to decrypt the encoded satellite signal is no longer tied to a physical smart card in your receiver, but moves to a remote server that provides keys over the network. The receiver makes a request, the server responds, the channel opens. Everything else is implementation details, but ignorance of them leads to freezes, "not found" errors, and hours wasted on forums.

Here I will break down the architecture from scratch: protocols, configs, real file paths, diagnostics through logs. Without fluff and without advertising specific services.

What is a subscription to satellite TV and what does card sharing have to do with it

The satellite operator encodes the transponder with conditional access systems — Viaccess, Irdeto, Nagravision, Conax, BISS, and others. Each package of channels has its own CAID (Conditional Access ID) — a numerical identifier of the encryption system. A subscription is essentially a record in the operator's database that your smart card has the right to receive decryption keys for a specific CAID and provider ident.

Card sharing transfers this verification from the local card to a network server. The server holds the real card, accepts requests from clients, decrypts ECM (Entitlement Control Message), and returns CW — control word, the actual decryption key for the stream. The receiver on the client side applies this key to the video stream and displays the picture.

Classic subscription: smart card and CAM module

In the standard scheme, the operator issues a physical smart card. It is inserted into a CAM module (CI module) or directly into the built-in reader of the receiver. The receiver extracts ECM from the stream, sends it to the card, the card returns DCW (Decrypted Control Word) — and the stream is decrypted locally.

Every 10 seconds (sometimes more often), the operator changes CW — this is called key change. That is why, when there are problems with card sharing, freezes occur strictly every 10 seconds: the new key has not arrived before the change occurs.

What card sharing changes: distribution of control words over the network

Instead of a local card — a remote daemon (CCcam or OScam), to which your receiver connects. ECM from the receiver goes to the server via TCP, the server processes it through the real card, gets DCW, and returns it back. From the decoder's point of view, nothing has changed — it received the key and decrypted the stream.

This is what is called a "network subscription." Understanding what a subscription to satellite TV via card sharing means in a technical sense makes it clear why response time is critical: you have a maximum of a few hundred milliseconds to receive DCW before the next CW change.

How CCcam differs from OScam

CCcam — a closed binary, historically popular on Enigma2 boxes. One protocol, simple configuration through a single file CCcam.cfg. Works well, but has little flexibility: you cannot listen to multiple protocols simultaneously, there is no proper web interface out of the box, and the priority of readers is weakly configurable.

OScam — open source, written in C, supports CCcam, newcamd, camd35, mgcamd, and several other protocols simultaneously. The config is split into several files, there is a built-in web interface on port 8888, fine-tuning of reader priorities and CAID filtering. For the server, OScam is an obvious choice. For the client — also, if the firmware supports it.

How card sharing works technically: ECM, CW, and protocols

Let's break down the full cycle because this is where most configurators get lost. Understanding this cycle explains any problems with freezes and errors.

The ECM → DCW cycle: what happens behind the scenes

The transponder carries an encrypted video stream + ECM packets in a separate PID. The receiver's demultiplexer extracts ECM and sends it to the client daemon (for example, built into Enigma2 or external via softcam). The daemon forwards ECM to the server via the chosen protocol. The server receives ECM, processes it through the card, gets DCW, and sends it back. The client passes DCW to the decoder, which decrypts the stream.

This entire cycle must be completed before the next CW change by the operator. If it doesn't finish in time — freeze. That is why the ping to the server, the load on the server, and the bandwidth directly affect the picture quality.

CCcam protocol (camd35/cccam) and its features

The CCcam protocol operates over TCP, the default port is 12000. It is a binary protocol with a simple format: the client logs in (username/password), after which the server sends a list of available CAIDs. ECM requests and DCW responses are sent over the same connection.

One of the downsides is that the protocol does not work very well behind multiple levels of NAT. If you have double NAT (provider + router), port forwarding 12000 may not help: packets will reach the router but not the receiver. In such a situation, you either need to configure forwarding at two levels or set up a VPN tunnel.

Newcamd, mgcamd, and the role of OScam as a universal daemon

Newcamd is an older protocol, distinguished by the fact that each CAID usually requires a separate port (typically 15000, 15001, 15002, etc.). It is used in older receivers and some CI modules. Mgcamd is another client daemon, popular on older Dreambox.

OScam can work with all these protocols simultaneously. On one server, OScam can open a port for CCcam clients, a port for newcamd clients, and camd35 — and all this will be serviced by one daemon with one set of readers. This is what makes OScam the de facto standard for the server side.

Response time (ECM time) and why it is critical

ECM time is the total time from sending the ECM request to receiving DCW. The normal value is up to 300–600 ms. At 800–900 ms, periodic freezes begin. Above 1000 ms — regular freezes every 10 seconds on most operators.

ECM time is affected by: ping to the server, load on the card on the server (too many clients on one card), channel load, as well as the number of hops — "passing" ECM between several servers in the chain. Each additional hop adds latency. Hop 0 — local card, hop 1 — direct connection to the card owner's server, hop 2 and above — resale.

A separate case is HD channels. They often use a different CAID or require additional entitlement on the card. If SD channels work but HD does not, it is almost certainly not a connection issue, but that the card on the server does not have rights to the HD package.

Basic client and server setup: configs, paths, and ports

Here I will provide real paths and examples of config lines — what is usually lacking in general descriptions.

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

OScam uses several configuration files. On Enigma2 firmware (OpenATV, OpenPLi), they are usually located in/etc/tuxbox/config/. On older firmware or custom builds — in/var/etc/ or/etc/oscam/. Check the specific firmware.

The main file —oscam.conf. Minimal example of sections:

[global]

Readers (cards or key sources) are described inoscam.server:

[reader]

Users (clients that will connect) — inoscam.user:

[account]

Configuring CCcam.cfg on the client

The fileCCcam.cfg on Enigma2 is usually located in/var/etc/CCcam.cfg. On some older firmware — in/etc/CCcam.cfg. The formats differ slightly between versions of Enigma2 and very old firmware like Gemini.

Connection string to the server (C-line):

C: host.example.com 12000 username password

Wherehost.example.com — server address,12000 — port, followed by login and password. The access grant line on the server (F-line):

F: username password 1 0 0 0 { 1801:000000 }

The numbers after the password — hop level, minimum age, and other parameters. In curly braces — allowed CAID and provider ident. Empty braces or their absence mean access to everything on the card.

Port forwarding and working behind NAT

The client does not need to forward ports — it initiates the connection with an outgoing request. Forwarding is needed on the server: so that clients can reach port 12000 (or any other you configured in the config).

On the router, you need to add a DNAT/port forwarding rule: external TCP port 12000 → server IP inside the network, port 12000. If the provider itself does NAT (so-called carrier-grade NAT, CGN), you do not have a public IP and forwarding will not help. The solution is a VPN with an exit node that has a real IP, or IPv6 if the provider supports it.

Checking through the OScam web interface (port 8888)

After starting OScam, open in your browserhttp://IP-сервера:8888. There you can see: the status of readers, a list of connected clients, ECM request statistics, and real-time response times. This is the first place to look during diagnostics.

In the "Readers" tab, the green status of your reader with the card should be lit. If it's red — there is a problem reading the card locally, the network issue has not yet arisen. In the "Users" tab, all connected clients and their activity are visible.

Diagnostics and solving typical problems

Most problems are solved by reading logs, not by reconfiguring everything. OScam writes quite detailed logs.

Channel does not open: reading OScam logs

The default log is/tmp/oscam.log (the path is specified inoscam.conf, parameterlogfile). To view in real time:

tail -f /tmp/oscam.log

Switch the channel and see what appears. A typical successful line looks something like this:

2026/06/18 14:23:01 c [client1] ECM CAID 1801 FOUND (250 ms)

If you seeNOT FOUND orrejected — the key was not obtained. If nothing appears at all — the connection was not established.

Errors FOUND/NOT FOUND and rejected ECM

NOT FOUND means that no reader was able to respond to the ECM. Reasons: there is no card with the required CAID, incorrect provider ident (package subcategory), the card is blocked by the operator, or the ECM request came from an unknown form factor.

rejected — the client was explicitly rejected. Most often: the connection limit has been exhausted, incorrect password, the requested CAID is not allowed for this account inoscam.user.

Multiple CAIDs on one transponder — a separate story. If the channel is multi-encrypted (for example, simultaneously Viaccess 0500 and Irdeto 0602), OScam will try all available readers. Priority is set by thepriority parameter inoscam.server. A conflict arises if the local card and the network reader serve the same CAID — OScam will try to use both, which can cause a race condition. This can be resolved by explicitly specifying priorities or disabling one source for a specific CAID throughcaid = in the reader settings.

High ECM time and image freezes

If the ECM time in the web interface is consistently above 600 ms — look for the bottleneck. Check the ping to the server with the commandping host.example.comIf the ping is normal (up to 100 ms) and the ECM time is high — the server itself is overloaded or the chain is too long (hop 3+).

Freezes strictly every 10 seconds — almost always the ECM time exceeds the CW change period of the operator. The key does not arrive before the next change. The solution is simple: reduce the ECM time (better server, fewer hops, normal channel).

A weak internet channel on the client side also affects, but less — ECM packets are small, a few kilobytes. Even ADSL 1 Mbps is sufficient. The problem is usually with latency, not bandwidth.

Problems with local time and time zone

This point is ignored by almost all guides. Some conditional access systems (especially Nagravision) check the timestamp in the ECM. If the clock on the receiver is significantly out of sync with the real time — the card will return an error, and you will getNOT FOUND out of nowhere.

Check the time on the receiver with the commanddate in SSH. Set up NTP synchronization. On Enigma2, this is done through the settings menu or via/etc/init.d/ntpdate. A discrepancy of more than 2–3 minutes can already cause problems on sensitive systems.

Time zone separately: some demons log time in UTC, while you are looking at UTC+3 — this is not an error, just keep it in mind when comparing timestamps.

How to choose a source of access rights: criteria, not names

Understanding what a subscription to satellite TV via card sharing is from a technical perspective allows for formulating normal criteria for evaluating the access source — without relying on advertising.

What to look at: stability of ECM time and uptime

The main indicator is the stability of ECM time, not its minimum value. A server that always responds in 400 ms is better than one that usually responds in 100 ms but spikes to 2000 ms once an hour.

Uptime is the second criterion. A server that goes down once a week for several hours will be annoying. Before paying for a long period — test it for at least a week.

Hop level: the lower, the better. Hop 1 — direct connection to the card. Hop 2–3 — already intermediaries. Hop 4+ — almost guaranteed to be unstable. A normal provider indicates hops in the description.

Local card vs network access

If you have an official subscription from the operator with a physical card — this is always better from a technical standpoint. ECM time is zero (local reading), there is no dependence on someone else's server, no risk of sudden disconnection. Through OScam, you can even share a local card with several of your receivers in a home network — this is technically an analogous task.

A conflict between a local card and a network reader on the same CAID arises when you have simultaneously inserted your own card and connected to an external server with the same CAID. OScam will try to use both, which creates unpredictable behavior. Clearly set the priority in the config or disable one of the sources for the conflicting CAID.

Signs of an unreliable source

Signs that something is wrong with the source: high hop (3+) without explanations, lack of information about supported CAIDs before payment, refusal to provide a trial period, no feedback when problems arise. Technically, this manifests as unstable ECM time, frequenttimeout in the logs, and regular connection drops.

Another marker — too many clients on one card. The card physically cannot handle an infinite number of ECM requests in a unit of time. If the server is overloaded, ECM time increases for all clients simultaneously.

Legal context and user responsibility

Here, without beating around the bush. Only your own subscription, arranged directly with the satellite operator, is legal. Sharing someone else's access over the network — even if technically it is just the transmission of bytes over TCP — violates the terms of service of the operator and is classified as unauthorized access to paid content in most countries.

This is not a moral judgment — just a fact that needs to be understood before figuring out what a subscription to satellite TV via card sharing is and how to set it up. The responsibility for use lies with the user, not with the developers of OScam or CCcam.