Setting up CCcam and OScam sharing: a complete guide

If you've reached the stage where you already understand what card sharing is, have chosen the software, and received the line data from the provider — congratulations, the most interesting part is just beginning. Setting up sharing in practice comes down to configuration files, the formats of which are sensitive to details: an extra space, incorrect case, BOM encoding — and the line won't connect. I will break this down line by line, with real config examples and explanations of each field.

What you need to prepare before setting up sharing

Before opening the editor, make sure you have everything necessary. The line provider gives a set of data: hostname (or IP), port, username, and password. Sometimes they provide several C-lines — these are backup servers, and you need to add them all.

Access to the receiver's file system — via FTP (FileZilla, WinSCP), SSH, or Telnet. Without this, editing configs is impossible. On most Enigma2 receivers (Vu+, GigaBlue, Dreambox), FTP is enabled by default.

Emulator software: CCcam or OScam

CCcam is a proprietary softcam, with a single config file and simple syntax. It is installed via the plugin manager or placed in /usr/bin/ with execution rights. OScam is open, actively supported, consists of several configuration files, and supports dozens of protocols.

Line data: host, port, username, password

The standard set looks like this: host in the form ofserver.example.com or IP, port in the range of 12000–18000 (for CCcam), username, and password. For OScam via newcamd, the port is usually around 28000+. Save this data — it is inserted into the config verbatim, without changes.

Access to the receiver or server file system

Typical paths: for CCcam, the config is located in/var/etc/CCcam.cfg. On some firmware versions —/etc/CCcam.cfg. For OScam, configs are placed in the directory/etc/tuxbox/config/ or/etc/oscam/ and are namedoscam.conf,oscam.server,oscam.user,oscam.dvbapi.

How CCcam differs from OScam

CCcam deploys faster: one file, minimal settings, it will work in five minutes. OScam is more complex at the start, but provides routing between readers, support for newcamd/CS357x/CS378x, precise group control, and load balancing. If the receiver's firmware cannot run OScam — use CCcam, no options.

Setting up the CCcam client: analyzing CCcam.cfg

The file/var/etc/CCcam.cfg is text-based, one instruction per line, case is important. It should be opened in an editor without BOM: Notepad++ with UTF-8 without BOM encoding or any Linux editor. Save with LF line endings, not CRLF — otherwise, CCcam will not parse the lines correctly.

C-line syntax

The main connection line to the server looks like this:

C: hostname port username password no { 0:0:1 }

