CCcam.cfg: configuration of C-line and connection to the server

If you have already installed CCcam and are trying to figure out how to set up the connectioncccam to the server — this page is for you. There will be no fluff about "what is card sharing" — only the format of the line, real paths to the config, check commands, and step-by-step diagnostics when something goes wrong.

The CCcam.cfg file is read line by line. One extra tab, Windows line break, or space in an unexpected place — and the line silently fails to load. Let's break everything down by levels.

What the connection line in CCcam means and how the C-line format is read

C-line is the line that tells CCcam: "connect to this server with these credentials." It looks like this:

C: example.server.com 12000 myusername mypassword no no

Six fields separated by single spaces. No tabs, no double spaces between fields.

Format breakdown: C: host port username password

Let's break it down from left to right:

• C: — literally "C colon space". The space after the colon is mandatory.
• host — hostname or IPv4 address of the server. Domain is preferable for dynamic IP.
• port — port. The standard CCcam port is 12000, but the server can listen on any; check the provider's data.
• username — login. Case-sensitive.User1 anduser1 — different logins.
• password — password. Also case-sensitive.

Example with comment:

# main server

Additional C-line parameters (wantemu, hops, distance)

The last two fields after the password — boolean flags:

• wantemu (first flag) — whether to request emulated cards from the server. Usuallyno, if you only need real cards.
• keepalive/wantemus (second flag) — interpreted slightly differently in various versions of CCcam; set what the server requires, usuallyno.

After the colon following the password, you can addHOPS andDISTANCE, but this is already advanced filtering. The basic line works perfectly without them.

How C-line differs from N-line (newcamd) and F-line

Confusion often occurs. Three types of lines — three protocols:

• C-line — the CCcam protocol. This is what you receive from the server for connection.
• N-line — the Newcamd protocol. It starts withN:, the format is different, used in MGcamd and OScam. It does not work with a CCcam server.
• F-line — this is a line for clients who connectto you. If you are sharing a line yourself — you write F-line in your config.

If you received a line starting withN:, and you are working with CCcam — this is not your format. Either convert it through OScam, or request a C-line from the provider.

Where to write the C-line: paths to CCcam.cfg on different systems

This is where most often stumble. The config can be located in two places depending on the image and build settings.

Paths on Enigma2 (/etc/CCcam.cfg, /var/etc/CCcam.cfg)

On most Enigma2 images (OpenATV, OpenPLi, OpenVision) CCcam reads the config from/var/etc/CCcam.cfg. This is where you should write it. On some older builds or custom launch scripts, the path is —/etc/CCcam.cfg.

To check which one your build is using, simply:

ps aux | grep CCcam

In the launch line, the path to the config will be explicitly indicated through a flag or as the first argument.

File formatting rules:

• C: lines — from the very beginning of the line, without indentation
• Comments — through# at the beginning of the line
• Encoding — UTF-8 without BOM, Unix line endings (LF, not CRLF)

Location on a Linux server and DreamOS

On a bare Linux (Debian, Ubuntu) CCcam usually runs from/usr/local/bin/CCcam, and the config is placed in/etc/CCcam.cfg. On DreamOS (Dreambox with native system) the path is often/etc/CCcam.cfg, but it depends on the firmware version.

If installed via package manager — check the init script:

cat /etc/init.d/CCcam

There will be a hardcoded path to the config.

File permissions and daemon restart after editing

Permissions should allow CCcam to read the file. Usually enough:

chmod 644 /var/etc/CCcam.cfg

After each config edit — restart. The most straightforward method that always works:

killall -9 CCcam&

On Enigma2 it's more convenient through the plugins menu or the command:

/etc/init.d/CCcam restart

CCcam cannot re-read the config without a restart. SIGHUP won't help — only a full process restart.

Checking connection: ports, protocol, and line status

Configured the config — now you need to make sure the line is up. This is done in two steps: first check the network, then look at the status in the CCcam interface itself.

CCcam web interface (port 16001) and the Servers page

CCcam raises a built-in HTTP server. To enable it, add to CCcam.cfg:

WEBINFO LISTEN PORT : 16001

After restarting, open in the browserhttp://[box-ip]:16001. The "Servers" page shows all C-lines: status, number of cards, hops, time of last response.

On the same page, you can see ECM time — the time to decode one packet. A normal indicator is up to 200-300 ms. Above 500 ms — it's already a problem.

Checking port availability via telnet and nc

Before looking for errors in CCcam, make sure the server is responding at the TCP level. Directly from the box or server:

telnet example.server.com 12000

