Card Sharing Explained: CCcam & OScam Setup Guide

Card sharing is the network-level distribution of decrypted control words from a smartcard to one or more satellite receivers. If you've hit a wall trying to get your CCcam lines connecting or your OScam server won't authenticate clients, the problem is almost always in the details — wrong CAID, misconfigured reader block, or a port that was never forwarded. This guide walks through the actual mechanics and real config syntax so you can diagnose and fix issues without the usual trial-and-error.

I've spent a lot of time staring at OScam logs and digging through /etc/tuxbox/config/ on various Enigma2 builds. What follows is the technical grounding most setup guides skip entirely.

What Card Sharing Actually Is (Protocol-Level)

At the network level, card sharing works by proxying the smartcard decryption process over TCP. Your receiver normally talks directly to a local card; card sharing replaces that local path with a network hop to a machine that has the physical card inserted. The decryption result — the control word — comes back and your receiver uses it like nothing happened.

The Control Word (CW) and Why It Must Be Shared Every Few Seconds

Every encrypted broadcast stream is scrambled using a Control Word — two 8-byte halves that together make up the 16-byte key. The broadcaster rotates this CW roughly every 7–10 seconds to limit exposure. The upcoming CW is actually embedded in the stream slightly ahead of when it's needed, inside an Entitlement Control Message (ECM).

Your receiver extracts the ECM, sends it to the smartcard (or, in a card sharing setup, across the network to the card server), and the card decrypts it and returns the CW. If that round trip takes longer than the rotation window, you get a freeze. That's the entire reason ECM time matters — you're racing a 7-second clock.

Client/Server Roles and the ECM/EMM Request Flow

In a card sharing setup the server holds the physical smartcard. When a client receiver tunes to a channel, it intercepts the ECM from the broadcast stream and sends it upstream to the card server over the sharing protocol. The server passes it to the card, gets the CW back, and relays it to the client, which uses it to descramble the video.

EMM — Entitlement Management Message — is a separate layer. EMMs carry subscription updates from the broadcaster, keeping the card's entitlements current (pay-per-view events, renewal signals, tier updates). If your setup doesn't forward EMMs back to the card, you'll eventually find the card loses channels after a renewal cycle. In OScam this is controlled by the au flag in oscam.user.

CCcam vs OScam vs MGCamd vs Newcamd at a Glance

OScam is almost always the right choice for running a server. It's actively maintained, has a web monitoring interface, writes detailed logs, and speaks every protocol clients could want. CCcam-protocol C-lines for client-side configuration remain the most universally supported format for connecting to a server.

Where the Physical Smartcard Fits In

The smartcard is the actual authorization root. Everything else is just a proxy. The card holds the keys granted by the broadcaster and performs the ECM decryption locally — no card, no CW. On the server side the card sits in a smartcard reader: a built-in receiver slot (internal protocol in OScam), a USB PCSC reader like a SCR3310, or a serial reader. The card reader type determines your protocol line in oscam.server.

Setting Up an OScam Server From Scratch

OScam's config is split across several files, which trips up most first-time setups. The key insight is that every major function — the reader, the users, the protocols, the global settings — lives in its own file. Get the file paths right first and everything else follows.

Compiling or Installing OScam and the Config Directory Layout

On Debian/Ubuntu you can grab a precompiled binary or build from the OScam SVN repo. The build target you want for most server setups includes WITH_LIBUSB for PCSC support and WITH_SSL if you plan to use encrypted client connections.

The config directory location varies by image. Common paths:

• /etc/tuxbox/config/ — Enigma2 images (OpenATV, OpenPLi)
• /usr/local/etc/ — generic Linux installs
• /var/keys/ — some older DM images

You can always tell OScam explicitly where to look: oscam -c /your/config/path. Do this in your init script so you're never guessing which directory is actually being read.

oscam.conf: Webif, Global, and Logging Blocks

A minimal oscam.conf for a server with the web interface enabled:

[global]nice = -1maxlogsize = 500logfile = /var/log/oscam/oscam.log[webif]httpport = 8888httpuser = adminhttppwd = changemehttpallowed = 127.0.0.1,192.168.0.0-192.168.255.255

Set httpallowed to your LAN range. Don't leave the web interface open on a public IP without authentication. The nice = -1 line bumps OScam's scheduler priority slightly, which can help on loaded boxes.

Once OScam is running, hit http://serverip:8888 in a browser. The web interface shows reader status, active users, ECM response times per request, and the live log — this is your primary debugging tool and most guides ignore it entirely.

oscam.server: Defining Your Local Reader (PCSC, Internal, Serial)

This file defines the physical card. For a built-in reader on an Enigma2 box:

[reader]label = local_cardprotocol = internaldevice = /dev/sci0caid = 0500detect = cdgroup = 1emmcache = 1,3,2

For a USB PCSC reader (SCR3310 or similar):

[reader]label = usb_readerprotocol = pcscdevice = 0caid = 1810detect = cdgroup = 1

The caid value is the Conditional Access ID in hex. Get this wrong and OScam will see the card but route ECMs to it incorrectly, causing silent decryption failures. Check the card's actual CAID by connecting to the web interface — under Readers, a detected card shows its reported CAID. Cross-check it against what you put in the config.

One edge case worth knowing: if you have multiple readers defined with overlapping CAIDs, OScam will try to route ECMs based on its load-balancing rules. This can mean ECMs go to a secondary card that doesn't actually hold the entitlements. Assign distinct group values and use group assignments in oscam.user to pin users to specific readers.

oscam.user: Creating Accounts and CAID/Ident Assignment

[account]user = client1pwd = secretpassgroup = 1au = local_cardcaid = 0500ident = 0500:042800,042100

The au field is where a lot of setups quietly fail. It needs to point to a reader label from oscam.server. Without it, EMMs from the broadcaster don't reach the card, and after the next subscription renewal cycle the card stops decrypting. The card's entitlements just silently expire.

The ident field accepts provider identifiers in the format CAID:ident1,ident2. If the broadcaster updates CAID or ident after a card software update — which does happen — your previously working setup breaks without any obvious log error beyond "no matching reader".

Enabling the CCcam Protocol with [cccam] and Port Binding

Add this to oscam.conf to make OScam accept CCcam-protocol client connections:

[cccam]port = 12000reshare = 1reshare_mode = 0version = 2.3.0build = 11559

The reshare value controls how many hops a CW can travel from this server. Setting it to 1 means clients can use the card but cannot reshare it further. The version and build fields matter: a version mismatch between the server's reported version and what the client expects can cause handshake failures, especially with older Enigma2 CCcam builds. If a client connects but immediately drops, try adjusting these to match the client's CCcam version.

Connecting a CCcam Client (Line Syntax & Ports)

The C-line is the entry point for any card sharing client. Get the format exactly right — CCcam is not forgiving about whitespace or field order.

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

C: server.example.com 12000 myuser mypassword

Breaking down each token: C: declares this as a CCcam server line. The hostname (or IP) is next, then the port the server is listening on, then username and password matching an account in oscam.user (or CCcam.cfg on the server side). That's it for basic connectivity.

Extended flags come after the password. no disables wakeup packets; the fifth field (a number) controls EMM forwarding. For most setups the four-token form above is all you need.

Where CCcam.cfg Lives and How the Receiver Reads It

On Enigma2 boxes running CCcam, the config is typically at /var/etc/CCcam.cfg. Some builds use /etc/CCcam.cfg — SSH in and check both. The receiver reads this file at startup and after a CCcam restart (via the plugin menu or init.d). Changes don't take effect until CCcam restarts.

If you're running OScam on the receiver as the client (connecting to a remote OScam server), the equivalent lives in oscam.server as a protocol = cccam reader block pointing to the remote host.

F-lines, N-lines, and Reshare Hop Limits

F-lines in CCcam.cfg define what this receiver reshares to downstream clients:

