Setting up CCcam in OScam: reader and cccam protocol

If you googledcccam in oscam and found only a bare config without explanations — this article is for you. OScam can work as a full-fledged CCcam client: connect to someone else's server via C-line, receive cards, and decode ECM. But there are several parameters, without understanding which the reader will hang in the CONNECTED status with zero cards, and you won't understand why.

Here is a practical breakdown of the setup from scratch: config, diagnostics, typical errors, and reading logs.

What is a cccam reader in OScam and why is it needed

OScam is not just an alternative to CCcam. It is a full-fledged conditional access system with its own routing, caching, and flexible CAID management. One of its operating modes is the cccam protocol client: OScam connects to a CCcam or OScam server just like the original CCcam.cfg would with a C-line.

cccam protocol as a client reader

A C-line string of the formC: host port user pass in OScam terms — is the section[reader] in the oscam.server file. The parameterprotocol = cccam tells the daemon which protocol to use to communicate with the server. Then OScam handles the handshake, card exchange, and ECM requests itself.

The concept is simple, but the devil is in the details of the configuration. Especially in the parametercccversion, which most tutorials do not explain at all.

The difference between the OScam client and the original CCcam

The original CCcam reads the C-line from /etc/CCcam.cfg and manages connections itself. OScam provides significantly more control: you can filter CAIDs and providers at the reader level, limit the number of hops, manage ECM timings, cache CW, and set priorities between multiple sources.

Practically, this means: the same set of C-lines in OScam works more stably and predictably than in native CCcam. Plus — all statuses are visible in WebIF in real time.

When to use cccam and when to use newcamd/cs378x

If the server provides CCcam shares — useprotocol = cccam. If you have an N-line — this is newcamd (protocol = newcamd). CS378x — for CS378x/CS357x clients. Do not try to connect a CCcam server via newcamd: the handshake is different, the connection will not be established.

Setting up a reader with the cccam protocol in oscam.server

The oscam.server file is where all card sources are described. The path depends on the firmware: on Enigma2 it is most often/etc/tuxbox/config/oscam.server, on some images —/var/etc/oscam.server or/usr/keys/oscam.server. File permissions — 644, owner — the user under which OScam is running.

Basic example of the [reader] block

Here is a working example of a section for one C-line:

[reader]
label                = myline01
protocol             = cccam
device               = server.example.com,12000
user                 = myuser
password             = mypassword
inactivitytimeout    = 30
group                = 1
cccversion           = 2.1.4
cccmaxhops           = 5
cccwantemu           = 0
cccnodeid            = 0102030405060708
audisabled           = 1

This is the minimally necessary and working config. Each parameter here is not decoration, but a specific behavior setting.

Parameters device, user, password, and port

In the parameterdevice — host and port separated by a comma without a space:device = hostname,port. The port for CCcam servers is most often 12000 or 12001, but can be anything.user andpassword — exactly what you were given in the C-line. Case matters, spaces do too.

An important point: if the password contains special characters like# or=, OScam may parse it incorrectly. In such cases, try wrapping the password in quotes or ask the provider to change it.

cccversion: 2.0.11, 2.1.1, 2.1.4 and why this is important

This is the most underrated parameter in the entirecccam in oscam setup. The protocol version must match what the server expects. If the server is running on CCcam 2.1.4 and you specified 2.0.11 — the line will come up, the handshake will pass, CONNECTED will light up green. But the cards will not come.

The most common options:2.0.11,2.1.1,2.1.4. On servers with the original CCcam, it is most often 2.1.4. OScam servers often emulate 2.0.11 or 2.1.1. If you are not sure — start with 2.1.4, then try 2.0.11.

There are servers with a non-standard version not included in the standard OScam list. In this case, you can try to specify the version manually as a string, for examplecccversion = 2.3.0 — OScam will pass it as is during the handshake.

cccmaxhops, cccwantemu, and cccnodeid

cccmaxhops = 5 limits the depth of sharing: cards with a hop count greater than 5 will not be accepted. For stable operation, I recommend setting no more than 3–5. The fewer hops, the faster the ECM.

cccwantemu = 0 — disables the request for emulated cards (software decoders). If you only need physical cards, keep it at 0. If the server provides softcam shares and you want them — set it to 1.

cccnodeid — a unique identifier for your node in the CCcam network, 8 bytes in hex. If you connect multiple readers from one IP address to one server, each reader must have its own unique nodeid. Otherwise, the server will see a duplicate and cut off the second line.

group, caid, ident, and audisabled

group = 1 connects the reader with users in oscam.user who havegroup = 1. If your clients are in group 2 — set it to 2 here as well, otherwise the routing will not work.

audisabled = 1 disables Auto-Update (AU) for this reader. For CCcam shares, this is almost always necessary. AU on the share is a sure way to get banned on the server: it will try to update an entitlement that does not belong to it.

Parameterscaid andident allow you to strictly limit which CAIDs and providers should go through this reader. For example,caid = 0500 — only Viaccess. If the channel does not open, even though there are cards — check these filters first.

Connection check and diagnostics

Configured the config — restart OScam with the commandkillall -HUP oscam or by fully restarting the daemon. After that, go to WebIF.

OScam web interface: reader status and card list

