Setting up CCcam in OScam: config, protocol, ports 2026

If you have reached this article, it means OScam is already running and you have a C-line, but the client is not connecting or the cards are not appearing. The topic cccam in oscam seems simple at first glance — added reader, restarted, done. In practice, it turns out that half of the manuals on the internet are either outdated or skip key details like group binding or the correct cccversion. Let's break everything down in order, with real configs.

OScam configuration files by default are located in/usr/local/etc/ or/var/keys/ — it depends on the build. To find out the exact path, runps aux | grep oscam and look at the parameter--config-dir. Some distributions place configs in/etc/oscam/.

How OScam works with the CCcam protocol: reader vs sharing

OScam can work with CCcam in two modes. The first is to receive cards from an external CCcam server (client mode), the second is to distribute CCcam cards to clients (server mode). These are completely different settings, and they reside in different files.

CCcam as a client protocol (receiving C-line) in oscam.server

For OScam to connect to a CCcam server and receive cards, a section is needed[reader] in the fileoscam.server with the parameterprotocol = cccam. This is where the host, port, login, and password from the C-line are specified.

OScamdoes not read CCcam.cfg. No file import is provided. A line likeC: server.example.com 12000 user pass needs to be manually parsed into reader section parameters. I will show how exactly below.

CCcam as a server protocol (distribution) in oscam.conf

If you want to distribute CCcam cards to clients (for example, receivers with CCcam firmware or other OScam instances), this is configured through the section[cccam] inoscam.conf and accounts inoscam.user. Two different files, two different traffic directions.

The difference between cccam and cccam_ext

In OScam there are two protocol options:cccam andcccam_ext. The latter is an extended version with support for additional features, including EMM transmission. In practice, the standardcccam is sufficient for most tasks.cccam_ext is used if the server specifically supports extensions and this is stipulated.

An important point: if OScam is built without CCcam protocol support, the parameterprotocol = cccam simply will not work, and an error will appear in the log. You can check with the commandoscam --capabilities — the list should includeprotocol: cccam.

Where OScam stores configs: /usr/local/etc and /var/keys

The file structure is standard:oscam.conf — global settings and protocol sections,oscam.server — reader sections for incoming cards,oscam.user — accounts for clients,oscam.srvid — channel database. All in one directory, the path to which is determined during compilation or by the flag--config-dir.

Setting up C-line reception: reader section in oscam.server

This is the most common task — you have a C-line from the provider, and you need to make OScam work with it.

Transforming C: line into reader parameters

Let's take a typical C-line:

C: my.server.com 12000 myuser mypassword

Here’s how it turns into a reader section:

[reader]

The parameterdevice — is the host and port separated by a comma. No spaces. This mistake is made most often.

Some C-lines contain additional flags in curly braces:C: my.server.com 12000 user pass { 0:0:2 }. The numbers in curly braces usually denote the reshare and hop parameters. In OScam, they are not transferred directly — instead, usecccmaxhops in the reader section.

Mandatory parameters: label, protocol, device, user, password

Withoutlabel OScam will not be able to identify the reader in the logs and webif. Use meaningful names, especially if there are multiple readers.protocol = cccam — is mandatory, without it OScam will not understand what to do with the device.device,user,password — are obvious.

The parameters cccversion, cccmaxhops, cccwantemu

cccversion — is the version of the CCcam protocol that OScam will emulate during the handshake with the server. Common values:2.0.11,2.1.4,2.2.1,2.3.0. If the server is set to a specific version and you specify another — you will receive a login denial or unstable operation. Ask your provider, or try2.3.0 as the most common.

cccmaxhops limits the depth of card hops that the reader accepts. A value of10 — is sufficient for most cases. If you want only local cards (hop 0) or direct ones (hop 1), set1.

cccwantemu = 1 is needed in rare cases: when the server only provides cards to those clients who explicitly requested emulation. By default —0. If cards do not appear specifically from a certain server — try enabling it.

group, caid, ident and card filtering

Parametergroup — is the glue that connects the reader with users during sharing. The reader withgroup = 1 only gives cards to those users inoscam.user who also havegroup = 1. If the groups do not match — the cards exist, but do not reach the clients. A classic trap.

caid andident — are filters for specific systems and providers. If specified, the reader will only accept cards of the required CAID. Convenient when there are multiple readers with overlapping CAIDs — you can clearly delineate priorities. But during the debugging stage, it's better to remove these filters to rule them out as a cause of problems.

Full example of a working section

[reader]

Several readers with overlapping CAIDs? Assign them different groups and manage priority throughcacheex or the order in oscam.server — OScam polls readers from top to bottom.

CCcam sharing setup: section [cccam] in oscam.conf and oscam.user

If you want to share cards with clients using the CCcam protocol, the configuration is divided into two parts.

The port parameter in [cccam] and the version/build format

Inoscam.conf add the section:

[cccam]

Port12000 — the de facto standard for CCcam, but you can set any free one. The main thing is that it must match the port in the C-line that you provide to clients and be open in the firewall.

version andbuild — are what OScam will report to clients during the handshake. The values2.3.0 /3 work with most modern clients.

Creating a client in oscam.user

Each CCcam client must have an account inoscam.user:

[account]

Pay attention togroup = 1 — it must match the group of readers from which this client should receive cards. Without this, the client will connect but will not see any cards.