F: clientuser clientpass 1 0 { 0:0:0 }

The fields after the credentials are downhops and uphops. Downhops controls how far the CW propagates downward from this node; uphops is how many hops back upstream the client can see. Most servers cap reshare at hop 1 or 2 deliberately — deep reshare chains add latency at each hop, and if the chain is long enough the CW can arrive after the rotation window, which causes freezing.

N-lines are for Newcamd protocol connections and include a per-user DES key:

N: server.host 10000 user pass 01 02 03 04 05 06 07 08 09 10 11 12 13 14

High reshare hop counts are a common hidden cause of intermittent freezing. A setup might work fine at low viewer counts and start freezing when the server gets busier, because queued ECMs add a few hundred milliseconds to each hop in the chain.

Testing a Line and Reading the Connection Status

On an Enigma2 receiver running CCcam, navigate to the CCcam Info panel (usually under Plugins → CCcam Information). You'll see each server line with its connection status, the number of cards visible, and — most importantly — the ECM response time in milliseconds.

A healthy ECM time is generally under 400ms. Under 200ms is solid. If you're seeing 600ms or above, expect freezes. Consistently rising ECM times point to server load or network congestion, not a config problem. A flat high number (say, always 800ms) suggests geographic distance or packet routing issues.

Troubleshooting: No Channels, Freezing, and 'Card Not Found'

Most card sharing problems fall into three buckets: the CW isn't arriving at all, the CW is wrong, or the DVB tuner itself has a signal problem that has nothing to do with card sharing. Mixing these up wastes hours.

Black Screen vs Scrambled Channel — Diagnosing the Difference

A scrambled or blocky picture (not a clean black screen) means the channel is tuning correctly but decryption is failing. The signal is there; the CW isn't. A clean black screen is more likely a tuner issue — wrong transponder frequency, bad LNB voltage, or a SID that's simply not in the card's entitlements at all.

Before blaming card sharing for a black screen, check signal strength and SNR/BER in the receiver's tuner diagnostics. Card sharing cannot fix a weak or missing signal. An LNB connection issue, a wrong DiSEqC setting, or a dead LNB cable looks identical to a subscription problem from the user's perspective but has nothing to do with the card.

CAID/Provider Mismatch and Reading the Right Local Card

The "no matching reader" log entry in OScam is your diagnostic starting point. It means an ECM came in for a CAID/ident combination that no reader is configured to handle. Pull up the OScam web interface, go to the live log, and look for the CAID and ident values in the failed ECM line. Compare them to your oscam.server reader block and oscam.user ident assignment.

Broadcasters occasionally update CAID or provider ident values alongside card software updates. A card that decoded everything fine for months suddenly stops after an OTA update, and the only clue is that the CAID in the ECM log no longer matches oscam.server. Update your CAID and ident values to match what the live log reports.

Firewall, NAT, and Port-Forwarding for Self-Hosted Servers

If you're hosting an OScam server and clients outside your LAN can't connect, the port needs forwarding on your router. For a server listening on port 12000:

# iptables exampleiptables -A INPUT -p tcp --dport 12000 -j ACCEPT

On your router, forward TCP port 12000 to the server's local IP. Verify with netstat -tlnp | grep 12000 on the server that OScam is actually bound to that port.

CGNAT is a separate problem. If your ISP puts you behind carrier-grade NAT, your public IP isn't yours — it's shared across multiple customers. You can connect outbound as a client just fine, but inbound connections to your "public" IP never reach your server. The only real options are a VPN with a dedicated IP, a VPS as a relay, or switching to an ISP that provides a real routable address. There's no port-forwarding trick that fixes CGNAT from the router side.

MTU, Latency, and Intermittent Freezing

Intermittent freezing that happens every 7–10 seconds almost exactly tracks the CW rotation. The new control word isn't arriving before the old one expires. Start with ECM time in the receiver's info menu — if it's consistently over 400ms, that's your problem.

