OScam and CCcam: setting up a card sharing server in 2026

If you have been working with card sharing for more than a few months, you inevitably encounter a pair of oscam cccam — two emulators that either work together like clockwork or turn the evening into a debugging marathon. The difference between them is not just in the name — they are fundamentally different tools with different philosophies.

OScam vs CCcam: what is the real difference

CCcam is a closed proprietary emulator with a binary without source code. Its protocol operates on port 12000 by default, and for a long time it was the de facto standard for sharing on Dreambox. OScam is open, written in C, compiles for anything from MIPS to ARM, and supports not one protocol, but several.

Architecture and principle of operation

CCcam operates monolithically: one process, one config/etc/CCcam.cfg, one protocol. Simple, but limited. OScam is modular — separate files for global settings, readers, users, services. This complicates the initial setup but gives full control over every parameter.

The key difference: OScam can simultaneously act as a CCcam client (receiving C-line from a remote server) and a CCcam server (distributing keys to its clients). CCcam cannot do this fully. That’s why the combination of oscam cccam on one server is not a hack, but a fully functional architecture.

When OScam is more stable, and when CCcam is simpler

CCcam is better suited if you have an old Dreambox 800 and just want to throw in a couple of C-lines without fussing with compilation. A config of 10 lines — and everything works. OScam is indispensable when you need to read a card locally, serve dozens of clients simultaneously, and finely control the load through groups and filters by CAID.

On weak hardware with 64 MB RAM, CCcam sometimes behaves more predictably. On a normal server or VPS with 512 MB+, OScam wins in all parameters — especially in diagnostics and logging.

Protocol compatibility and emulator pairing

OScam supports newcamd (default port 28910), camd35 (UDP, port 35), mgcamd, and of course, cccam. This means that a client on mgcamd and a client on pure CCcam can simultaneously receive keys from one OScam server — simply through different protocols. CCcam does not provide such flexibility.

Installation and structure of OScam configuration files

The first thing to understand: OScam does not have a single "correct" location for configs. It depends on the distribution and hardware. On Dreambox, it is usually/etc/tuxbox/config/, on Enigma2 boxes, it can be found at/usr/keys/, on pure Debian —/etc/oscam/.

The directory /etc/tuxbox/config or /var/tuxbox/config

Historically, configs lived in/etc/tuxbox/config/. On modern Enigma2 builds like OpenPLi or OpenATV, the path may differ — check viafind / -name oscam.conf 2>/dev/null. The binary is usually in/usr/bin/oscam or/usr/local/bin/oscam.

Purpose of oscam.conf, oscam.server, oscam.user, oscam.services

The minimum workingoscam.conf looks like this:

[global]

oscam.server — description of readers (local cards or remote servers).oscam.user — clients to whom you distribute keys.oscam.services — filtering by CAID and providers, if you need to restrict access to specific channels.

