CCcam lines: setting up C-line and F-line in 2026

If you are holding a line likeC: server.example.com 12000 myuser mypass for the first time and do not understand what to do with it — this article is for you. CCcam lines are not just "lines to insert into the config". Each field has meaning, and an error in any of them will result in either "connected, 0 cards" or a complete connection timeout. Let's break it down step by step: format, syntax, where to insert, what to do when it doesn't work.

What is a CCcam line and why is it needed

A line in the context of CCcam is a line in the configuration file that describes the parameters of a single connection. Not a magic link, not an authorization token — just a text entry with a host, port, username, and password. The entire CCcam protocol is built on such exchanges: the client connects to the server via TCP, authenticates, receives a list of available cards, and requests the decryption of ECM packets.

By default, the protocol operates on TCP port 12000, but this is not a strict requirement — the port is explicitly specified in the line itself and in the server config. If your provider says "port 17000" — write it that way.

Definition of C-line, F-line, N-line

C-line (Client line) — client line. You insert it into your config, and CCcam connects to someone else's server. This is the incoming traffic line from your side.

F-line (Friend line) — server line. It describes the client to whomyou allow to connect to your server. The logic is reversed: not "where to go", but "who to let in".

N-line — line for the Newcamd protocol. The format is different:N: host port user pass key. It is used less frequently but appears in mixed configurations where a CCcam client connects to a Newcamd server or a local card reader.

How the client differs from the server in CCcam

In CCcam, one installation can be both a client and a server at the same time. Your receiver with a C-line connects upwards to the provider, and if you have F-lines specified — you are distributing downwards to your clients. This is a cascading model (reshare), and it is controlled by the parameters uphops/downhops.

How the line is related to the CCcam protocol

After the TCP connection, CCcam performs a handshake: exchanges SHA1 hashes for authentication, then the server sends a list of available CAIDs and providers. Next, the client sends ECM requests, and the server returns CW (Control Word) for decryption. All this happens within a single TCP connection described in the C-line. No C-line — no connection.

C-line format: breakdown of each field

The basic syntax looks like this:

C: hostname port username password

Example:

C: example.host 12000 testuser testpass

No quotes, no semicolons. Just spaces between fields. If there is an extra space or character somewhere — CCcam will ignore the line or throw a parsing error in the log.

Syntax: C: hostname port username password

hostname — domain name or IP address of the server. It is better to use a domain rather than an IP: if the server has a dynamic address with DDNS (for example, through DuckDNS or No-IP), the IP will change, while the domain will remain. Do not write0.0.0.0 in the actual line — it is a placeholder.

port — TCP port on which the CCcam server listens. The standard is 12000, but servers often use 11000, 15000, 17000, and others. The provider always specifies a specific port — do not guess.

username / password — credentials issued by the provider for your account. Case-sensitive.TestUser andtestuser — different logins.

Additional parameters (no/yes, encryption flags)

You can add additional parameters after the password. The most common:

C: example.host 12000 testuser testpass no { 0:0:0 }

no /yes — traffic encryption activation flag (AES). Most providers useno, meaning encryption is disabled. If the server requiresyes — specify explicitly, otherwise the handshake will fail.

Block{ 0:0:0 } — CAID filter. You can limit which cards to request from this server. Not needed in most cases, but useful in case of conflict between several C-lines with the same CAID.

Where to insert C-line in CCcam.cfg

On Enigma2 (Dreambox, VU+, Zgemma, and similar) the config is located at:

/var/etc/CCcam.cfg

On some builds and distributions of Linux:

/etc/CCcam.cfg

Open the file in any text editor (nano, vi, WinSCP + Notepad++), add the C-line on a separate line. You can write several C-lines in a row — CCcam will connect to all of them and will use the first available card for each CAID.

After editing, a restart of the daemon is needed:

init 4&& init 3   # Enigma2

Example of a working line with field explanations

C: myserver.dyndns.org 12000 client01 xK9pL2mN no

• myserver.dyndns.org — DDNS server name (not a static IP)
• 12000 — standard CCcam port
• client01 — unique login for this connection
• xK9pL2mN — password, at least 8 characters, preferably random
• no — encryption is disabled

Format of F-line and setting up your own server

F-line is needed when you become a server yourself and want to give someone access to your cards. Each F-line is one allowed client.

F-line syntax: F: username password uphops downhops

F: frienduser friendpass 1 1

Fields:

• username — client login
• password — client password
• uphops — how far the client can reshare cards further (reshare depth). 0 = reshare is prohibited, 1 = client can share one level down
• downhops — how many levels of cards below the client can see. 1 — sees only direct cards from the server

Reshare and uphops/downhops parameters

This is the most commonly misunderstood part. Uphops = 0 means: the client receives cards but is not allowed to reshare them to their clients. Uphops = 1 — can share one level down. The higher the value, the further the card spreads through the network, the more load and delay on ECM.

Downhops controls visibility. With downhops = 1, the client sees only the cards that are directly on your server. With downhops = 2 — sees the cards from your upstreams as well. For most configurations,1 1is sufficient.

F-line binding with a connected card or reader

F-line itself is not tied to a specific card — the client gets access to everything your CCcam sees. To restrict access to certain CAIDs, the directiveALLOW is used after the F-line:

F: frienduser friendpass 1 1

You also need to specify the port for incoming connections in CCcam.cfg:

SERVER LISTEN PORT: 12000

Security: unique logins and passwords

Never give two clients the same login. If one client starts to abuse or their config leaks — you won't be able to block them without affecting the second. Unique credentials = full control: if one client misbehaves — remove their F-line and restart the daemon.

Passwords should be generated randomly:openssl rand -hex 8 will give a 16-character string that cannot be brute-forced.

Equivalent in OScam: translating line to OScam config

Many use OScam instead of CCcam — it is more flexible, actively supported, and works better with multiple protocols simultaneously. But cccam lines as such do not exist in OScam — instead of lines, there are sections in INI files. Here’s how to translate.

C-line as [reader] with protocol = cccam

C-line of the formC: example.host 12000 user pass turns into a section in theoscam.server file:

[reader]

The file is located at/etc/oscam/oscam.server or/var/keys/oscam.server depending on the build. On Enigma2 with the OScam plugin — usually/etc/tuxbox/config/oscam/.

F-line as [account] in oscam.user

F-line for distributing to clients is specified inoscam.user:

[account]

Parametercccmaxhops here is equivalent to uphops in CCcam F-line.uniq = 1 prohibits simultaneous login with the same username from different addresses — useful protection.

Files oscam.server and oscam.conf

The main config of OScam —oscam.conf. It is configured, among other things, on which port to listen for CCcam clients:

[cccam]

Without the section[cccam] in oscam.conf OScam will not accept incoming connections from CCcam clients, even if there are correct accounts in oscam.user.

Comparison of CCcam and OScam behavior

Parameter	CCcam	OScam
Client line	C-line in CCcam.cfg	[reader] in oscam.server
Server line	F-line in CCcam.cfg	[account] in oscam.user
Server port	SERVER LISTEN PORT in .cfg	[cccam] port in oscam.conf
Reshare management	uphops/downhops in F-line	cccmaxhops in oscam.user
Web interface	Port 16001	Port 8888 (configurable)

OScam handles mixed configurations better, where CCcam, Newcamd, and local card readers operate simultaneously. CCcam is easier to set up initially — one line, and everything works.

Diagnostics: why line is not working

“Connected, but nothing is showing” — the most common complaint. Let's break it down step by step.

Checking connection status (CCcam Info, web interface)

First, open the CCcam web interface. By default, it is available on port 16001:

http://<receiver_IP>:16001

There you can see: a list of connected servers (C-lines), the status of each (connected / disconnected), the number of cards, hops, the last activity time. If the server shows “connected, 0 cards” — the connection is there, but there are no cards. This is a problem on the server side (card not inserted, CAID does not match, account is limited).

In Enigma2, there is also a CCcam Info plugin that shows the same data in the receiver's GUI.

Reading logs and values of hops/cards

The CCcam log is written to/tmp/cccam.log or/var/log/cccam.log. Look for:

• connected to server — connection established
• got X cards — received cards
• ECM timeout — the server did not respond to the decryption request in time
• wrong password /authentication failed — invalid credentials

A large number of hops (4–6 and above) means that the card is far down the reshare chain. Each additional hop adds delay to the ECM response. If ECM takes more than 1500–2000 ms, the channel will freeze or not open at all.

Network checks: ping, telnet to port, firewall

If there is no “connected” line in the log at all — it is a network problem. Step by step:

1. Check DNS:

nslookup example.host

If the domain does not resolve — there is a DNS problem. Try temporarily replacing it with an IP.

2. Check port availability via telnet:

telnet example.host 12000

If the connection cannot be established and after a few seconds “connection refused” or timeout — the port is closed. Either the server is not listening, or the firewall is blocking. Some internet providers deliberately block port 12000 — in this case, ask the server to move to a non-standard port (for example, 443 or 8080).

3. NAT and port forwarding. If you are raising a server (F-line) and clients cannot connect — most likely, the port is not forwarded on the router. In the router settings, you need to create a Port Forwarding rule: TCP, external port 12000 → internal IP of the receiver, port 12000. Without this, external connection is physically impossible.

Typical errors: incorrect port, DNS, ECM blocking

Dynamic IP without DDNS. If the host in the C-line is specified as an IP, and the server has a dynamic address — when the IP changes, everything stops working. Solution: DDNS client on the server (ddclient, inadyn) + domain name in the C-line instead of IP.

Conflict of multiple C-lines with the same CAID. When you have two C-lines, both providing access to the same CAID — CCcam selects the first available one. If you want to explicitly set priority or limit each line to its own set of CAID, use the block{ CAID:provider } after the password.

ECM timeout and freeze with high hops. Typical scenario: the server is connected, cards are visible (for example, 5 cards, hops 4), but the channels freeze. CCcam Info shows ECM time of 1800–2500 ms. This is a borderline value — it works with a good channel, but fails under any load or network delay. Look for a more "local" source of cards with hops 1–2.

And finally: if you are transferring the configuration between CCcam and OScam in a mixed network — do not forget that OScam requires an explicit section[cccam] in oscam.conf to support CCcam clients. Without it, clients with cccam lines simply will not be able to connect, although accounts in oscam.user will exist.