Card Sharing: setting up CCcam and OScam in 2026

If you already know what card sharing is and why it is needed, this material is for you. There will be no fluff about "smart TVs" and "the future of paid TV." Only configs, file paths, syntax, and diagnostics. We will analyze CCcam and OScam from a sysadmin level: why the channel does not open, what to look for in the logs, and how to properly configure the readers.

What is card sharing and how does the protocol work

Principle of operation: ECM, control word, and dscw

The encrypted DVB stream consists of two layers: the video stream itself and the control packets ECM (Entitlement Control Message). Without decrypting the ECM, the decoder will not receive the control word (CW) — an 8-byte key that descrambles the picture. The CW changes every ~10 seconds (crypto period).

In card sharing, the client receiver sends the ECM to a remote server, which physically has a smart card inserted. The server decrypts the ECM with the card and returns the descrambling control word (dscw). The client inserts the CW into the descrambler and shows the channel. All of this must happen faster than the crypto period changes — hence the criticality of the delay.

Roles of the server and client in the sharing scheme

The server is a receiver or Linux machine with a physical smart card and a running daemon (CCcam or OScam). It listens for incoming connections, processes ECM requests, and distributes CW. The client is any receiver that supports the corresponding protocol, which does not have its own card or the required CAID.

There can be several intermediate nodes between the server and the client — this is called a hop. Hop 1 means that the card is physically on the server to which you are directly connected. Hop 2 — the server itself is a client of another server. With each additional hop, the delay and instability increase.

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

CCcam is a proprietary binary protocol. It operates over TCP, and the data is partially encrypted. The port is set manually in the config (in practice, 12000 is most often used, but there is no strict standard). The protocol supports the transmission of share information about available CAIDs between nodes.

Newcamd (newcs/mgcamd) also operates over TCP, with 3DES encryption, and the port is usually 10000–15000. It was originally created for emulators like mgcamd. It is less flexible in terms of multi-level sharing but more stable in a simple "one server — one client" scheme.

cs378x (also known as camd35 over TCP) is the successor to the UDP protocol camd35, ported to TCP. It is encountered less frequently, but OScam supports it. The default port is often 35354. Some providers still keep cs378x as a backup entry.

Setting up the CCcam server and client

Structure of the CCcam.cfg file and its location

Depending on the firmware, the config is located in different places. On OpenPLi, OpenATV, and most Enigma2 images —/etc/CCcam.cfg. On older Dreambox models with the original firmware, it is often/var/etc/CCcam.cfg. If you are not sure — check both paths or runfind / -name CCcam.cfg 2>/dev/null.

The file is plain text, comment lines start with#. CCcam reads it at startup and upon receiving a HUP signal. The order of lines is not important, but case sensitivity is.

Lines F: for clients and C: for connecting to the server

LineF: describes a local client that is allowed to connect to your server:

# F: username password allow_emm allow_ecm hop_limit

Here:myclient — login,secretpass — password, the first1 — allow EMM, the second1 — enable ECM,2 — maximum hop for sharing to this client.

LineC: describes the connection of your receiver as a client to a remote server:

# C: hostname port username password [no]

The last parameterno — do not use minimal rights for this connection. If the server requiresyes — check with the provider.

The parameters WAIT TIME, hop and share limits

At the beginning ofCCcam.cfg you can set global parameters:

WAIT TIME: 5

WAIT TIME — waiting time for a response from the server in seconds. By default 5, increase to 8-10 with poor ping.MAX HOPS — maximum number of hops for accepted shares. The lower — the better the quality.ECM CACHE LEN — length of the ECM response cache, helps with repeated requests for the same CW.

If you have multiple linesC: for different servers with the same CAID — CCcam will automatically choose the first one to respond. But this can cause conflicts if responses come with different CW (which sometimes happens with long hop chains). It is better to explicitly limit CAID throughIGNORE CAID: or switch to OScam with its fine control over readers.

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

Basic section [global] and web interface [webif] on port 8888

OSCam configs — in the directory. On Enigma2 devices usually/etc/tuxbox/config/oscam/ or/var/keys/. On bare Linux —/usr/local/etc/oscam/ or wherever you installed it. Check:ps aux | grep oscam and look at the argument-c.

Fileoscam.conf, section[global]:

[global]

If port 8888 is occupied by another service — OScam will start, but the web interface will be unavailable. Check:ss -tlnp | grep 8888 ornetstat -tlnp | grep 8888. If occupied — change httpport to 8080 or 9000.

Description of readers in oscam.server (protocols cccam, newcamd)

Each reader is a separate section in the fileoscam.server. Example for connecting via CCcam protocol to an external server:

[reader]

Example for newcamd:

[reader]

Parameterkey for newcamd — DES key provided by your provider. Without it, the connection will not be established. If the provider did not give the key — request it explicitly, otherwise you will waste time debugging.

Parametercaid in the reader limits which CAID this reader will process. Leave it empty — the reader will try to respond to everything that comes, including CAID that it does not have. This is useless and burdens the connection.