Field breakdown:C: — line type (Client),hostname — server address,port — TCP port,username andpassword — line credentials. The parameterno means "do not share back" (can't share back). In curly braces — CAID:provider:reshare level, most often left as{ 0:0:1 } for automatic detection.

Connection parameters and their order

The order of fields in the C-line is fixed — it cannot be changed. A missing space betweenC: and hostname breaks parsing. A typical minimal CCcam.cfg:

# CCcam configuration

Local cards and SHARE LIMITS option

If there is a physical smart card in the receiver, CCcam sees it as hop 0 — a local card. Cards from remote servers receive hop 1, 2, and so on. The directiveSHARE LIMITS limits at what level to stop ressharing. For a pure client without local cards, these lines are simply unnecessary.

Status check via web interface (port 16001)

CCcam raises a built-in web server on port 16001. Openhttp://IP-receiver:16001 in a browser — you see the status of connected C-lines, ECM time, number of active subscribers and hops. The statusCONNECTED means that the TCP connection is established. This does not guarantee that the required channels will open — but at least the network is working.

Configuring OScam: oscam.server, oscam.user, and protocols

OScam is divided into several configuration files. This is inconvenient at the start, but provides clear separation: readers (card/line sources) — in oscam.server, users (local clients) — in oscam.user, global settings — in oscam.conf. Configuring sharing in OScam requires understanding this structure.

Reader in oscam.server (protocol = cccam)

Reader section in/etc/oscam/oscam.server for connecting to the CCcam server:

[reader]

Fieldlabel — arbitrary name of the reader for logs.device — host and port separated by a comma.group — group number by which OScam routes ECM requests. Important: if two readers have the same group, OScam will try to balance between them — make sure this behavior is desired, otherwise assign different groups.

Creating a user in oscam.user

If OScam operates as a server and clients connect to it (for example, local MGcamd or a second OScam), an account is needed inoscam.user:

[account]

Parameterau = 1 enables auto-update of rights (auto update). For a local dvbapi client (opening channels on the receiver itself), an account is usually not needed — OScam itself accesses the tuner through oscam.dvbapi.

Protocols newcamd, CS357x, CS378x, cccam

newcamd — one of the most common client-server protocols, port usually in the range of 28000–28010. Uses DES encryption. In oscam.server:protocol = newcamd, additionally, the parameterkey (14-byte DES key from the provider) is needed.

CS357x (camd35) works over UDP on port 34000. Fast, but less reliable on unstable channels — UDP does not guarantee delivery.CS378x — TCP version of the same protocol, more stable.cccam in oscam.server — this is a connection to an external CCcam server, as shown above.

dvbapi and binding to the tuner

Fileoscam.dvbapi describes how OScam interacts with the Enigma2 tuner for descrambling channels. Minimum variant:

[dvbapi]

Parameterboxtype depends on the receiver:dreambox,vuplus,dbox2 and others. Incorrect boxtype is a common reason why the line is connected, but channels do not open at all.

Checking functionality and reading logs

After saving the configs and restarting the emulator, don't expect a miracle — go check the logs and web interface. Most problems are visible right away if you know what to look for.

Web monitoring: CCcam (16001) and OScam (8888)

OScam raises the web interface through a section inoscam.conf:

[webif]

Openhttp://IP:8888 and see the statuses of all readers, current ECM requests, response time. CCcam — similarly on port 16001, but the interface is more limited.

Decoding ECM statuses (decoded / not found / timeout)

decoded — the channel opened, card found.not found — there is no card with the required CAID in any reader. This is either an incorrect CAID/provider in the settings, or the channel simply does not belong to the purchased line package.timeout — the request was sent, but the response did not arrive in time. Reasons: overloaded server, poor connection, too long a chain of hops.

Checking via telnet and logs

Basic diagnostics — check if the port is open at all:

telnet myserver.example.com 12000

If the connection is established — the network is working. If immediatelyConnection refused or timeout — the port is unavailable, the problem is at the network or router level. The OScam log is set inoscam.conf:logfile = /tmp/oscam.log. There you can see CARD INSERTED, CONNECTED, AUTH FAILED — everything needed for diagnostics.

Measuring ECM response time

Normal ECM time — from 100 to 600 ms. Stably above 1000 ms — the server is overloaded or physically far away. Above 2000 ms — freezes when switching channels are inevitable. In the OScam web interface, this field is visible in real-time for each reader.

Typical sharing configuration errors and their resolution

Over the years of working with this software, I have seen the same pitfalls over and over again. Most problems can be solved in 10 minutes if you know where to look.

Reader/line in OFF or ERROR status

AUTH FAILED in the logs — incorrect login or password, check literally, without extra spaces.NETWORK ERROR / OFF — the port is unavailable. Check via telnet. A common reason: the router does not forward incoming connections, although outgoing through NAT usually works fine — for client connections, port forwarding is not needed.

Another reason: the internet provider's firewall blocks non-standard ports. In this case, ask the line provider for an alternative port (many provide 80 or 443 as backups).

FTA channels open, coded ones do not

FTA channels (free unencrypted) always open — they do not require a card. If coded ones are not working, the line is either not connected or the CAID does not match. In OScam, check the ECM requests in the web interface: it shows which CAID is being requested and if there is a suitable reader. If the statusnot found — the required CAID is not present in the line.

A separate case: some channels of the package open, some do not. This means that the line does not cover the entire package — only certain transponders or provider IDs. Solution: clarify the coverage of the line with the source.

Freeze and image freezes

Freezes with a normally connected line — almost always ECM time is above normal. Reasons: slow internet channel (less than 1 Mbps stable), overloaded server at peak times, too long hop chain (hop 3–4 and above). In CCcam.cfg you can explicitly limit:ECMTIME: 3000 — requests longer than 3 seconds will be interrupted.

Another reason for freezes — incorrect file permissions on configuration files. After uploading via FTP, OScam may not read the files if the permissions are set to 600 or 777. Correctly:chmod 644 /etc/oscam/*.

Conflict of multiple emulators and softcam

This is a real problem that is ignored almost everywhere. If CCcam and OScam are running simultaneously on the receiver — they conflict over access to dvbapi and the tuner. Channels open chaotically or do not open at all. Keep only one emulator active, turn off the second one via the softcam manager (usually Blue Panel → Softcam Manager).

How to choose a reliable line: criteria without reference to names

Setting up sharing is only half the battle. The other half is the quality of the line itself. You can perfectly configure the configs but get garbage at the output due to an unreliable source.

Stability of uptime and backup servers

Normal uptime for a working line is from 99% per month. It is difficult to check this in advance, but you can request a test line for 24–48 hours. A good sign is the presence of several C-lines (backup servers): if the main one fails, the client will automatically switch to the backup. A line without a backup is a lottery.

Low ECM time and geographical proximity

A server in the same country or region will have lower ECM time physically. 50–150 ms to a server in a neighboring country versus 300–500 ms to a server on another continent. This directly affects the viewing comfort when switching channels.

Support for required packages and protocols

Before purchasing, make sure that the line supports the protocol you need — CCcam, newcamd, CS378x. And that the package of satellites/channels you are interested in is actually included in the line. Request a list of supported CAIDs and providers — a normal source will provide this information without problems.

What should raise concerns

The requirement to install third-party closed software for "activation" of the line — a red flag. Refusal to provide a trial period — also. Lines with extremely low prices for declared "premium" packages are usually unstable or are resales with a large number of hops — ECM time will be high.

And finally: watching paid encrypted content via card sharing without a contract with the rights holder violates the legislation of most countries. Legal risks lie entirely with the user. Keep this in mind.