Or via netcat (it's almost everywhere):

nc -vz example.server.com 12000

If the connection cannot be established — the problem is not with CCcam. It's a firewall, incorrect port, or the server is not listening at all. The config has nothing to do with it.

If telnet connects, but CCcam still shows OFFLINE — check the login/password and protocol version.

Reading line status: ONLINE, CONNECTED, number of cards and hops

In the web interface, each C-line will have the status:

• CONNECTED / ONLINE — TCP session exists, authorization passed, cards received
• OFFLINE — connection not established at all
• 0 cards in ONLINE — the transport works, but there are no cards (either the server is empty or there is no match for CAID)

Fieldhops shows how many nodes the card has passed through. Hop 0 or 1 — local card or one forwarding. Hop 2+ — the card has come through a chain, delays and instability increase.

Why C-line does not work: analysis of common errors

Diagnosis should be done layer by layer: first the network, then authorization, then content. If you jump straight to "wrong CAID", you can spend hours rearranging settings and not find a trivial firewall block.

LINE OFFLINE: firewall, NAT, incorrect port

The most common reason — the port does not reach the server. Options:

• Box behind a NAT router, and the server has no port forwarding — this is relevant for incoming connections, but in this case, you are initiating the connection outward, so check if the router is blocking outgoing traffic on non-standard ports
• Incorrect port in C-line — took the port from the example (12000), but the provider issued 15500
• The server's IP has changed — if the server has a dynamic IP, and you specified a numeric address instead of a domain
• The server is completely unavailable — check via telnet from another device on the same network

Special case: if the CCcam server itself is behind NAT and you did not forward port 12000 (or another) outward — clients will physically not reach it, even with an absolutely correct config.

LINE ONLINE, but channels do not open (no required CAID/providers)

This is not a connection error — it is a content mismatch. The line is up, authorization has passed, but the server does not have the required cards for your channels.

What to check:

• CAID of the channel and CAID of the cards on the server — must match. In the web interface on the Servers page, you can see which CAID are available.
• Provider ID — few CAID, a provider is also needed. Some channels require a specific PROVID.
• Hop — a card with hop 2+ may "appear" and "disappear", not having time to respond in the ECM timeout.
• Subscription on the server side has expired — the card exists, but no longer decodes. This is visible by ECM time → timeout.

Freeze and freezes: high ECM time, hops, server overload

Channels open, but the image breaks up every few seconds. This is almost always due to ECM time.

The ECM request must pass in less time than the channel's crypto period (usually 10 seconds, but on some streams 5 seconds). If the ECM time is consistently above 500-800 ms, and especially jumps to 2-3 seconds — freezes are guaranteed.

Reasons for high ECM time:

• Many hops — each forwarding adds delay
• Overloaded server — too many clients on one card
• Network losses between you and the server — check with ping
• Geographically distant server — 200+ ms ping already creates problems

Syntax errors in the config and invisible characters

This kills more time than one would like to admit. CCcam is extremely sensitive to file formatting.

What breaks C-line unnoticed:

• Windows line endings (CRLF) — if you edited the config in Notepad on Windows and uploaded it via FTP in ASCII mode, there is \r at the end of each line. CCcam reads the login as "myuser\r" — it does not match the server's "myuser".
• BOM in UTF-8 — some editors add three invisible bytes at the beginning of the file. The first line of the config does not start with "C:", but with "BOM + C:", and CCcam does not recognize it.
• Tab instead of space — looks the same, parsed differently.
• Extra space before C: — the line should start with "C:", not with " C:".

Quick check of the file encoding on the box:

file /var/etc/CCcam.cfg

cat -A will show^M at the end of lines with CRLF and other invisible characters. Convert to Unix format:

sed -i 's/\r//' /var/etc/CCcam.cfg

If DEBUG logging is enabled (lineDEBUG TIMEOUT : 30 in the config), you can view the logs like this:

tail -f /tmp/cccam.log

There you will see whether the C-line is being parsed at all and at what stage the connection is breaking.

How to choose a server for connection: technical criteria

When setting upcccam to the server, the quality of this server determines everything. Even an ideal config won't help if the server itself is unreliable.

Stability of uptime and low ECM time

The first thing to look at is uptime. A good server operates 99%+ of the time without crashes and reboots. How to check this before purchasing — ask for a test line for 24-48 hours and see if the connection drops at night.

ECM time is not just a number in the web interface. It is a real indicator of the load and quality of the server. Stable ECM 50-150 ms — good. Jumping from 100 to 800 ms — bad, even if the average is normal.

Local cards (local) vs hops (hops)

The most technical criterion that few explain. Hop 0 — the card is physically inserted into the server you are connecting to. Hop 1 — the card is in a neighboring server that is connected to yours. Hop 2+ — a chain of two or more nodes.

Each additional hop is a delay plus a potential point of failure. Cards with hop 0-1 are stable. Cards with hop 2+ are always a lottery: sometimes yes, sometimes no, ECM time fluctuates.

When setting upcccam to a server with hop 2+ you depend not only on the quality of the server itself but also on the entire chain to the original card. If any link in the chain is overloaded or fails — the channel will freeze.

Support for necessary CAID/providers for your satellite

Before paying — make sure that the server actually covers the channels you need. A list of supported CAID and provider-ID for a specific satellite is required.

What to check:

• CAID of the encryption system (Viaccess, Nagravision, Irdeto, Conax — each has its own CAID)
• Provider ID — one CAID can cover different packages from different providers
• Satellite position — cards for 13°E will not open channels from 19.2°E of another system

This seems obvious, but good servers immediately provide a list of supported packages. If such information is not available — ask explicitly.