CCcam line: format, configuration of C-line and F-line 2026

If you received a line likeC: somehost.example.com 12000 user123 pass456 and don't understand what to do with it — you are in the right place.CCcam line is literally one text line that describes one network connection. Where to insert it, how to read each field, why it sometimes doesn't work even with the correct syntax — we will discuss all this in order.

What is CCcam line and why is it needed

Definition of CCcam line in simple words

CCcam line is one configuration line in the CCcam.cfg file that defines one network connection. Either outgoing (you are the client connecting to someone else's server) or incoming (you are the server describing an account for a client who will connect to you).

The CCcam protocol operates over TCP. The default port is 12000, but in practice, any free port in the range of 10000–30000 is used. One cccam line = one connection = one peer in the sharing network.

The role of line in the CCcam protocol

When the CCcam daemon starts, it reads CCcam.cfg line by line. Each line starting withC: is perceived as a command: "establish a TCP connection with this host, authenticate, receive CW (Control Words) for decoding ECM packets." LinesF: are accounts for incoming clients that will connect to your CCcam server.

Without at least one valid cccam line with working server data, decoding paid channels will not work — the daemon simply does not know where to connect.

How line differs from newcamd and mgcamd lines

NewCamd line starts withN: and uses a DES key instead of a plain-text password. MGcamd works through a separate filenewcamd.list with a similar format. CCcam line is simpler: plain-text login/password, no encryption keys in the config, the session is encrypted at the protocol level.

This means that cccam line is easier to read and edit, but also easier to accidentally mess up — especially if the password contains special characters.

C-line format: breakdown by fields

Syntax: C: hostname port username password

The full syntax of C-line looks like this:

C:<hostname> <port> <username> <password> [no|yes] [{node-id}] [no|yes]

Let's break down each field:

• hostname — DNS name or IP address of the server. Domain is preferable to IP if the server is behind DynDNS.
• port — TCP port. Most often 12000, but it can be any. It must matchLISTEN PORT on the server.
• username — the login provided by the server owner. Case-sensitive.
• password — the password. Also case-sensitive, spaces are not allowed.

The lineis case-sensitive.User123 anduser123 — different logins. And no tabs — only spaces between fields.

Additional parameters (no/yes, share hops, em)

The fifth field — permission to forward your cards to the server:

• no — do not share your local cards with this server (default value for purely client connection)
• yes — share your cards, forming a mutual exchange

The sixth field{0:0:1} — is the client’s node ID in the CCcam network. Used to prevent sharing loops. Generated automatically on the first launch and written to the fileCCcam.nodeID. No need to change it manually — CCcam will insert its ID upon connection.

Example of a valid C-line and an example with an error

Valid line:

C: server.example-host.tld 12000 user123 pass456 no

Line with an error — tab instead of space between fields:

C:	server.example-host.tld	12000	user123	pass456

CCcam will respond to this with "invalid line" in the log. Another classic mistake — an empty line afterC:, or adding a comment at the end of the line with# (not all forks support this).

For an IPv6 address, the syntax requires square brackets:

C: [2001:db8::1] 12000 user123 pass456 no

F-line format: creating an account for the client

Syntax: F: username password uphops downhops

F-line is declared in your CCcam.cfg if you want other clients to connect toyour CCcam server. Syntax:

F:<username> <password> <uphops> <downhops> [{node-id}]

Example:

F: client01 secretpass 1 2

This creates an accountclient01 with the passwordsecretpass, which is allowed to connect to your server.

The values of uphops and downhops

uphops — how many hops your client can forward your cards further. A value of1 means: the client can use your cards but cannot share them with their clients. A value of0 = cards are not forwarded at all. A too high value of uphops creates long chains — the ECM delay increases, stability decreases.

downhops — how many hops you are willing to accept from the client. If the client has their own cards and wants to share them with you, downhops=2 means that you will accept cards that have passed a maximum of 2 servers.

Standard practice: uphops=1, downhops=2. This is a balance between functionality and performance.

How to limit the number of connections from one account

Standard CCcam 2.3.x does not have a built-in connection limit parameter in the F-line syntax. Limiting is implemented at the firewall level or through third-party CCcam forks with extended syntax. In practice, most servers limit simultaneous connections through iptables conntrack or fail2ban scripts.

Where to insert the line: location of CCcam.cfg

Path to CCcam.cfg on Enigma2 (OpenATV/OpenPLi)

On most Enigma2 images, the config is located here:

• OpenATV, OpenPLi:/etc/CCcam.cfg
• Some older images:/var/etc/CCcam.cfg

If the file is missing — create it manually. After editing, restart the daemon through the SoftCam Manager plugin (not through a full reboot of the receiver). SoftCam Manager is in the plugins menu on OpenATV/OpenPLi — there are Stop/Start buttons for each emulator.

Path to the config on Linux x86 / Raspberry Pi

On Linux x86, the path depends on how CCcam is installed:

• Standard installation:/usr/local/etc/CCcam.cfg
• If you are running the binary from an arbitrary folder — the config is searched next to the binary
• OpenWRT with CCcam-mod for MIPS:/etc/CCcam.cfg

Restarting the daemon on Linux:

killall CCcam&& /usr/local/bin/CCcam -d

Flag-d launches in daemon mode with logging to/tmp/CCcam.log.

Line breaks via FTP/SCP and permissions

It's convenient to edit the config via WinSCP (Windows) ornano directly on the receiver via SSH. After saving, check the permissions:

chmod 600 /etc/CCcam.cfg
chown root:root /etc/CCcam.cfg

On some Enigma2 images, the CCcam daemon does not run as root, so permissions 644 are preferable. Important: a file with permissions 777 on some images of CCcam refuses to read at all — this is not a bug, it is intentional protection against unauthorized changes to the config.

When editing via FTP — make sure the client saves the file with Unix line endings (LF), not Windows (CRLF). Some versions of CCcam do not parse lines with .

Checking connection status and debugging

CCcam web interface on port 16001

CCcam raises a built-in HTTP interface on port 16001. For it to work, there must be a line in CCcam.cfg:

WEBINFO LISTEN PORT: 16001

After that, open in your browserhttp://<IP_receiver>:16001 and see three sections: Connections (active C-lines and their status), Servers (servers to which connected), Shares (cards that are available).

StatusCONNECTED means that the TCP connection is established and authorization has passed. StatusCONNECTING — connection not established, CCcam is trying again. If the line hangs in CONNECTING for more than 2-3 minutes — the problem is either in the network or in the credentials.

Reading the log: ECM request, CW received, timeout

Log/tmp/CCcam.log when started with-d contains everything that happens. Lines to look for:

CCcam: server server.example-host.tld user123 (cccam 2.3.0) connected

— connection established, the server protocol version is visible next to it.

ECM request CAID:0604 SID:1234 PMT:100

— the receiver requested a key for the channel with CAID 0604.

CW received from server.example-host.tld in 124ms

— key received, delay 124 milliseconds. Normal up to 500ms.

ECM timeout after 3000ms

— the server did not respond in 3 seconds. The channel will freeze or show artifacts.

Telnet commands to check server reachability

The fastest way to check if the port is open at all:

telnet server.example-host.tld 12000

If the connection is established and then immediately closed — the port is open, but CCcam rejected the connection (invalid credentials or IP not allowed). IfConnection refused — the port is closed or the firewall. If timeout — network issue or IP is blocked.

Alternative without telnet:

nc -zv server.example-host.tld 12000

Typical errors in CCcam line and how to fix them

Invalid port or DNS does not resolve

Typo in the port — status forever in CONNECTING. Check the port again via telnet. If DNS does not resolve (especially relevant for servers behind CGNAT, where the IP changes every few hours), try to get the IP via nslookup:

nslookup server.example-host.tld

And temporarily substitute the IP instead of DNS in the C-line for testing. If it works with the IP — the problem is with your provider's DNS resolver. Solution: specify in/etc/resolv.conf an external DNS, for example 8.8.8.8.

For servers with frequently changing IPs, use a DynDNS name in the hostname field — this is exactly what the hostname field is for.

Username/password contains special characters

If the password contains$,#,!,@ or space — there may be issues. CCcam parses the line by spaces, and a space in the password will completely break the syntax. The character# is interpreted as the start of a comment in some forks.

If the password was issued with problematic characters — ask to recreate it without them. Or check the log: if after the line with your C-line it says "invalid line N" — the issue is definitely with the syntax.

A special case: empty password (only space after username). The original CCcam 2.3.2 accepts such a line, but most forks do not.

Protocol version conflict CCcam (2.0.11 vs 2.3.x)

CCcam 2.0.11 — an old version with a different handshake. If your client 2.0.11 connects to a server on 2.3.0 or 2.3.2, the connection may be established (CONNECTED in status), but ECM responses will not come or will be incorrect.

In the log, this looks like a series of ECM timeouts without a single CW received. The solution is to update the CCcam binary on the receiver. For Enigma2, take the binary for your architecture (ARM, MIPS) with version ≥2.3.0.

The server does not provide cards: check SID and hops

Connection CONNECTED, but channels are not opening. This means the problem is not with the network, but that the server is not sharing the required cards. Options:

• uphops=0 in the F-line on the server — the server does not allow your account to receive cards. The server owner needs to fix the F-line.
• SID filter — the server is configured to provide only certain channels. In the web interface at 16001 in the Shares tab, check which CAID/SID are available.
• Expired account — the log may show "account expired" or the connection is established and immediately drops.
• No required card on the server — the server physically does not have a card with the required CAID.

Another nuance: if you have multiple C-lines for the same host with different ports — each connection is counted separately by the server. This is permissible, but some servers consider it an attempt to bypass the connection limit.

CCcam line in OScam: compatibility and conversion

Section [reader] in oscam.server instead of C-line

OScam does not read CCcam.cfg and does not understand the syntaxC:/F:. But it can work with the CCcam protocol as a client. The config for OScam is written in/etc/oscam/oscam.server.

Here’s how one cccam line turns into an OScam-reader:

Was (CCcam):

C: server.example-host.tld 12000 user123 pass456 no

Became (OScam, file/etc/oscam/oscam.server):

[reader]
label                = server1
protocol             = cccam
device               = server.example-host.tld,12000
user                 = user123
password             = pass456
group                = 1
cccversion           = 2.3.2
cccmaxhops           = 10
ccckeepalive         = 1

Parameters protocol = cccam, device, user, password

Parameterprotocol = cccam tells OScam to use the CCcam protocol for this reader.device — this is host and port separated by a comma (without space).user andpassword — as in the original C-line.

Parametercccversion must match the server version for stability — this directly affects the handshake. If you do not know the server version, start with2.3.2. If there are problems — try2.2.1 or2.0.11.

ccckeepalive = 1 enables keepalive packets — prevents disconnection during long idle times.

When is it better to migrate from CCcam to OScam

OScam wins if you have a complex configuration: a local smart card plus several remote servers simultaneously, SID filters, different CAIDs for different receivers. The flexibility of settings in oscam.server is incomparably higher than the syntax of C:/F:.

Also, OScam can simultaneously maintain connections via newcamd and cccam with one configuration. This is convenient when transitioning from one protocol to another without downtime.

But if you have a simple task — one server, one receiver — CCcam with a couple of lines in cfg is easier and faster to set up.

One practical detail: a configuration where the receiver is simultaneously a client (C-line) and a server (F-line) works correctly in CCcam. The order of declaration in CCcam.cfg affects initialization — F-line is recommended to be declared before C-line so that the server part is ready before establishing outgoing connections.