No-Subscription Satellite TV: CCcam & OScam Setup Guide

If you've ever wondered how people run no subscription satellite tv setups on their Dreambox or VU+ receiver, the answer almost always comes back to two pieces of software: CCcam and OScam. This guide skips the marketing and gets into the actual protocol, config files, and troubleshooting steps you need. Assume you're already comfortable with SSH and a text editor — this isn't a hand-holding exercise.

How Card Sharing Actually Works (CCcam vs OScam)

The core concept is simpler than the jargon makes it sound. A satellite broadcast encrypts its stream using a rapidly changing key — the control word (CW). To get that key, your receiver sends an ECM (Entitlement Control Message) to a server that holds a legitimate smartcard. The server's card decrypts the ECM, extracts the CW, and sends it back to your receiver. Your receiver uses that CW to descramble the video.

The other message type you'll see in logs is EMM — Entitlement Management Message. EMMs don't carry the CW directly; they're used to update entitlements on the card itself, adding or removing channel access. ECMs happen constantly (every few seconds as the CW rotates). EMMs are less frequent but matter for keeping the card's subscription current.

The control word and ECM/EMM exchange explained

Your receiver tunes to a channel and hits the CA (conditional access) layer. It can't descramble on its own, so it passes the ECM upstream to whoever holds the card. The card decrypts it and returns the 8-byte CW. The whole round trip needs to happen in well under a second — the CW period is typically 10 seconds, but if your ECM response takes too long, you get a freeze before the new CW arrives.

This cycle is what all the "ECM time" monitoring is about. A fast card on a local network is trivial. A card sitting behind three reshare hops with a slow network in between is where problems start.

Client-server model: what the receiver requests

The receiver (or the softcam running on it) acts purely as a client. It knows it can't decode the stream itself, so it connects outbound to a sharing server over TCP. It sends the ECM, waits for the CW, and descrambles. The server does the actual card work. This is why port forwarding is a server-side concern — the client initiates the connection.

CCcam protocol vs OScam protocol vs newcamd

CCcam uses its own closed binary protocol. The default port is 12000 (TCP). It was dominant for years, but the protocol is undocumented and the last official CCcam binary is from around 2012. Still works, still widely understood by receivers, but there's been no active development in over a decade.

OScam is open-source and implements multiple protocols simultaneously on different ports. Out of the box you can run the cccam protocol on 12000 for receiver compatibility, newcamd on a port of your choice (5000 is common), and camd35 if needed — all from one OScam instance. You can also point physical smartcard readers directly at it.

Newcamd (Network Camd) is an older but still-used protocol with its own encryption layer for the handshake. It's slower to set up but supported by almost every receiver. Most modern setups default to cccam protocol for clients because receiver support is universal.

Why OScam has largely replaced CCcam for new setups

OScam reads physical smartcards via internal or external smartcard readers (USB or serial). It has a live web interface for monitoring. It's actively maintained with commits in 2025 and 2026. And it handles protocol translation — a client connecting over cccam protocol can be sharing from a card that OScam reads natively. CCcam can't do any of that. For a new server build, there's no reason to start with CCcam.

Setting Up an OScam Server: Config Files and Structure

OScam's config is split across several plaintext files. There's no binary database or GUI required — just files, permissions, and a restart. The config directory is set at compile time, which is the first gotcha when you're running a pre-built binary from an Enigma2 image.

The core config files: oscam.conf, oscam.server, oscam.user

Three files get you running. oscam.conf is the main config — global settings, protocol ports, and the web interface. oscam.server defines your readers (either physical cards or upstream sharing connections). oscam.user defines who can connect as a client. Additional optional files like oscam.services and oscam.provid let you filter by provider/channel, but you don't need them to start.

Where configs live (/etc/tuxbox/config or /usr/keys)

This depends entirely on the build. On most Enigma2 images (OpenPLi, OpenATV), OScam compiled for that image uses /etc/tuxbox/config/. On some images, it's /var/keys/. If OScam silently fails to start after install, this is almost always why — the binary is looking for its files in one path and you put them in another.

Find the right path with: oscam --help 2>&1 | grep config or check the startup script in /etc/init.d/oscam. You can also override at launch: oscam -b -c /etc/tuxbox/config. Once you know the real path, put all your config files there.

Defining a reader in oscam.server

Here's a minimal reader block for a physical smartcard on an internal slot:

[reader]
label = localcard
protocol = internal
device = /dev/sci0
caid = 0500
group = 1
detect = cd
mhz = 357
cardmhz = 357

The group number is critical — it must match the group in the corresponding oscam.user account, or the share routing won't happen. Many people set up readers and accounts, see no errors, and still get "no card" because the group numbers don't match. Check this first.

