Card sharing CCcam and OScam: server setup in 2026

If you have already figured out the positioning of the dish and chosen a receiver on Enigma2, the next step is to configure the software for decoding. Each satellite channel that you want to watch in an encrypted package requires a control word from a server with a legal card. This is where CCcam and OScam come into play. In this article, you will find specific paths to files, config syntax, and error diagnostics without fluff.

What is card sharing and how do CCcam and OScam work

The mechanics are simple. The receiver receives an encrypted stream and generates an ECM request (Entitlement Control Message) — a packet with encrypted data necessary to obtain the control word. This request goes to the server, where a physical smart card with an active subscription is located. The server returns a CW (control word) — an 8-byte key that the receiver uses to decrypt the stream. The entire cycle must fit within approximately 300–500 ms; otherwise, the picture will start to freeze.

SoftCam is an emulator that handles all this exchange at the software level. CCcam and OScam are the two most common options. The difference between them is fundamental.

The principle of key exchange ECM/EMM between the server and the client

ECM requests go from the client to the server every few seconds — the encryption on satellite packages changes constantly. EMM (Entitlement Management Message) is another type of packet; they manage the card's access rights. For the average client, the ECM cycle is what matters: the faster the server responds, the more stable the picture.

Response time over 1000 ms is already a problem. At 1500+ ms, the image will start to regularly freeze, especially on packages with aggressive key updates, such as Viaccess 3.0 or Nagravision 3.

Differences between CCcam, newcamd, and CS378x protocols

CCcam is a proprietary protocol developed specifically for this software. It operates over TCP, with port 12000 by default. Simple in basic configuration, but less flexible in multi-reader configurations.

Newcamd is an older protocol with a 14-byte DES key for session encryption. It is used in OScam as one of the supported options. Ports 888 or 988 — depends on the config. CS378x is another protocol in OScam, operating on an arbitrary TCP port, slightly more efficient under high loads.

When to choose OScam and when to choose CCcam

CCcam wins in simplicity. One configuration file, minimal syntax, quick start. If you need a basic setup for one client — it's a good choice.

OScam is another level. It supports multiple protocols simultaneously, flexible rights for different users through oscam.user, a built-in web interface, and detailed logs. For serious work with multiple readers or multi-protocol configurations, OScam is significantly better. I would choose OScam by default in 2026 — it is actively supported, while CCcam has long been frozen in development.

Installation and structure of configuration files

Here, competitors often write general phrases instead of actual paths. I will correct this immediately.

File locations: /etc/tuxbox/config/ and /usr/keys/

Depends on the Enigma2 image. On OpenATV and OpenPLi, CCcam configs are located in/etc/CCcam.cfg. On some older custom builds, the path shifts to/var/etc/CCcam.cfg. If the file is not found — check both.

OScam stores configs in the directory/etc/tuxbox/config/oscam/ on most images. On some builds, it is/etc/oscam/. Keys and SoftCAM files are traditionally placed in/usr/keys/. It is most convenient to edit all this via FTP using FileZilla or through the built-in telnet/SSH.

Structure of CCcam.cfg: lines F and C

The CCcam.cfg file is read line by line. There are two main types of lines:

Line F — describes a local user (Friend) to which clients connect:

F: username password

Line C — describes the connection to the upstream server (Cascade):

C: hostname 12000 username password

Order matters: first all C lines (connections to servers), then F (local accounts). Spaces and case in the login/password are taken into account. This is a common reason for the "card not found" error — a typo in the password.

Additional parameters such asNEWCAMD LISTEN PORT andCCCAM VERSION can be added to the file header. A protocol version mismatch between the server and the client's old firmware is a real problem. If the client is on 2019 firmware and the server provides CCcam 2.3.x protocol, the connection may not be established. In this case, CCcam.cfg should include:

CCCAM VERSION: 2.1.4

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

OScam separates configuration into files — this is both more complex and more flexible at the same time.

