CCcam server v1: protocol setup and config 2026

If you typed "cccam server v1" into a search engine and reached this article, you probably already know what card sharing is, and you don't need an explanation of the basics. You are either trying to set up a server on old hardware or figuring out why the client cannot connect to the server that calls itself v1. Let's break this down in simple terms, with real config examples and without fluff.

What "CCcam server v1" and protocol versions mean

This is where almost everyone gets confused. When someone says "cccam server v1," they may mean two completely different things: the version of the exchange protocol or the version of the program binary. These are not the same, and mixing them up is the first step to unclear bugs.

CCcam protocol version vs program version

The CCcam binary exists in versions like 2.1.3, 2.1.4, 2.2.1, 2.3.0 — this is just the build number of the program. The exchange protocol is a separate story. It describes the handshake format, the structure of ECM requests and responses, and the method of encrypting the initial exchange.

What is commonly referred to as "v1" is the original CCcam protocol that was used in binary versions up to about 2.2.x. It operates over TCP, with port 12000 by default. There is no official document titled "CCcam protocol v1" — this is a colloquial designation that has become established in the community.

How the server and client agree on the version during handshake

When establishing a connection, the client sends the server a string with the CCcam version number and build number — something likeCCcam 2.1.4 build 3076. The server looks at this string and decides whether to allow the client or not. Old servers on 2.1.x often refuse clients with a newer version — they simply do not understand the string and drop the connection.

That is why OScam has the parametercccversion — it manually specifies what the client will present to the server. Specify2.1.4, and the old server will accept you.

Where v1 is still found and why you shouldn't stick with it

Old configs, forum guides from 2010–2015, some firmware for receivers based on old STi chips — "v1" appears everywhere there. Many emulators (NewCS, MPCS) declare compatibility specifically with this protocol format.

But staying on a pure CCcam binary of an old version in 2026 is a bad idea. Development has stopped, vulnerabilities are not being patched. OScam as a replacement server has long surpassed it in stability and functionality. Nevertheless, understanding how the protocol works is necessary; otherwise, you won't be able to debug.

Configuring CCcam.cfg on the server side

The configuration file is everything. One incorrect directive, and the server silently does not provide cards to clients. Let's start with where to look for this file at all.

File location: /var/etc/CCcam.cfg and /etc/CCcam.cfg

On Enigma2 receivers (VU+, Dreambox, and clones), the file is located in/var/etc/CCcam.cfg. On some images — in/etc/CCcam.cfg. The specific location depends on where the plugin is installed and what image is flashed.

A common trap: you edit/etc/CCcam.cfg, but the server reads/var/etc/CCcam.cfg. Changes are not applied, restarting does not change anything, and you waste an hour debugging. Check the symlinks with the commandls -la /etc/CCcam.cfg — often this is just a link to/var/etc/CCcam.cfg.

Directive F: line — login, password, uphops, downhops

LineF: adds a client (peer) that is allowed to connect to the server. Format:

F: username password 1 0 0

The third number —uphops: how many hops the server accepts from this client (incoming depth). The fourth —downhops: how many hops the client can share further (0 means — only for itself). The fifth number — the allow_sidescanning flag.

If you set uphops = 0, the client does not transmit its cards to the server at all. If downhops = 0, the client cannot become an intermediate server for the next level. That's why many have "cards available, but not shared" — downhops is set to 0, and the client lower in the chain sees nothing.

SERVER LISTEN PORT and ALLOW TELNET parameters

The basic server block looks like this:

SERVER LISTEN PORT : 12000

Port 12000 — for client connections. Ports 16001 and 16002 — for management and statistics. ALLOW TELNET opens console access, which is convenient for debugging but dangerous on a public IP: port 16001 does not require authentication by default. If the server is exposed to the internet — close it with a firewall or turn it off completely.

Sharing local cards via SERVER ECM/EMM

To share a card from a local smart card reader, you need to ensure that CCcam sees the reader and adds it to the share list automatically. The directivesIGNORE CAID andALLOW CAID filter which CAIDs are included in the share:

ALLOW CAID : 0500

Without explicit specification, CCcam shares everything it sees. This is not always desirable, especially if several readers with different cards are connected to the server.

Client connection: line C: and connection check

On the client side (another receiver or OScam), the connection to the server is specified by the lineC:.

Syntax C: hostname port username password

Minimum format:

C: my.server.host 12000 myuser mypassword no

Extended version with CAID and provider filter:

C: my.server.host 12000 myuser mypassword no { 0500:030B00 }