MTU mismatches on certain ISP connections can fragment TCP packets in a way that adds latency specifically to small, time-sensitive payloads like CW responses. If you've ruled out server load and geographic distance, try setting the MTU on your server's network interface to 1460 or 1452 and see if ECM times stabilize.

Packet loss is more destructive than latency here. Even 1–2% loss on the path between client and server means some CW responses get dropped or retransmitted, and a retransmitted CW response after the rotation window means a freeze. Use mtr or ping -f to check the path for loss before chasing config issues.

Reading OScam Logs to Pinpoint the Failing ECM

Enable detailed logging with oscam -d 255 or via the web interface (Config → Logging, set log level to debug). Then grep for the channel's SID or CAID:

grep -i "no matching reader" /var/log/oscam/oscam.loggrep -i "CW" /var/log/oscam/oscam.log | tail -50

Key log phrases to know: "no matching reader" means the CAID/ident routing failed. "rejected" after a user line means authentication is failing — wrong password or the user account doesn't exist. "DCW checksum error" is hardware: your smartcard reader is returning corrupt data, usually from oxidized card contacts or a flaky PCSC USB reader. Clean the card contacts with isopropyl alcohol, or try a different reader.

Receiver clock issues are an underrated cause of log confusion. If the server's system time is significantly off (say, 20+ minutes), auth logs show rejections that look credential-related but are actually timestamp-based. Run ntpdate -u pool.ntp.org or enable NTP in your system config and make sure the clock is synced before blaming credentials.

Choosing a Server Source: Criteria, Not Names

The fundamental question when evaluating any card sharing source is: how much of the chain do you control? Local card ownership and remote line rental are genuinely different situations with different failure modes.

Local Card vs Remote Line — What You Actually Control

With a physical card in your own reader, you control everything. EMM updates reach the card directly, you can see the reader status in OScam, and you're not dependent on anyone else's uptime. The downside is cost and the requirement to have a valid local subscription.

A remote line means someone else owns the card and runs the server. You get a C-line, add it to your config, and it either works or it doesn't. If their server goes down, you have no visibility into why and no way to fix it. Their card needs to receive EMMs too — if the card-holder's setup doesn't properly handle EMM forwarding, you'll see channels drop after subscription renewal periods even if the connection itself looks healthy.

Stability and Uptime Indicators to Evaluate

When evaluating any card source, the most useful test is a trial period where you actively watch ECM times under different loads — evening prime time is harder on a server than off-peak hours. A source that returns 80ms ECM times at 2am may hit 600ms at 8pm when concurrent clients peak.

Connection drops that require manual C-line restarts are a red flag. OScam will auto-reconnect, but a server that drops connections regularly indicates instability somewhere in their infrastructure. Watch the OScam web interface "Clients" tab for frequent connect/disconnect cycles on your own users as a proxy for how stable the server behaves under load.

Reshare Depth, CAID Coverage, and What to Verify

A provider advertising a long CAID list should be verified against what you actually need. Ask specifically which CAIDs and idents are active on the card — not just what the marketing says. Connect a trial line, open the OScam web interface, and look at the card info for that reader. What CAIDs actually show up? Do they match the channels you're trying to decode?

Reshare depth above hop 2 is generally pointless and actively harmful for ECM times. Any source setting reshare to hop 5 or higher is either not thinking about latency or is trying to maximize client count. Neither is good for your setup.

Latency, Server Location, and Peering Quality

Geographic proximity to the server isn't just about raw ping — it's about peering. A server 500km away on a well-peered data center connection can outperform a server 50km away on a congested residential connection. Ping the server IP from your network before committing to a line. Anything under 30ms is excellent; 30–80ms is workable; above 150ms you'll be fighting ECM timing constantly.

On the legal side: card sharing entitlements with a card beyond its licensed viewing scope — sharing a single subscription across multiple households, for example — typically violates the terms of the subscription agreement and, in some jurisdictions, may conflict with broadcasting or copyright law. The specifics vary significantly by country and subscription type. Make sure you understand what's permitted under your specific subscription terms before configuring anything.