For an external USB smartcard reader, swap device = /dev/sci0 for device = /dev/ttyUSB0 and adjust mhz to 368 typically.

Creating client accounts in oscam.user

Each client gets an account block:

[account]
user = client1
pwd = s0mepassword
group = 1
au = 1
monlevel = 0

au = 1 enables EMM forwarding for that client (lets the card update). monlevel = 0 hides this account from the web interface's active client list — useful for privacy. Add as many [account] blocks as you need, one per client.

Enabling the web interface (httpport)

Add this to oscam.conf under a [webif] block:

[global]
logfile = /tmp/oscam.log
maxlogsize = 1000
nice = -1
[webif]
httpport = 8888
httpuser = admin
httppwd = yourpassword
httpallowed = 0.0.0.0/0
[cccam]
port = 12000
[newcamd]
port = 5000@0500:000000

If httpallowed isn't set or is bound to 127.0.0.1, you'll reach the web interface from localhost only — not from your LAN. That's a common reason the UI appears unreachable even though OScam is running fine.

Connecting a Client Receiver to a Sharing Server

Your receiver needs to know where to ask for decryption. If you're running a softcam that reads CCcam.cfg, this is a one-liner. If you're running OScam on the client side too, it's a reader block.

CCcam.cfg client line format (C: line)

Open /etc/CCcam.cfg on your receiver and add a C: line:

C: hostname.example.com 12000 myusername mypassword

That's it. Fields are: C: (literal), hostname or IP, port, username, password — separated by spaces. No quotes. One line per server. CCcam clients try connections in order if you have multiple lines; the first working server wins.

Note that the softcam on your receiver must be running for this to do anything. On Enigma2, start it from the softcam manager in the menu or via /etc/init.d/softcam start.

OScam client via camd35 or cccam reader

If you're running OScam on the client receiver (which has advantages for monitoring and filtering), add a reader to the client's oscam.server:

[reader]
label = upstream_server
protocol = cccam
device = hostname.example.com,12000
user = myusername
password = mypassword
group = 1
reconnecttimeout = 30

This tells OScam to connect outbound to the server using cccam protocol. It appears as a reader in the web interface just like a physical card would, which makes diagnostics much easier.

Port, hostname, username, password fields

Hostname can be an IP or a domain. If the server is behind a dynamic IP and uses a DDNS hostname, make sure the domain resolves correctly from your receiver's network. Port 12000 is the standard CCcam port, but servers can use any port — confirm the actual port before assuming it's 12000.

Credentials are case-sensitive. Copy-paste rather than retyping to avoid typos. A wrong password gives a connection that authenticates and immediately drops — you'll see "rejected" in the server's OScam log.

Testing the connection and reading ECM time

Open the OScam web interface on your client or server at http://ip-address:8888. Go to the Readers section. A working reader shows status "connected" and you'll see ECM counts incrementing when you tune to an encrypted channel.

ECM time is shown per reader. Under 200ms is excellent. Under 400ms is fine for everyday use. Above 1000ms is where you'll see visible channel freezes. If the reader shows "off" or "error" instead of "connected", the problem is credentials, host/port, or firewall — work through those in that order.

Troubleshooting Common Card Sharing Problems

Most problems fall into a small number of categories. Here's how to actually diagnose them rather than just restarting things and hoping.

Channel freezes and high ECM times

If video freezes every 10 seconds or so, the CW isn't arriving in time. Check ECM times in the OScam web interface for the relevant reader. Anything consistently over 800ms is a problem waiting to happen; over 1000ms and freezes become regular.

Causes: too many reshare hops between the source card and your receiver, geographic distance and latency, or an overloaded server at peak viewing hours. Hop count is visible in the OScam web interface — a hop 1 share means the server you're connected to holds the card directly. Hop 3+ means you're at least three servers removed from the card, and latency accumulates at each step.

Also check for packet loss between you and the server. A 5% packet loss rate destroys ECM reliability because the request or response gets dropped and has to retry.

'Reader not connected' errors

This is almost always one of three things: wrong hostname or port, wrong credentials, or a firewall blocking the connection. Test port reachability from your receiver with nc -zv hostname 12000 or from a PC on the same LAN. If the port doesn't respond, the issue is on the server side — either OScam isn't running its cccam listener, or the port is blocked.

On the server, confirm the cccam listener is up by checking netstat -tlnp | grep 12000. If OScam is running but the port isn't listed, the [cccam] block in oscam.conf may be missing or the port may be 0 (disabled).

Wrong config directory / OScam won't start

Run OScam manually in the foreground with verbose logging to see what it's doing: oscam -b -c /etc/tuxbox/config -l /tmp/oscam_debug.log. If it exits immediately with no log output, the config path is wrong and it's failing silently before logging starts.

