Card Sharing Explained: CCcam & OScam Setup Guide

Card sharing is one of those topics that looks simple on the surface — you've got a smartcard, you've got a network, connect them together, done. Except it's never that clean. The config files have quirks, the group numbers have to match in a way nobody bothers to explain, and when something breaks the error messages tell you almost nothing. This guide covers how the protocols actually work and how to get a CCcam or OScam server running without three days of blind trial-and-error.

What Card Sharing Actually Is

At its core, card sharing is the network transport of a decrypted control word from a physical smartcard to one or more satellite receivers. The card never moves. The data it produces does.

Your broadcaster encrypts video using a control word (CW) that rotates roughly every 10 seconds. To get that CW, your receiver sends an ECM — an Entitlement Control Message — to the smartcard. The card decrypts it (because it holds your subscription entitlements) and returns the CW. Your receiver uses that CW to decrypt the video stream. That's the entire loop, and it happens continuously as long as you're watching.

The control word (CW) and the smartcard's role

The smartcard is a tiny hardware device doing real cryptographic work. When an ECM arrives, the card's processor checks whether your subscription entitlement covers that channel, then decrypts the ECM payload to extract the CW. No valid entitlement, no CW. The card is both the decryption engine and the authorization gatekeeper.

CWs are short — 16 bytes, split into two 8-byte keys for odd and even periods. They change on a schedule baked into the broadcast, so the window for delivering a fresh CW before the current one expires is narrow. High decode latency kills the picture. That's why the latency metrics in the web interface matter so much.

How a sharing protocol relays the CW over a network

The sharing protocol's job is simple: carry ECM requests from remote receivers to the card, then carry the resulting CW back. CCcam and OScam both do this, just with different architectures. The server side holds the card. The client side sends ECMs and receives CWs over TCP.

This is distinct from EMM (Entitlement Management Message) handling, which deals with subscription updates written to the card. Most sharing setups don't forward EMMs by default and don't need to — the entitlements are already on the card.

Server vs client roles in a sharing setup

The server is whatever machine has the smartcard plugged into it — via a built-in reader, a Smargo USB smartcard reader, or a Phoenix-type reader. It runs the daemon (CCcam or OScam) that talks directly to the card hardware. The client is any other receiver that connects to the server over the network and sends ECM requests.

A single server can handle many clients simultaneously. And clients can themselves act as intermediate relays, which is the basis of hop-based sharing in CCcam.

Where CCcam and OScam fit in the stack

CCcam is a daemon that runs on your receiver or a dedicated server. It manages card reading, network connections, and the protocol translation between what your receiver's decryption module needs and what the network delivers. OScam does the same job but is open-source, more configurable, and supports multiple protocols at once. Both sit between your hardware (smartcard reader) and your decryption module (the CAM or built-in descrambler).

CCcam vs OScam: Protocols and Architecture

Both daemons solve the same problem but approach it very differently. If you're running a single card on one receiver, CCcam is simpler. If you're running multiple cards, multiple protocols, or a server that handles a bunch of clients, OScam is the right tool.

CCcam protocol behavior and the newcamd legacy

CCcam is closed-source and was dominant for years on Enigma2 boxes. It uses a proprietary protocol on port 12000 by convention, though you can run it on anything. Sharing is hop-based — each relay between the card and the end client adds a hop. By default CCcam shows hop count in its Info interface on port 16001.

The newcamd protocol predates CCcam and works differently: one line per CAID, requires a DES key, typically runs on port 15000. CCcam can speak newcamd as a client (N-lines in the config) but its native protocol is the cccam one.

OScam's modular reader/client design

OScam separates concerns cleanly. A reader in OScam is a physical or network card source — defined in oscam.server. An account in OScam is a client credential — defined in oscam.user. Services and CAID filtering go in oscam.services. Global settings live in oscam.conf. Each file has a clear role.

The group system is what connects readers to accounts. A reader belongs to group numbers (e.g., group=1,2). An account must share at least one of those group numbers to access that card. Get this wrong and the card connects fine but never serves any ECMs to that client — silently.