oscam.conf — global parameters. The minimum working block:

[global]

oscam.server — description of readers (physical cards or cascade connections). Example block for a physical reader:

[reader]

To connect to a CCcam server as a client:

[reader]

oscam.user — management of clients connecting to OScam. Each user has a separate block[account] with parametersuser,pwd,caid.

Access rights and daemon restart

Configuration file permissions — 644. If set to 777, some OScam builds will refuse to read files for security reasons. Check and set:

chmod 644 /etc/tuxbox/config/oscam/*

Restart CCcam:

killall -9 CCcam&& CCcam

Or via init.d, if configured:

/etc/init.d/softcam restart

For OScam:

/etc/init.d/oscam restart

After changes in OScam configs, they can be reloaded without a full restart via the web interface — the "Reload" button on the Files page.

Opening ports and configuring protocols

If the server is behind NAT (which is almost always the case with home installations), ports need to be forwarded. Without this, the client outside will not be able to reach the server, even if everything is configured correctly.

Standard ports: 12000 for CCcam, 988 for newcamd

Default values that are used:

Protocol	Default port	Type
CCcam	12000	TCP
newcamd	988	TCP
CS378x	arbitrary	TCP
OScam WebIF	8888	TCP

Ports can and should be changed — standard ones are scanned more often. But when changing, don't forget to update both the server config and the client settings.

Port forwarding on the router and checking via telnet

In the router interface, find the Port Forwarding section (or Virtual Server — it has different names). Create a rule: external port 12000 TCP → internal IP of the receiver, port 12000. The internal IP must be static — either through DHCP reservation by MAC address or manually on the receiver.

Checking port openness from the outside:

telnet your_external_ip 12000

If the connection is established — the port is open. If "Connection refused" — either the forwarding is not working, or CCcam/OScam is not running. Through nmap:

nmap -p 12000 your_external_ip

A separate problem is double NAT. Often the provider gives a "gray" IP, and even a configured port forwarding on the home router does not help — the traffic simply does not reach. In this case, you need to request a static public IP from the provider or use a VPN tunnel (WireGuard, OpenVPN) for communication between receivers.

Configuring the OScam web interface on port 8888

In oscam.conf, add the section:

[webif]

After restarting OScam, the web interface is available at the addresshttp://ip_receiver:8888. All active connections, ECM time for each client, and reader status are visible there. Very convenient for diagnostics without digging through logs.

DES key encryption in newcamd

The newcamd protocol requires a 14-byte key in hex format for session encryption. In oscam.server, this parameter iskey:

[reader]

The key must match on both the server and the client. If it does not match — the connection will be established, but authorization will fail. The standard test key is all zeros (00...00) is used by many servers, but it's better to change it in the production configuration.

With a dynamic external IP, DDNS is needed. Services like No-IP or DynDNS provide a permanent domain name that automatically updates when the address changes. This is usually configured on the router in the DDNS section — you enter the login/password from the service account, and the router updates the record itself.

Diagnostics and solving typical problems

Most card sharing problems are diagnosed through logs. But for this, you first need to enable these logs and know how to read them.

Freezes and image hangs

Freezes are the most common complaint. There are several reasons, and it's important to identify the specific one:

• High ECM time — the server response time is more than 800–1000 ms. This can be seen in the OScam web interface or in the log.
• Conflict of emulators — if CCcam and OScam are both running simultaneously, they both try to capture one physical reader (/dev/sci0). The result is chaotic freezes, sometimes a complete absence of picture. This is a very common mistake after reinstalling softcam. Check with the commandps | grep -E 'CCcam|oscam' — only one process should be running.
• Unstable ping — jitter on the channel to the server. Ping 20 ms with spikes up to 300+ ms is worse than stable 80 ms.
• Aggressive key switching — some packages update CW every 5–7 seconds instead of the standard 10. An ECM time of 600 ms on a regular package is normal, but on such a package, it's already on the edge.

Error "card not found" and empty ECM responses

If you see "card not found" or "no entitlement" in the log — the card on the server does not have rights for the requested CAID/provider. Check that the CAID in oscam.server matches what the satellite channel is broadcasting (the satellite channel is broadcast with a specific encryption system identifier).

An empty ECM response ("empty answer") usually means that the server accepted the request, but the card could not decode it. Either the package is not included in the subscription, or the card is blocked.

Reading logs OScam and CCcam

Enabling logging in OScam (oscam.conf):

[global]

The level of detail is set through the web interface: Files → oscam.conf → parameterdebug, or through the Loglevel page in WebIF. For diagnostics, set the level to 64 (CW logging) or 255 (everything).

Key lines in the OScam log:

• cw written — the control word has been successfully received and sent to the decoder
• rejected — the request was rejected by the server (no rights, incorrect credentials)
• timeout — the server did not respond in the allotted time
• no card — the reader did not find a suitable card for CAID

For CCcam, the log is written to/tmp/cardserver.log when started with the key-d:

CCcam -d

Problems with the local card and reader

The physical reader diagnostics in OScam is started with the command:

oscam -r

This is the reader mode without fully starting the daemon — it shows whether the card is detected at all. If the card is not detected, check the parametersmhz andcardmhz in oscam.server — an incorrect reader frequency breaks the card initialization.

On some images (OpenATV 7.x), the reader device may be/dev/sci1 instead of/dev/sci0. Check:

ls /dev/sci*

How to choose a reliable source without risks

Without specific names — because they change constantly. Criteria are important, not brands.

Stability criteria: uptime and ECM time

Normal ECM time for comfortable viewing is up to 400 ms. Anything that consistently stays in the range of 200–350 ms is a good result. Numbers above 600 ms on average mean that any spike in load will cause freezes.

Server uptime is an indirect indicator. Any decent service shows availability history. Monthly uptime below 98% raises questions. Look not only at the stated numbers but also at technical support forums: how quickly they respond to problems.

Signs of an unreliable source

Red flags that indicate you should look further:

• Requirement for full prepayment without a trial period — no test, no trust
• Lack of technical documentation — a normal service provides a config for CCcam and OScam right away
• Promises of "100% uptime" — physically impossible, which means they are lying
• No information about the location of servers — important for ping assessment
• Support only through messages in messengers without a ticket system

Checking the ping and geolocation of the server

A server 500 km away from you with a ping of 15 ms is always better than a server across the ocean with a ping of 180 ms, even if the latter is more powerful. Before purchasing, ask for a test connection string and measure the ping:

ping hostname_of_the_server

Check the geolocation of the server's IP through any IP lookup service — at least you understand roughly where the hardware is physically located. A discrepancy between the declared country and the actual geolocation is also a warning sign.

Legal aspects and legal use

Card sharing within one network and with an officially paid subscription is technically permissible use of the card for personal needs. One satellite channel received on the card you paid for can be decoded on several devices in the home network — this is a gray area that is not explicitly prohibited in many jurisdictions.

But as soon as the control word goes to third parties — that’s a different story. Transmitting CW outside your network to outsiders violates both the subscription terms (which means immediate termination upon detection) and copyright legislation in most countries.

For each satellite channel that you want to watch legally, there must be a paid subscription. This is not just a formality — it is the only scheme under which you are legally protected.

A brief cheat sheet on paths and commands

What	Path / command
CCcam config (OpenATV/OpenPLi)	/etc/CCcam.cfg
CCcam config (custom images)	/var/etc/CCcam.cfg
OScam configs	/etc/tuxbox/config/oscam/
OScam log	/var/log/oscam.log
CCcam log	/tmp/cardserver.log
Restarting CCcam	killall -9 CCcam&& CCcam
Restarting OScam	/etc/init.d/oscam restart
Checking port	telnet ip 12000
Checking running processes	ps | grep -E 'CCcam|oscam'