CCcam Server v1: protocol and config setup

If you searched for "cccam server v1" and expected to find a separate distribution or special version of the program — it does not exist. This designation refers to the revision of the exchange protocol, not a separate product. Understanding this difference is important before you start setting up the server; otherwise, you will spend half an hour downloading the "correct" binary that does not exist.

Below is a complete breakdown: what v1 means in the context of the protocol, how CCcam.cfg is structured, how the handshake works, and what to do when a client connects but there are no channels.

What is CCcam server v1 and how the protocol version differs from the binary version

CCcam as a program was released in versions 2.1.4, 2.2.1, 2.3.0, and so on. These are binary versions — the files you place in /usr/bin/ or /var/bin/. The protocol version is different. It describes the handshake format during a TCP connection and how the server and client agree on the exchange. When people say "cccam server v1," they mean the first revision of this protocol.

The confusion arises because there has never been any official documentation or clear public specification for CCcam. The protocol was reverse-engineered by third-party developers — primarily the OScam and mgcamd teams. They introduced the revision numbering of the protocol.

Protocol version CCcam vs program version (2.1.4, 2.2.1, 2.3.x)

The binaries of versions 2.1.4 and 2.3.0 can both use the same protocol revision. Or they can use different ones. This does not correlate one-to-one. Early builds of CCcam used what is now referred to as v1 — a simplified handshake without some fields that appeared later. More recent builds added fields to the handshake, which led to the emergence of "v2."

In practice, most modern servers operate with the extended format but maintain backward compatibility — a client implementing an old revision will still connect, just not receive part of the extended data.

Where the protocol version is displayed in logs and CWS_DOWN

In standard CCcam logs, the protocol version is not written directly but is visible indirectly. OScam in the oscam.server config for protocol type = cccam writes a line like:

2026/01/15 14:32:11 s   cccam: client connected, version: 2.3.0, nodeid: A1B2C3D4E5F60718

The line "version: 2.3.0" is the version of the binary that the server reports during the handshake, not the protocol revision. The protocol revision can be determined by the set of fields that came in the handshake packet. If you need this information — check the dump via Wireshark or enable maximum debug level in OScam (loglevel = 255).

In the client status lines of CCcam (web interface on port 16001, path /status.html), the version is displayed in the column next to the nodeid of the connected server.

Compatibility of v1 clients with modern servers

Old receivers — Dreambox 500S, 600PVR with firmware from 2009–2011 — sometimes carry CCcam binaries that implement only the early revision of the protocol. Such a client may not be able to negotiate with a modern OScam server: the handshake goes through, but CW (Control Words) do not arrive or arrive with decoding errors.

Solution: in oscam.server for this client, explicitly set the protocol version. The parameter cccversion = 2.0.11 will make OScam imitate the old binary when responding to the handshake, which often resolves compatibility issues without replacing the firmware on the receiver.

Structure of the CCcam.cfg file and key server directives

CCcam.cfg is the only configuration file for the server. It is text-based, without sections, without JSON, without XML. Each directive is a separate line in the format "KEY : value" or "Letter : parameters". Comments start with #.

Path to the config: /var/etc/CCcam.cfg and /etc/CCcam.cfg

On Enigma2 firmwares (OpenATV, OpenPLi, OpenViX), the standard path is/var/etc/CCcam.cfg. On a clean Debian/Ubuntu or Raspbian — usually/etc/CCcam.cfg. Some builds for OpenDreambox place it in/etc/cccam/CCcam.cfg.

If the server does not start and there are no config errors in the logs — first check where it is reading the config from. Run:

strings /usr/bin/CCcam | grep cfg

This will show the hardcoded path in the specific binary.

Directives SERVER LISTEN PORT and WEBINFO LISTEN PORT

Two main ports:

• SERVER LISTEN PORT : 12000 — the port on which CCcam accepts incoming client connections (C-lines from the client side)
• WEBINFO LISTEN PORT : 16001 — the web interface port where you can view the status of channels and connections

It is advisable to change both at once, especially 12000 — it is scanned. More on this in the section about ports.

F lines: (friend) for incoming clients

The F line describes the client allowed to connect to your server. Format:

F: username password uphops downhops {0,0,0,0,0,0,0,0}

Field breakdown:

• username / password — client credentials
• uphops — how many hops up the client can request (usually 0 or 1)
• downhops — how many hops down the server will give to the client (0 = only direct cards, 1 = first-level cards)
• {0,0,0,0,0,0,0,0} — an eight-byte flag mask; a zero mask means "no CAID restrictions"

Example of a minimal working config:

# Main distribution port

Risk with downhops: if a large value (3–5) is set, the card may loop — pass through several servers and return to the source. CCcam tries to detect this through nodeid, but not always successfully. Keep downhops no more than 1 for external clients.

Parameters ALLOW EMM, DISABLE EMM, GLOBAL LISTEN PORT

ALLOW EMM : yes — allows passing EMM (Entitlement Management Messages) from the client to the card. Necessary if the client updates the subscription through sharing. If not needed — disable it, reduces load.

DISABLE EMM : yes — the opposite directive, explicitly blocks EMM. Use one of the two.

GLOBAL LISTEN PORT — an alternative directive for the port, sometimes found in old configs. If both are present —SERVER LISTEN PORT takes priority in most builds, but it's better to keep just one.

Ports, exchange protocol, and network handshake

CCcam operates over TCP. The client establishes a connection, after which an encrypted handshake occurs: exchange of nodeid (unique node identifier), version, and session parameters. All this without TLS — the encryption is proprietary, symmetric, based on SHA1 and XOR transformations. Not ideal from a security standpoint, but that's how the protocol works.

TCP port 12000 and its change for security

Port 12000 is default and widely known. Scanners like Shodan and various brute-force scripts find servers on it within hours. Change it to something in the range of 20000–50000 — this is not protection, but it significantly reduces automated noise.

Conflict with another service on the same receiver — a common problem. On some Enigma2 firmware, port 12000 is occupied by another daemon. Check:

netstat -tlnp | grep 12000

If the port is occupied — change it in CCcam.cfg and restart.

Encryption of handshake and nodeid keys

When CCcam starts for the first time, it generates a unique nodeid — an 8-byte node identifier. It is stored in a file (usually/var/etc/.nodeid or/tmp/.cccam_nodeid). This ID is used during the handshake for identification and preventing loops in the sharing network.

If you clone the receiver or restore from a backup — delete the nodeid file and let CCcam generate a new one. Two nodes with the same nodeid will create problems when sharing through a common server.

Difference between CCcam protocol and newcamd (port 15000) and mgcamd

Three protocols that are most often confused:

Protocol	Default port	Encryption	Features
CCcam	12000 (TCP)	Custom (SHA1+XOR)	Support for hop networks, nodeid
newcamd	15000 (TCP)	DES	One CAID per connection, simpler
mgcamd	—	—	Client, not a protocol; uses newcamd/cccam

mgcamd is a client program, not a separate protocol. It can connect via newcamd or CCcam. Newcamd is simpler: one TCP connection — one CAID, encryption with DES. CCcam is more powerful for building sharing networks: it supports hops and can aggregate cards from multiple sources.

Mixed links like "CCcam client → OScam server" work fine if OScam is configured to receive the CCcam protocol. The reverse link — OScam as a client to a CCcam server — is also supported through the reader type = cccam in oscam.server.

Port forwarding on the router and working behind NAT

Standard scheme: in the router settings, create a Port Forwarding rule — external TCP port (for example, 12500) → internal IP of the receiver, port 12500. After that, a client from the internet can connect using your external IP.

Check that the port is accessible from the outside:

# From another machine on the internet:

If the connection exists but CCcam does not respond — the problem is with the firewall on the receiver itself. Check iptables:

iptables -L INPUT -n | grep 12500

Double NAT and CGNAT — a separate headache. If your provider gives you a gray IP (which is normal for mobile internet and some cable operators), port forwarding won't help — the external IP does not belong to your router. In this case, the only working option is a VPN tunnel (WireGuard or OpenVPN) to a VPS with a public IP, where CCcam or a reverse proxy is set up.

Card sharing setup: C-lines, sharing, and CAID/provider

The logic is simple: the server describes clients through F-lines, the client describes the server through a C-line. These are two ends of one connection.

The format of the C-line on the client side: C: host port user password

On the client side in its CCcam.cfg:

C: 192.168.1.100 12500 client01 secretpass1