Protocol comparison: cccam, newcamd, mgcamd, cs378x

OScam supports all of these simultaneously, each on its own port:

• cccam — CCcam-compatible protocol, conventionally port 12000. Multi-CAID per connection, hop-aware.
• newcamd — older protocol, typically port 15000. Single CAID per line, requires a 14-character DES key in the N-line config.
• cs378x — a newer protocol developed by OScam, port 8888 range by default. Supports the same feature set as cccam but cleaner implementation.
• mgcamd — used by older mgcamd-based receivers, a variation of newcamd.

You define which protocols OScam listens on in the relevant sections of oscam.conf. Running all four costs almost nothing in resources and avoids compatibility headaches.

Why OScam is preferred for multi-reader setups

OScam handles fallback readers, priority ordering, CAID-specific routing, and load balancing across multiple physical cards. CCcam doesn't. If you have two cards covering different packages and want seamless ECM routing, OScam does it natively. The web interface also shows per-reader stats, ECM decode times in milliseconds, and live log tailing — all of which CCcam's Info page doesn't expose with the same granularity.

Setting Up an OScam Server: Config Files Step by Step

OScam's config is all plain text. No GUI needed to set it up, though the web interface helps verify it. Four files do almost everything.

Directory layout: /etc/tuxbox/config/oscam/ and /var/etc/oscam/

The config directory depends on your image. On Enigma2 images running on Dreambox hardware it's often /etc/tuxbox/config/oscam/. On VU+ images and some others it's /var/etc/oscam/. Gemini, OpenATV, and OpenPLi each have their own defaults.

Here's the trap: some images mount /etc/ as a RAM filesystem that resets on reboot, while /var/etc/ persists. Editing the wrong path means your changes disappear on restart. Check which path the running OScam process is using with ps aux | grep oscam — the -c flag shows the config directory if specified, otherwise check the startup script.

oscam.conf — global, monitor, and webif blocks

A minimal oscam.conf that works:

[global]logfile = /tmp/oscam.logmaxlogsize = 200preferlocalcards = 1[webif]httpport = 8888httpuser = adminhttppwd = yourpasswordhttprefresh = 10[monitor]port = 985[cccam]port = 12000[newcamd]port = 15000@CAID:ProviderIdent

The preferlocalcards = 1 setting tells OScam to try local physical cards before forwarding ECMs upstream, which reduces decode time for clients. The webif section gives you the browser interface at http://your-server:8888.

oscam.server — defining your local card reader

Each physical card reader gets a block in oscam.server:

[reader]label = my_cardprotocol = internaldevice = /dev/sci0caid = 0500detect = cdgroup = 1

For a Smargo USB reader the protocol changes to smargo and the device to /dev/ttyUSB0. For a Phoenix-type serial reader use protocol = mouse. The caid field filters which CAIDs this reader answers — leaving it blank lets the reader answer for any CAID on the card, which is usually fine but can cause confusion when two CAIDs share overlapping provider idents.

Watch out for the /dev/ttyUSB0 device node. USB devices don't always enumerate in the same order after reboot. If your Smargo reader suddenly stops being found, check with ls /dev/ttyUSB* — it may have become /dev/ttyUSB1. Fix it permanently with a udev rule tied to the device's USB serial number.

oscam.user — creating client accounts and groups

[account]user = myclientpwd = clientpasswordgroup = 1cccmaxhops = 5au = 1

The group = 1 here must match the group = 1 in the oscam.server reader block. That's the link. If they don't share a group number, the account connects but never gets card access — no error, just silence. This is the single most common misconfiguration I see.

cccmaxhops controls how many hop levels OScam will offer to a CCcam client. Setting it too low silently drops valid cards from upstream. Set it to 10 unless you have a specific reason to restrict it.

oscam.services and CAID/ident filtering

You can define named service groups in oscam.services and then reference them in reader or user blocks to restrict which channels are accessible. The format:

[mysports]caid = 0500provid = 040810srvid = 1234,5678

Then in oscam.user: services = mysports. If a channel's CAID or provider ident doesn't match what's defined here, OScam won't even try the card for it. Black channel, no log entry. This trips up a lot of people — the service filter is working exactly as configured, it's just configured wrong.

Starting OScam and reading the web interface

Start OScam with oscam -c /etc/oscam (or whatever your config path is). Open the web interface at port 8888. The Readers tab shows whether each card reader reports "connected, card inserted." If a reader shows "connected" but not "card inserted", the physical layer is broken — check the device node, the card seating, or the reader hardware itself.

The Status tab shows live ECM activity with decode times in milliseconds. You want consistent times under 400ms. Anything over 800ms and clients will start seeing freezing.

Connecting a CCcam Client (C-line) Correctly

Once the server is running, connecting a client is straightforward — provided you understand what each field in the C-line does.

Anatomy of a C-line: C: host port user password

A C-line looks like this:

C: myserver.example.com 12000 myclient clientpassword

Four fields after the C:. Host can be an IP or hostname. Port must match what's in the server's oscam.conf[cccam] block. Username and password must match an account in oscam.user exactly — case-sensitive. That's it. No DES key, no CAID specification — the CCcam protocol negotiates which CAIDs are available after the connection is established.

Where CCcam.cfg lives on common receiver images

On most Enigma2 images the file is /etc/CCcam.cfg. On some it's /var/keys/CCcam.cfg. OpenATV uses /etc/CCcam.cfg. If you're editing /etc/CCcam.cfg and changes aren't taking effect, same issue as with OScam — check whether /etc/ is a RAM filesystem and your actual persistent config is somewhere else. The CCcam process arguments will show the active config path.

Verifying the share in the CCcam Info webpage

CCcam runs a status page on port 16001 by default. Open http://receiver-ip:16001 and you'll see connected cards, their CAIDs, provider idents, and hop counts. A card showing 0 hops means it's locally inserted. A card at 1 hop came from a directly connected server. Higher hop counts mean more relaying and more latency.

If the CAID you need doesn't appear in the card list, the server either doesn't have that entitlement or the connection isn't fully negotiated yet. Give it 30 seconds after connecting before troubleshooting.

F-line and reciprocal sharing basics

An F-line in CCcam.cfg creates a server account for inbound connections — it's how you offer your own card to others:

F: theiruser theirpassword 1 0 0 0 0 { 0:0:1 }

The trailing fields control hop limits, share limits, and access restrictions. For simple setups the defaults work fine. But reciprocal sharing means someone is also getting ECMs from your card, which affects your decode capacity and latency — factor that in when deciding what to offer.

Troubleshooting: Why the Share Isn't Decoding

Most problems fall into a handful of categories. Match the symptom to the cause and you'll fix it in minutes instead of hours.

Connected but no card / zero hops

The connection to the server established but no cards came back. Either the server has no cards configured, the group numbers between your account and the reader don't overlap, or cccmaxhops is 0. Check the server's OScam web interface — does the reader show "card inserted"? Does your account share a group number with that reader? These two misconfigurations account for probably 60% of "connected but nothing works" reports.

ECM timeouts and high decode times

OScam shows ECM decode times in the Status tab. If you're seeing "found (1200 ms)" or "timeout", the problem is latency — either the upstream server is overloaded, the network path is slow, or there are too many hops. Each hop adds round-trip time. A card at 3 hops over a slow connection might add 200–300ms per hop, easily blowing past the crypto period window.

You can run OScam with verbose logging using oscam -d 255 to see the full ECM lifecycle. That's noisy but useful for isolating exactly where the delay happens.

CAID/provider mismatch and channel freezing

Channel freezes every 10 seconds or so. Classic CW-late symptom — the old control word expired and the new one hasn't arrived yet. But it can also mean the card is answering ECMs for the wrong CAID or the wrong provider ident.