File permissions matter too. Config files should be readable by the oscam process user. chmod 644 /etc/tuxbox/config/oscam.* and chown oscam:oscam (or whatever user OScam runs as) sorts permission issues. Check with ls -la /etc/tuxbox/config/.

Also: the [global] section in oscam.conf must exist. An empty or malformed oscam.conf causes OScam to exit without a useful error.

Firewall and NAT port-forwarding issues

If you're running the server behind a home router, you need to forward TCP port 12000 (and 8888 if you want remote web access) to the server's internal IP. The common mistake is forwarding to the wrong LAN IP, especially if the server's DHCP lease changes. Set a static LAN IP for the server machine first.

Double-NAT setups — where your ISP gives you a carrier-grade NAT address before your home router — are genuinely problematic. Port forwarding through your home router works on your LAN but the public IP your clients connect to isn't reachable because the ISP's NAT layer blocks it. In this situation, a VPN tunnel or a VPS-based reverse proxy (like a WireGuard or SSH tunnel to a VPS with a real public IP) is the only clean solution.

Test port reachability from outside your network using a tool like canyouseeme.org or by SSHing to a VPS and running netcat from there. If the port isn't reachable from outside, no client will connect no matter how correct the credentials are.

Reading the OScam log for ECM rejections

Enable verbose logging in oscam.conf:

[global]
logfile = /tmp/oscam.log
loghistorysize = 2000
maxlogsize = 5000

Watch the log live with tail -f /tmp/oscam.log. Key entries to look for:

• ECM rejected — the card refused to decrypt this ECM. Usually means the card's subscription doesn't cover that provider or the card is expired.
• no card — OScam found no reader that can handle this ECM. Almost always a group number mismatch between reader and user account.
• client disconnected — normal, but if it happens immediately after connect, credentials are wrong.
• restarting reader — the reader dropped and OScam is retrying. If this repeats every 30 seconds, the upstream server is refusing the connection.

Time sync issues are another cause of ECM rejections that gets ignored. If your STB rebooted and the system clock is wrong (say, off by hours because NTP hasn't synced yet), some CA systems reject ECMs based on timestamp checks. Force an NTP sync after reboot: ntpdate pool.ntp.org or enable the system NTP service permanently.

How to Evaluate a Sharing Source (Generic Criteria)

If you're connecting to an external source rather than reading your own card locally, what you're evaluating is essentially a remote card reader. The criteria are technical, not marketing.

Uptime and server stability indicators

A reliable source should be able to show you uptime statistics or at least have a track record you can verify — through forums, user reports, or testing a trial line for a few days during peak hours (evenings, weekends). A service that looks fine at 3am but chokes at 8pm when everyone's watching is a known pattern with oversold setups.

Ask whether they run any status page or monitoring. Operators who take uptime seriously usually have one. Those who don't are a yellow flag.

Local card vs reshare — why it matters

A hop 1 source means the server you're connecting to physically holds the smartcard. A hop 2 source means your server connects to another server that holds the card. Each hop adds latency and a potential failure point. A reshare chain of 3 or more hops is asking for trouble — you're three servers away from the actual card, and any one of those links dropping causes your connection to fail.

This is one thing most setups glossing over no subscription satellite tv don't explain clearly: the hop count directly affects reliability, independent of server speed. A fast 3-hop setup is often worse than a slightly slower 1-hop setup.

Latency, hops, and geographic proximity

For a 10ms ECM response, the card needs to be geographically nearby. A server in the same country as you, running a card with no reshares, can deliver ECM times under 100ms on a good day. A server on another continent adds 80-150ms of baseline round-trip latency before the card even does its work.

When evaluating, ask where the servers are physically located. If they can't or won't answer that, the latency you see in the ECM times will tell you anyway — run a connection for an hour and watch the OScam reader stats. Consistent 300ms ECM times are fine. Spikes to 900ms every few minutes mean the path is unstable.

Red flags that signal an unreliable setup

A few things that should make you pause before committing:

• No trial period offered — you're being asked to pay without any way to test stability
• Promises of "unlimited lines" or "guaranteed uptime" without specifics — these are meaningless without an SLA behind them
• ECM times that vary wildly day to day — suggests the server is being reshared across multiple providers with no capacity management
• Support that goes quiet for days — if you can't get a response when evaluating, don't expect better when something breaks
• Only one server IP — no redundancy means if that machine goes down, you have nothing

The setup described throughout this guide gives you the tools to evaluate all of this yourself. Once OScam is running on your receiver, you have real-time ECM monitoring and reader stats. Use them — they're more reliable than any marketing claim about no subscription satellite tv.