Or via the internet:

C: 203.0.113.45 12500 client01 secretpass1

Parameters: host (IP or domain name), port, login, password. The login and password must exactly match what is specified in the F-line on the server. Case matters.

If the client is OScam, then the C-line is not used. Instead, in/etc/oscam/oscam.server a reader is created:

[reader]

Limitation of shared CAID and provider ID

By default, the CCcam server gives the client all cards to which it has access. If you need to limit it — a mask is used in the F-line or a CAID filtering directive.

Example: allow the client only CAID 0x0500 (Viaccess):

F: client01 secretpass1 0 1 {0,0,0,0,0,0,0,0} # no restrictions

For fine filtering by CAID, it is better to use OScam as a server — there, filters are flexibly configured through the ident and caid parameters in profiles. The native CCcam server with CAID filtering is less convenient to work with.

Control of the number of connections and downhops

One F-line = one client. If you want one user to connect from two devices — create two F-lines with different logins. CCcam does not have a built-in parameter "maximum N connections per F-line" — this limitation is implemented at the login level.

downhops in the F-line controls depth: 0 means "I only give out cards that are physically plugged into my receiver," 1 means "I also give out cards that I received from one hop above." Keep this value minimal.

Logs /var/log and debug mode -d

The standard log is written to the path specified in the directiveLOG FILE. If not specified — some builds write to /var/log/cccam.log, some — to stdout.

For diagnostics, run CCcam manually with the debug flag:

# Stop the daemon

In this mode, detailed output will go to the console: connection attempts, handshake, ECM requests, source responses. This is the fastest way to understand why cards are not coming. Look at the ECM, CW, and ERROR lines — they will tell you everything.

Troubleshooting typical CCcam server connection errors

Most problems fall into one of four categories. Let's go through each.

Status 'CWS_CONNECT failed' and reasons

CWS_CONNECT failed means that the TCP connection was not established at all. Reasons in descending order of frequency:

1. Incorrect IP or port in the C-line — a typo
2. Port is closed on the server firewall or not forwarded on the router
3. Server is not running or has crashed
4. Provider blocks non-standard TCP ports (rare, but happens)
5. Double NAT / CGNAT without a VPN tunnel

Diagnostics: telnet from the client machine to the server's address and port. If the connection does not open — this is a network problem, not a CCcam problem. Check the route before diving into the config.

Client is online, but no cards (no cards / 0 cards)

There is a connection, handshake has passed, but the client's status shows — 0 cards. This is one of the most common situations when working with cccam server v1 compatible clients. Check in order:

1. uphops on the client — if the client requests uphops = 0, and the server can only provide cards from a higher hop — nothing will come
2. downhops on the server in the F-line — set to 0, but the card came from a hop? It will not be forwarded to the client
3. CAID mask in the F-line — if the mask is non-zero and does not include the required CAID
4. The source itself does not have active cards — check the status of the server itself, not just the client
5. Expired access — if the server is connected to a paid source with a limited term

FREEZE and long ECM response time

The picture freezes — the ECM request goes to the source, but the CW returns too late. The DVB decoder does not manage to decode the packet before the key changes.

Normal ECM response time — up to 500 ms. If you see values of 1500–3000 ms in the logs — the source is overloaded or the ping is too high. A ping to the server greater than 100–150 ms already poses risks of freeze, especially on channels with frequent CW changes (every 10 seconds).

High ping — a systemic problem, not fixed by configuration. Change the source or raise an intermediate caching node OScam closer to the clients.

Another reason for freeze: mismatch of system time between the server and the client. A discrepancy of more than 5–10 seconds breaks some implementations of the protocol. Check NTP on both.

Access errors to CCcam.cfg and autostart

CCcam.cfg must be readable by the user from whom the daemon is started:

chmod 644 /var/etc/CCcam.cfg

After updating the Enigma2 firmware, file permissions in /var/etc/ are sometimes reset. If the server does not start after the firmware update, first check the permissions.

Autostart on Enigma2 is usually done via a script in/etc/rc3.d/ or through a wrapper plugin. On a clean Debian, create a systemd unit:

[Unit]

Save to/etc/systemd/system/cccam.service, then:

systemctl daemon-reload

After this, the daemon will automatically start on reboot and restart on failure.