File permissions for configuration:chmod 600 /etc/oscam/*, the owner is the user from whom oscam is launched. If you run it as root, it's not a problem, but on servers, it's better to create a separate user.

Building OScam via SVN and toolchain

The latest relevant SVN revision at the time of writing is around r11826+. The build is standard:

svn co http://streamboard.gmc.to/svn/oscam/trunk oscam-src

FlagUSE_LIBUSB=1 is needed for SmartReader and other USB readers. Without it, the device simply won't be recognized. After building, start:oscam -b -r 2, where-b — background mode,-r 2 — logging level (2 = normal, 4 = debug).

Configuring the local card reader in oscam.server

This is where most beginners lose an hour or two. The card is physically in the reader, OScam sees the device, but in the log — silence or initialization errors. Most often, the problem is not in the config at all, but in the clocking parameters.

Section [reader] for smart card (protocol, device)

Basic example for USB reader:

[reader]

For the built-in reader on Dreambox or Vu+:

[reader]

Device permissions:ls -la /dev/ttyUSB0 — the oscam user must be in the groupdialout or have direct access. On built-in readers,/dev/sci0 the owner is usually root, which causes fewer problems.

Parameters detect, mhz, cardmhz for problematic cards

This is the very parameter that most guides are silent about. If the card is not read or initialized every other time — try explicitly setting the frequency:

mhz = 357

The value 357 corresponds to 3.57 MHz — the standard for most cards. Some Nagravision or Irdeto cards work better at 600/357 (interface at 6 MHz, card at 3.57). If the card is not consistently initializing, try combinations: 369/357, 357/357, 600/600.

Parameterdetect = cd includes card detection via the CD pin. Without it, OScam may attempt to read the card before it is fully initialized. It helps on some readersdetect = 0.

Another common problem is double initialization when usinginternal andphoenix protocols on one/dev/sci0. OScam will try to open the device twice, the second time it will be denied, and the log will show something likeDevice /dev/sci0 already in use. The solution is obvious — one reader per device.

Checking card reading through webif and oscam.log

Webif on port 8888 is the first diagnostic tool. The "Readers" tab will show the status of the reader: green = card is being read, red = no. The ECM time is also visible in real-time.

In the log, upon successful initialization, look for lines like:

2026/01/15 14:32:01 [reader] local_card: card detected

If you seecard not found when the card is physically inserted — it is almost always due tomhz/cardmhz or incorrectprotocol.

Connecting clients and sharing via the CCcam protocol

When the card is read locally and the ECM time is visible in webif around 150-300 ms — you can connect clients. The C-line format that the client writes in their config is standard:

C: hostname 12000 username password

Hostname — the IP or DNS of your server. If the client is behind NAT and you are also behind NAT — without port forwarding, nothing will work.

The [account] section in oscam.user

[account]

The parametercaid in[account] — is one of the most frequently overlooked. If the card is being read and everything works locally, but the client receivesnot found — in 80% of cases, the problem is right here. The CAID in the account does not match the CAID of the card, and OScam filters the request before reaching the reader.

Setting up C-line and N-line on the client side

N-line — is the newcamd protocol, the format is different:

N: hostname 28910 username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

14 digits at the end — DES key, it is set in[newcamd] the oscam.conf section with the parameterkey. N-line is more stable for one CAID and one provider — less overhead, no hop counter. C-line is more convenient when you need to stream multiple CAIDs through one connection.

The parameters cccmaxhops, cccreshare, port 12000

cccmaxhops = 1 means that your client will receive cards only from the zero and first hop — that is, local cards and first-level sharing cards. Cards with hop=2 and higher are filtered out. This is the correct setting for quality control: the more hops, the higher the ECM time.

cccreshare = 0 prohibits the client from resharing your card further.cccreshare = 1 — allows one level of resharing. Without this parameter, the client can technically build their server on your lines — which you probably do not want.

Port 12000 — default for the CCcam protocol. It is set inoscam.conf in the section[cccam] with the parameterport = 12000. If both CCcam and OScam are running on the same host — one of them must move to another port (for example, 12001), otherwise you will get a conflict at startup.

Diagnosing problems: freezes, no keys, ECM timeout

Freezes on the screen — the most common complaint. And the most ambiguous, because there can be about six different causes. You should start diagnosing from the log, not by restarting everything.

Reading oscam.log and decoding statuses (found, not found, timeout)

In oscam.log, each ECM request ends with a return code:

• rc=1 (found) — key found and sent to the client. All is well.
• rc=4 (not found) — no reader returned the key. Either incorrect CAID/ident, or the card is not subscribed to this channel, or there is a problem with the remote server.
• rc=5 (timeout) — the request was sent, but the response did not arrive within the timeout (by default — the value ofclienttimeout in oscam.conf, usually 1500-2000 ms).
• rc=7 (cache) — key taken from the cache, not from the reader. Fast and good.

If you see continuousrc=4 for a specific channel — check CAID and ident. Sometimes the provider changes ident, and you need to updateoscam.services or remove the restriction by ident altogether.

Freezes only on some channels while the rest are working — a frequent sign of an EMM problem, not ECM. The channel changed keys, the card did not receive the EMM update in time. Check ifau is enabled. (auto-update) for the reader and the corresponding account.

NAT issues, port forwarding, firewall

The client says they connected, but the keys are not coming — classic NAT. The check is simple:

telnet your-server-ip 12000

If the connection does not establish — the port is closed. Port forwarding is needed on the router: external port 12000 → internal server IP, port 12000, protocol TCP. On the Linux server, check iptables:

iptables -L INPUT -n | grep 12000

If the rules block — add:iptables -A INPUT -p tcp --dport 12000 -j ACCEPT. The same for the webif port 8888, if remote access to the interface is needed.

High ECM time and unstable peering

ECM time above 1000 ms guarantees freezes on most receivers. The decoder buffer runs out before a new control word arrives. The norm for a local card is 100-400 ms. For one hop of sharing — 300-700 ms. Two hops and more — a lottery.

Unstable peering is usually visible in the log as alternatingrc=1 andrc=5 on one channel. The reason is high or fluctuating ping to the remote server, or the server itself is overloaded and cannot respond in time. In such cases, adding a second server as a fallback inoscam.server with the samegroup — OScam will automatically choose the faster one.

How to choose a line provider: technical criteria

A technically sound choice of a line is not about price and not about a nice website. It is about measurable parameters that can be checked independently during the trial period.

What to look at: uptime, ECM time, local cards

First — ECM time. Request a test and check in oscam cccam webif for real numbers. If the ECM time consistently stays around 200-500 ms — a good sign. If it fluctuates from 100 to 1500 ms over an hour — the server is overloaded or the card is not local.

Second — locality of cards. Hop=0 means the card is physically on this server. Hop=1 — already a resharing. Hop=2 and higher — this is a resale chain, where each node adds delay. In webif in the "Services" section, the hop value for each CAID is visible.

Third — uptime. A normal server maintains 99%+ over a month. This can only be realistically checked during a trial access over several days, preferably including evening prime time.

Signs of an unstable or resold server

A resold server can be easily identified by a pattern in the log: in the evening, ECM time rises from 300 to 800-1200 ms, then drops back at night. This is a load picture — too many clients on one card.

Another sign — periodicrc=5 without visible reason specifically during prime time. The server itself does not crash, ping is normal, but the card simply cannot respond to all clients simultaneously. In this case, no settings on your side will help — the problem is with the provider.

High downhop (hop=3 and higher) — also a warning signal. A chain of three resellers is unstable by definition: if one drops out, you have no keys.

Trial period and quality monitoring

During the trial period, enable debug logging in oscam: the parameterlogfile inoscam.conf plus level-r 4 at startup. Let it write for several hours during prime time. Thengrep "rc=" /var/log/oscam/oscam.log | sort | uniq -c — the percentage of successful requests is immediately visible.

Good line: 95%+ rc=1 or rc=7, single rc=5 only when switching channels. Bad line: 30-40% rc=5 in the evening — this is not "a bit unstable", it is unsuitable for normal viewing.

Frequently Asked Questions