Some packages have two CAIDs for the same content — one for new subscribers, one for legacy smartcards. OScam might be routing ECMs to a card that has the CAID but not the specific provider ident for your subscription tier. Check the channel's exact CAID:ProviderIdent in the OScam log and verify it matches an entitlement on the card.

Firewall, NAT, and port forwarding issues

Connection refused means port 12000 (or whatever port you're using) isn't reachable. On a home connection you need to forward the port on your router. But there's a harder problem: ISP-level CGNAT. If your ISP puts you behind carrier-grade NAT — common on mobile broadband and increasingly on residential fiber — you don't have a routable public IP at all. Port forwarding won't work. You'd need a VPN tunnel or a VPS to relay connections through a real public IP.

Check whether you have CGNAT with curl ifconfig.me on the server, then compare to what your router reports as its WAN IP. If they differ, you're behind CGNAT.

Also confirm you're not running both CCcam and OScam bound to the same port. If both daemons try to bind port 12000, the second one fails with a bind error and all connections go to the first. Check with ss -tlnp | grep 12000.

Reading OScam logs and ECM responses

OScam's log is your primary diagnostic tool. Enable it with logfile = /tmp/oscam.log in [global]. Key lines to look for:

• found (150 ms) — ECM answered successfully, 150ms decode time. Good.
• not found — card was reached but has no entitlement for this CAID/ident.
• timeout — card didn't respond in time. Network or hardware issue.
• no matching reader — no reader in the right group for this CAID.

The "not found" vs "timeout" distinction matters. "Not found" is an authorization problem — the entitlement isn't there. "Timeout" is a connectivity or performance problem. They have completely different fixes.

Choosing a Card Source Without Getting Burned

A local card you physically own is the only source that gives you full control and zero dependency on a third party's uptime. For self-hosted card sharing setups, that's the baseline to aim for.

Self-hosted local card vs a remote shared line

A physical smartcard in a reader attached to your server means zero hops, the lowest possible decode latency (typically under 50ms), and no dependency on someone else's network or infrastructure. The downside is you need a valid subscription for each package you want to decode.

A remote line means you're dependent on whoever runs the upstream server — their hardware, their network, their uptime. Every hop adds latency and a failure point.

Generic criteria for a reliable upstream

If you're evaluating an upstream source for a card sharing arrangement, these are the metrics that actually matter:

• ECM decode time — should be consistently under 400ms. Not 400ms average with spikes to 2000ms. Consistent.
• Hop count — fewer hops is better. A card at 1 hop over a low-latency connection beats a "local" card with a slow reader every time.
• CAID and provider ident coverage — the share must cover the exact CAID:ProviderIdent for your target package. "Supports Sky" means nothing if it's the wrong ident for your regional feed.
• Server load — an overloaded server that handles too many simultaneous ECM requests will deliver late CWs during prime viewing hours. If a line works fine at 2pm but freezes at 8pm, the server is oversold.
• Test period — any credible source offers a test before commitment. If there's no way to verify the line works for your specific channels before paying or committing, that's a problem.

Red flags in any sharing arrangement

A line that claims to deliver 500 CAIDs from a single connection is almost certainly forwarding through a chain of relays. More hops, more failure points, higher latency. Avoid.

Frequent CW changes (separate from normal crypto period rotation) can signal an unstable card or reader that's cycling. If decode times are all over the place — 200ms then 1500ms then 300ms — the upstream is unreliable.

And if a server has no web interface, no status page, no way to verify decode times or card status, you're flying blind. The OScam web interface exists for a reason. A properly run server exposes enough info for clients to diagnose their own issues.

Stability metrics that actually matter

Uptime percentage is nearly meaningless — a server could be "99.9% up" but have a reader that drops the card every hour for 30 seconds, causing constant freeze cycles for anyone watching live TV. What actually matters is consistent ECM response time across the full day, especially during peak hours, and whether the card entitlements stay valid without unexpected gaps.

Watch the OScam Status tab for a few hours with a live channel running. The decode time column tells you more than any uptime claim ever could.