Access control in oscam.user and binding to caid/ident

Fileoscam.user describes the clients that connect to your OScam server:

[account]

Parametergroup must match the group of readers inoscam.server — this way OScam understands through which readers this client can receive CW. If the groups do not match — the client will connect, but the channels will not open, and in the log you will seenot found without an explicit reason.

Parameterident — CAID:ProviderID — strictly limits access to a specific provider within CAID. If you don't know the required ident — leave onlycaid, but then the client will have access to all providers of this CAID that are available to the readers.

Fileoscam.dvbapi is needed if OScam operates as a built-in descrambler via DVB API — that is, directly controls the tuner without an external Softcam. It specifiesdevice,pmt_mode and CAID filters. If you are using an external client (mgcamd, CCcam) — this file is likely not needed.

Diagnostics and troubleshooting common issues

Reading OScam logs and decoding ECM status

The log by default is written to/tmp/oscam.log. To view in real time:tail -f /tmp/oscam.log. ECM lines look something like this:

2026/03/15 14:22:31 c (clientname) ECM 0918/000000/1234 found (250 ms) by my_cccam_reader

Statuses:found — CW received, all good.not found — the reader responded, but the card is not available or CAID is inaccessible.timeout — the reader did not respond in the allotted time.rejected — the reader rejected the request (most often due to CAID/ident or group mismatch).

Normal ECM time — consistently up to 300–500 ms. With a good provider with hop 1 and normal ping — 50–150 ms. If you see 800–1200 ms and spikes — expect freezes.

High ECM time and image freezes

Freezes are almost always related to the fact that CW does not arrive before the crypto period changes. Reasons in descending order of frequency: overloaded upstream server, high ping to the server, long hop chain (hop 3+), unstable internet channel.

Check ping to the server:ping -c 20 server.example.com. Check port availability:telnet server.example.com 12000. If telnet hangs — the port is closed or the server is behind NAT without forwarding. If your server is behind NAT — make sure the external port is forwarded to the internal IP of the receiver in the router.

Another source of freezes — multiple readers for the same CAID without fallback logic. OScam sends ECM to several readers in parallel and takes the first response. But if two readers return different CW (which happens with a faulty upstream) — the descrambler receives an incorrect key and the picture breaks up. Solution: explicitly set priority viacccam_priority or distribute readers by CAID.

CW NOT FOUND and rejected errors by caid/provid

CW NOT FOUND In the log — the reader is present, the connection is established, but the card does not respond to the given CAID. Verification algorithm:

• Make sure that the reader linecaid contains the required CAID
• Check that the client's group matches the reader's group
• In the OScam web interface (port 8888), go to Readers → your reader → Cards: make sure the required CAID is there
• Compare the CAID and ProviderID with what the channel signal shows (in Enigma2 — Service Info plugin)

rejected by caid/provid means that the reader does not have rights for this provider. Either the sharing provider did not include the required package in your account, or inoscam.server you explicitly limited ident and specified the wrong ProviderID.

A separate issue is the incorrect system time on the receiver. EMM packets (card rights update) contain timestamps. If the receiver's clock is off by several hours — EMM will not be processed, rights will not be updated, and the channel will close even with a live connection. Check:date on the receiver. Fix:ntpdate pool.ntp.org or configure the NTP client in the firmware.

How to choose a card sharing provider: criteria without names

Stability of ECM-time and server uptime

A normal provider publishes statistics on ECM-time and uptime. Look not at the average, but at the maximum peaks and standard deviation. An ECM-time that mostly stays at 100–200 ms but occasionally jumps to 2000 ms is a bad provider, even if the average looks good.

Uptime below 99% per month is already a reason to think. Serious operators declare uptime of 99.5–99.9%, and they maintain it. Ask the provider for historical statistics, not just "everything is stable with us."

Supported caid, local cards, and hop 1

The key question when choosing: are the cards local or retransmitted? Hop 1 — the card is physically on the provider's server. Hop 2+ — the server itself is someone else's client, and you are already in the chain. With hop 1, ECM-time of 80–150 ms is realistic. With hop 3, you won't achieve a stable 300 ms even with good ping.

Be sure to clarify which specific CAIDs are supported and through which providers (ident). Vague "supports all European packages" is not an answer. You need a specific list of CAIDs like0918:000000, which you will compare with what your receiver shows for the required channels.

Trial period and technical support for protocols

A normal provider gives trial access for 24–72 hours without payment. During this time, you can connect the reader in OScam or CCcam, run logs, check real ECM-time, and verify all necessary channels. Paying without a test is a risk.

Clarify in advance: does the provider support the protocol you need — CCcam, newcamd, or cs378x. Some work only with one of them. If you are setting up OScam and want newcamd with a DES key — but the provider only offers CCcam — this is a compatibility issue that needs to be resolved before payment.

Technical support should understand the difference between "not connecting" and "connecting, but the channel does not open." If the response to a question about group and caid is "restart the receiver" — that is not support.