Curly braces define the filter:CAID:ProviderID. If you specify an incorrect CAID or make a typo in the provider ID — the client will connect, cards in the share list will be visible, but ECM requests to them will not be sent. It looks like a working connection, but there is no decoding. This is one of the most insidious errors.

Additional flags: wantemus, no/yes

The fifth parameter in line C: — the flagno/yes, it controls whether the client wants to receive EMM from the server. Most clients needno.yesneeded only if the server must update the client's card keys — a rare scenario.

Status check via webif (port 16001) and telnet

The CCcam web interface is available athttp://[receiver-ip]:16001 (or 16002, depending on the config). There are three important sections: Connected clients, Connected servers, and Shares.

In Shares, look at the columns:CAID (card type),hop (number of intermediate servers to the card),ECM time (response time in milliseconds). Hop = 0 — the card is local. Hop = 1 — the card is on the first server in the chain. The more hops, the higher the likelihood of a freeze.

Reading the log file and the CCcam -s command

The CCcam log on Enigma2 is usually written to/tmp/CCcam.log. View in real time:

tail -f /tmp/CCcam.log

The commandCCcam -soutputs the current state of the daemon to the terminal — active connections, share list, ECM statistics. Works only if CCcam is running and telnet is enabled.

Debugging typical v1 protocol errors

Most problems with cccam server v1 fall into a few scenarios. They are not difficult to diagnose if you know where to look.

Connection reset / login failed

“Login failed” in the log — first check the username and password in the F: and C: lines on both ends. They must match exactly, case is important. But if the login and password are correct, and the connection still resets — look at the node id.

Node id — a unique identifier for the CCcam client, generated from the MAC address or set manually. If two clients with the same node id connect to one server — the server drops both connections without a clear error in the log. It looks like a flapping connect: connected, dropped after 10–30 seconds, connected again. It can be fixed by changing the node id inCCcam.cfg of one of the clients with the directiveNODEID.

Version mismatch: client too old / version mismatch

An old CCcam server (version 2.1.x) may reject clients with a newer version string during handshake. The log will show something like “client version not supported” or the connection simply drops silently after the first exchange.

If you are using OScam on the client side — specifycccversion = 2.1.4 in the reader's config. If the CCcam client — find a binary of the same version as the server, or slightly older. Newer — risky.

Uphops issue and absence of cards in the share list

The client connected, the connection is displayed in webif, but Shares is empty. The first thing to check is the uphops parameter in the F: line on the server. If it is set to 0, the server does not pass the card list to the client at all. Set it to 1 for standard sharing.

The second option — the server shares cards, but the client filters them with a CAID filter in parentheses. Temporarily remove the filter from the C: line and check if the cards appear in the share list.

FREEZE and long ECM time

Picture freeze with a normal connection almost always indicates a high ECM time — more than 600–800 ms. Reasons: many hops (hop 3+), overloaded server, poor channel between client and server, or too many clients simultaneously requesting one CAID.

Check the ECM time in webif. If it's 1500+ ms — the problem is on the server or network side. If the ECM time is normal (200–400 ms), but there is a freeze — look at the receiver's decoder and buffer settings.

Linking CCcam protocol v1 with OScam

OScam can work with cards directly as well as through the CCcam protocol — acting as both a server and a client. This makes it a versatile tool for any configuration.

Configuring [cccam] reader in oscam.server

To connect OScam to cccam server v1 as a client, add a reader in/etc/oscam/oscam.server (or/var/etc/oscam/oscam.server on Enigma2):

[reader]

The parameterprotocol = cccam tells OScam to use the CCcam protocol for this reader.device — host and port separated by a comma without a space.

The parameters cccversion and cccmaxhops

cccversion — the version string that OScam will present to the server during handshake. For compatibility with the old cccam server v1, set2.1.4. If the server is newer — you can try2.3.0.

cccmaxhops limits the maximum number of hops for cards accepted from this server. Set 1–2 for normal operation. A value of 0 means only local server cards (hop 0). A value that is too high — OScam will pull cards with hop 5–6 and get a high ECM time.

Distribution through oscam.user with groups

Routing in OScam is built through groups. Inoscam.server the reader belongs togroup = 1. Inoscam.user you allow the user to use this group:

[account]

If the groups do not match — the user does not see the reader's cards. A classic mistake when transferring configs.

When OScam is preferable to the old CCcam binary

Honestly: almost always. OScam is actively developed, supports multiple protocols, has a decent web interface with detailed statistics, and logs errors well. The old CCcam binary has not received updates since the mid-2010s.

The only reason to stay on pure CCcam is specific hardware where OScam does not work for some reason. Such cases are practically nonexistent in 2026. If you can migrate to OScam — migrate.