WebIF is available by default on port 8888:http://[ip-set-top-box]:8888. The port is set in the[webif] section of oscam.conf with the parameterhttpport. TheReaders tab will show a list of all readers with their current status.

You need to see: statusCONNECTED and the number of cards (entitlements) greater than zero. If there are zero cards — check the logs, the reason is there. A green connection status ≠ a working line.

Reading oscam.log and debug levels

The log is located at the path specified in[global] section of oscam.conf — parameterlogfile. Typically, this is/var/log/oscam.log or/tmp/oscam.log. The logging level is the parameterloglevel, values from 0 (off) to 255 (maximum).

For diagnosing the reader, setloglevel = 64 or higher. Level 255 will provide very detailed output but will heavily load the flash memory. After resolving the issue, reduce it to 16 or 0.

CW logs are written separately to the directory specified in thecwlogdir parameter. Each file there is the history of requests for a specific CAID.

Monitoring command and ECM time counter

In theECM Info tab or directly on the reader page in WebIF, you can see ECM time — the average response time in milliseconds. A good indicator is up to 300–350 ms. Anything above 700 ms will cause freezes on fast channels.

Also, check the ratio: decoded/total. If 950/1000 — everything is fine. If 400/1000 — half of the ECM requests do not return CW, and this is a problem. Reasons: overloaded server, poor channel, mismatch of CAID filters.

Checking CAID routing and share

If the reader is connected and there are cards, but a specific channel does not open — check theShare Info orServices tab. There you can see which CAID and SID are available through each reader. It is possible that the required CAID is filtered by theident parameter or is not included inservices.

Also, make sure that the groups of the reader and the client account in oscam.user match. This is a common reason for "cards are present — channel does not open."

Typical errors and troubleshooting

Most problems withcccam in oscam fall into several scenarios. Let's go through each in order.

Reader CONNECTED, but 0 cards

The first suspect is a mismatch incccversion. Open the log, look for a line likecccam login failed orno cards next to the reader name. If the login was successful but there are no cards — try sequentially 2.1.4, 2.0.11, 2.1.1.

The second option: the account on the server is active but without linked cards. Check with the provider that your data indeed has shares. Third:cccmaxhops is too low, and all available cards have a greater number of hops.

Constant reconnections and inactivity timeout

inactivitytimeout — time in seconds after which OScam considers the reader to be stuck and reconnects. A value that is too low (5–10 seconds) on a normal but not very active line will cause constant reconnections. Set it to 30–60 seconds.

If reconnections occur every few minutes regardless of the timeout, the problem is either an unstable network or the server itself is dropping the connection (session limit, duplicate nodeid, payment period has expired).

Wrong CW / ECM checksum failed

These errors in the log mean that the CW was received, but OScam rejected it as invalid. Reasons: OScam server is sending CW from another CAID/provider, version incompatibility, or a genuinely corrupted response. Try the parameterdisablecrccws = 1 in the reader section — it disables CRC checking. This is a temporary solution, but it helps diagnose the issue.

Nodeid conflict and blocking on the server

If you connect two readers from the same IP to one server without unique nodeids, the server sees two nodes with the same identifier. It will keep the first and disconnect the second, or block both. The log will show something likeduplicate nodeid.

The solution is simple: assign each reader its owncccnodeid. Generate random 8-byte hex values; they must be unique within the network. For example:cccnodeid = A1B2C3D4E5F60708 for the first reader andcccnodeid = 0807F6E5D4C3B2A1 for the second.

File permission issues with configuration files

OScam will not start properly if it cannot read oscam.server. Permissions should be 644:chmod 644 /etc/tuxbox/config/oscam.server. If OScam is run as root, permissions are not critical, but this is bad practice. Also check the permissions on the directory.

After any changes in the config, a restart is mandatory. Some parameters are read by OScam "on the fly" through WebIF (Reload button), but changes in [reader] require a full restart.

How to choose a stable source for C-line (without advertising)

Setting upcccam in oscam is only half the task. The other half is the quality of the line itself. A poor source will cause freezes even with an ideal config.

Stability criteria: uptime and ECM time

A good ECM time for normal operation is consistently up to 300–400 ms. Peaks up to 600–700 ms are acceptable, but if the average over 24 hours is above 500, there will be freezes on rapidly changing channels (sports, news). Check not just one point, but the dynamics over 24 hours in the logs.

Uptime is how much time the reader spent in the CONNECTED status out of the total observation time. Less than 95% is a problem. This number can be found in the CW logs: count the intervals without responses.

Local cards versus resellers and hops

The number of hops is how many nodes the request passed from your client to the physical card. Hop 1 means that the card is directly on the server you are connected to. This is the ideal scenario: minimal delay, no dependency on intermediate servers.

Hop 3–5 means it is a reseller: the server itself is a client somewhere else. Under peak load, the chain may not cope, and the ECM time skyrockets. Check in WebIF for the number of hops for specific cards — OScam shows this.

Signs of an overloaded or unstable server

If the ECM time sharply increases in the evening (20:00–23:00) — the server is overloaded. If the reader regularly reconnects every 15–30 minutes — there is a problem with the source infrastructure. If specific CAIDs disappear from the card list for a few minutes and then reappear — the card on the server is periodically unresponsive.

Test any new line for at least 24 hours, including night and evening times, before drawing conclusions. One good hour means nothing.