cccmaxhops, cccreshare and uphops/downhops

These are two different parameters that are often confused, and it is important.

cccmaxhops — how many hops a card can go through before OScam accepts or gives it. A value of1 means "only direct cards." If your source itself receives cards through several hops, and you setcccmaxhops = 1 — there will be no cards.

cccreshare — permission for the client to share your line further.0 — prohibited,1 — allowed for one level. For security, set0, if you do not want your cards to spread uncontrollably.

Binding group between reader and user

The logic is as follows: a reader withgroup = 1 puts cards in the "basket" of group 1. A user withgroup = 1 sees this basket. If the reader has group = 2, and the user has group = 1 — there will be no cards, even if the reader is working and there are cards. A simple scheme, but it breaks half of the setups for beginners.

With multiple readers with different CAIDs, it is convenient to assign different groups and manage access selectively: one user sees only the Hotbird package, another sees both Hotbird and Astra.

Checking distribution through the web interface

The OScam Webif is available by default on port 8888 (or 8080 — depending on the build). In theStatus section, all connected readers and their status are visible, in theUsers section — active client sessions. If a client connects via CCcam, they will appear in the list with the protocol indicated. The number of cards the client sees is displayed in theCards column.

Diagnostics and typical connection errors

Most problems with cccam in oscam are solved by reading the log. But first, you need to know what exactly to look for.

Reader in CONNECTED status but no cards (no cards)

This is the most common situation. The reader shows CONNECTED, but in the webif, the card column shows — 0. There are several reasons, and they are checked in order.

First — checkcccmaxhops. If the server returns cards with hop 2 or 3, and you havecccmaxhops = 1, they will simply be filtered out. Temporarily setcccmaxhops = 99 for testing.

Second - group. The reader must be in the same group as the request for distribution. If cards "arrive" in group 2, and the handlers are looking at group 1 - the result is zero.

Third - the server may intentionally not return share. Some servers are configured to only return via CCcam under the condition ofcccwantemu = 1 on the client side. Try enabling it.

Errors in the logs: connection error, login failed

login failed almost always means incorrect user/password or mismatch incccversion. Check both. Some servers strictly check the version during the handshake -2.0.11 and2.3.0 may be perceived differently.

connection error or constant reconnections - a problem at the network level: the server is unavailable, the port is closed by a firewall (yours or on the server side), or the host resolves to an incorrect IP. Check with ping and telnet:telnet my.server.com 12000.

Problems with cccmaxhops and missing CAID

Sometimes, some channels work while others do not. This is almost always a matter of hops or CAID filters. In the webif in the reader section, you can see which cards it sees. If the required CAID is not there - either the server does not provide it, or it is filtered out by thecaid parameter in the reader section.

Reading oscam.log and enabling debug levels

Run OScam with extended logging:

oscam -c /usr/local/etc -d 64 -l /tmp/oscam.log

The mask-d 64 enables debug for readers. The full mask-d 255 gives everything - useful, but noisy. In the config, you can set it up throughoscam.conf:

[global]

Filter the log by the label of the reader:grep "provider_main" /tmp/oscam.log. Look for lines withlogin,CONNECTED,cards — here is the entire connection history.

Port and firewall check (iptables)

Check that OScam is listening on the required port:

netstat -tulpn | grep 12000

Or via ss, if netstat is unavailable:

ss -tulpn | grep 12000

Add an iptables rule for incoming client connections:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT

If OScam is behind NAT, clients need an external IP, not an internal one. Port forwarding on the router: external 12000 → internal IP:12000. In the C-line you provide to clients, specify the external IP or domain, not192.168.x.x.

How to choose a C-line source: criteria without advertising

Implementing cccam in oscam is the technical part. But the quality of work depends 50% on the quality of the C-line itself. Here’s what to look for when evaluating the source.

Stability of uptime and ping to the server

Ping to the server should be below 100 ms for comfortable operation. At 200+ ms, zapping between channels will noticeably slow down. Just check:ping my.server.com. Uptime should be above 99% — anything lower means regular drops during prime time.

A trial period is a mandatory condition for a normal provider. A few days is enough to assess stability during different time intervals: night, morning, Friday evening — the load varies.

Number of hops and local cards

The fewer hops, the faster the response to the ECM request. The ideal ishop 0 (local card directly in the server) orhop 1. Athop 3+ delays accumulate, and some channels start to flicker.

In the OScam web interface, in the reader section, you can see which hop the cards came from. This is a good diagnostic tool for assessing the quality of the source after connection.

Support for required CAID and packages

Before connecting, clarify which CAIDs are supported. Popular ones:0x0500 (Viaccess),0x0600 (Irdeto),0x0B00 (Conax),0x0D00 (CryptoWorks),0x0E00 (PowerVU),0x1800 (Nagravision),0x0100 (Seca). If the required CAID is not available, the other parameters are not important.

Also clarify whether the required package is supported on the specific transponder. The CAID may exist, but the package may not.

Transparency of conditions and trial period

A good sign is when the provider specifies restrictions in advance: the number of simultaneous connections, the allowable number of hops for re-share, the policy on EMM. This means that the conditions are clear and there will be fewer surprises.

And most importantly: card sharing can only be used legally with cards for which you have a valid subscription. Sharing your own card for personal use on multiple devices is allowed in most cases according to the provider's terms, but transferring to third parties is a different story. Check your operator's terms.