CCcam lines: configuration, line format and troubleshooting

CCcam lines are the foundation of any card sharing based on the CCcam protocol. It may seem like just one line with five fields, but its incorrect syntax or invalid parameters can kill half of the connections even before the first ECM request. Here I will explain everything in order: format, config, diagnostics, and transfer to OScam.

What is a CCcam line and what does it consist of

A C-line in the CCcam protocol looks like this:

C: hostname port username password no { 0:0:2 }

Each field here carries a specific load. Missing a space, adding an extra character, or mixing up the order will cause the server to simply not recognize the line.

Anatomy of a C-line: hostname, port, username, password

hostname — the domain name or IP address of the server. A domain is preferable: if the IP changes with the provider, the line will remain functional. Example:share.example.net or91.230.11.45.

port — the TCP port on which the CCcam daemon listens. The standard is 12000, but the server can accept connections on any other port. Important: the port in the client's C-line must exactly match what is specified by theSERVER LISTEN PORT directive on the server.

username andpassword — the credentials that the server checks against the F-line or user database. Case matters:User1 anduser1 — different logins.

The fieldno after the password is a flag for audio/video restrictions (usuallyno or a number). The block{ 0:0:2 } — parameters for the re-sharer, more about them in the FAQ.

How C-line differs from N-line and F-line

C-line — the client line of the CCcam protocol. It is written on the receiver or client server and indicates where to connect.

N-line — the line of the newcamd protocol. The format is different:N: host port user pass deskey { caid }. Ports — range 10000–15000 by default. Newcamd and CCcam are not directly compatible, but OScam can handle both.

F-line — server line for granting access to other CCcam clients. It is specified on the server in CCcam.cfg and determines who is allowed:F: username password 1 0 0 { 0:0:2 }.

Where the line is specified: CCcam.cfg and its location

On most Enigma2 images (OpenATV, OpenPLi, VTi), the config is located at/etc/CCcam.cfg. On some builds for older Dreambox boxes, it can be found at/var/etc/CCcam.cfg. There are images where the binary first looks for the config in/etc/, and if it doesn't find it — it crashes with an error without any hints in the log.

After updating the Enigma2 image, the path sometimes changes, and the old config is simply ignored — the box starts without errors, but also without sharing. The first thing I check in such a situation:find / -name CCcam.cfg 2>/dev/null.

Configuring CCcam.cfg: ports, protocols, and parameters

The working minimum of the config on the server side looks something like this:

SERVER LISTEN PORT : 12000

The config is read line by line, comments start with#. Directives are case-insensitive, but spaces around the colon are mandatory in this format.

Standard port 12000 and binding SERVER LISTEN PORT

12000 — de facto standard for CCcam, but nothing prevents using any unoccupied port above 1024. If several instances of CCcam are running on one machine (for example, for different packages), each must listen on its own port.

On the client side, the port in the C-line and the portSERVER LISTEN PORT on the server — is the same number. It sounds obvious, but this discrepancy is what I see most often when diagnosing other configs.

CCcam parameters: CWS NODEID, FRIEND, DISABLE EMM

CWS NODEID — unique identifier of the node in the format of 8 hex bytes. Two clients with the same NODEID on one server create a conflict: the second connection drops the first. If the line works on one receiver but does not connect on the second — this is one of the reasons.

DISABLE EMM : yes — disables EMM writing to the smart card. For clean resharing, this is normal: EMM will not pass correctly through several hops anyway, but the load on the card is less.

FRIEND — specifies trusted nodes for exchange without additional authorization. Used when building a sharing tree between several servers.

The parameterMAXLECMS limits the number of simultaneous ECM requests. If it is set rigidly, and the client has many active tuners — some requests are simply dropped.

The difference between CCcam, newcamd protocols (ports 10000–15000) and MGcamd

CCcam and newcamd are different protocols with different handshakes and packet formats. CCcam is by default on port 12000, newcamd — usually 10000–15000 (each port for a separate CAID or provider).

MGcamd — a client that can work with a newcamd server via N-lines. It is not possible to directly connect MGcamd to a CCcam server without an intermediary like OScam or a similar proxy.

Protocol version conflict between the CCcam server and client is a separate pain. A client on version 2.2.x tries to connect to a server 2.3.x, the handshake fails, and the connection drops instantly without a clear error in the log. OScam resolves this through the parametercccam version.

Restarting the daemon and checking the logs

On Enigma2, the most reliable way to restart CCcam:

killall -9 CCcam&

An alternative via init:init 4&& sleep 3&& init 3 — restarts all services, including CCcam, if it is listed in the autostart.

Logs can be viewed via telnet on port 16001 (web interface) or directly in the file. In some builds, CCcam writes to/tmp/CCcam.log, in others — only to stdout. Running with debug:CCcam -d 3 provides detailed output for each ECM request.

Diagnostics: why CCcam line does not connect

If cccam lines do not come up — do not panic and do not change everything at once. There is a clear sequence of checks that covers 95% of cases.

Statuses in the web interface (port 16001): ON, OFF, CONNECTED

The CCcam web interface is available athttp://ip-box:16001/. The username and password are set in the config with the directiveWEBINFO LISTEN PORT : 16001 username password.

StatusCONNECTED means only that the TCP connection is established. The card may not return the required CAID — and the channels will not open.OFF — there is no connection at all, check the network and port.ON — the service is running, but not yet connected.

The web interface also shows the number of active ECM requests, the list of connected clients, and the current uphops for each source.

Checking availability via telnet and ping

telnet hostname 12000

If the port is closed — you will seeConnection refused or a timeout. This means that either CCcam on the server is not running, or the port is blocked by a firewall, or the server provider is using CGNAT and incoming TCP connections simply do not reach.

CGNAT — a special problem. A server behind the provider's NAT physically cannot accept incoming connections without explicit port forwarding at the provider level. No port forwarding on the router will help here. The only solution is a VPS with a public IP or changing the provider.

Ping checks only IP accessibility, but not the port. Ping may be successful while the port is closed — this is normal and does not mean that the server is unavailable.

Authorization errors and incorrect username/password

If the port is open but the connection drops immediately — the problem is likely with authorization. Check: case sensitivity of the login and password, extra spaces in the config, matching username in the client's C-line with the F-line on the server.

Another scenario: the user is created on the server, the F-line is configured, but the connection limit is exhausted. The parameterMAXDISTANCE or the limit on the number of clients per account — and the new connection is simply not accepted.

High ECM time or freeze: causes and checking hops/uphops

Normal ECM time for hop1 (local card) is 100–400 ms. Values above 800 ms cause noticeable freezes. Above 1500 ms — the picture will stutter constantly.

High ECM time with low hop (1–2) — a sign of an overloaded card on the source side. By the way, the card may be formally hop1, but freeze due to the resharing on the source side being overloaded: 50+ clients on one card create a queue of ECM requests, and the response time increases.

Channels with BISS encryption or non-standard CAID (for example, some regional packages) will not open, even if the main subscription works. This is not a connection error — these CAIDs are simply not included in the source subscription.

Transition to OScam: equivalent of CCcam line

OScam has long been the preferred choice for those who want stable uptime and normal logging. Transferring cccam lines to OScam format is not difficult, but you need to know the structure of the configs.

Reader line in oscam.server for cccam protocol

C-lineC: share.example.net 12000 user1 pass123 no { 0:0:2 } in OScam looks like this:

[reader]

Config file:/etc/oscam/oscam.server. Each reader is a separate block. You can add as many blocks as you want for different lines.

Configuring oscam.user and reader groups

In/etc/oscam/oscam.user users who connect to the OScam server are specified:

[account]

The parametergroup links the user to the reader block: a client from group 1 will use the reader withgroup = 1. This is convenient when there are multiple sources with different packages.

Parameters cccam.reshare and cccam.version

cccversion in the reader block — this is the version of the CCcam protocol that OScam will present to the server. If the server requires a specific version (for example, 2.3.0), and you connect with 2.2.1 — the connection drops during handshake. Ask your provider or try 2.3.0 and 2.3.2 — these are the most common values in 2026.

cccreshare in/etc/oscam/oscam.conf controls whether OScam will reshare the received CW to other clients. By default, it is disabled, which is correct for a pure client.

Why OScam is more stable for EMM and long uptime

CCcam daemon during long operation (2–4 weeks) sometimes starts leaking memory or losing connections without self-recovery. OScam reconnects automatically, can failover between multiple readers, and writes a detailed log with timestamps.

The OScam web interface is by default on port 8888: it shows the status of each reader, ECM time for each CAID, and request history. This is incomparably more informative than the CCcam web interface on 16001.

EMM in OScam works correctly even through several hops with the right configuration — this is important for cards with periodic key updates.

How to choose a line provider: criteria without advertising

The cccam lines market is full of offers with the same promises of "99.9% uptime" and "HD quality". Reality is verified by three parameters.

Stability of uptime and number of hops

Hop1 — local card on the provider's server. Hop2 — the provider takes from someone else. Hop3 and above — resale of resale. Each extra hop adds delay and a point of failure.

Normal ECM time for hop1 — up to 400 ms, for hop2 — up to 700 ms. If the provider cannot name the hop level of their cards — it is likely hop3+, and you shouldn't expect stability.

Check uptime not by words, but by OScam logs a week after connection. Real outages and their frequency will tell you more than any advertisement.

Local cards vs. reshares

A local card (physical smart card in a reader on the provider's server) provides predictable ECM time and independence from others' problems. A reshare depends on the upstream: if the upstream is down — everyone below is down too.

Signs of a reshare: high uphops (3+), unstable ECM time with spikes, simultaneous outages for all clients of the provider. This does not happen with a local card — each client receives an independent response.

Trial period and adequacy of ECM time

An adequate provider gives a test line for 24–48 hours. During this time, check not only the fact of channel opening but also the ECM time in OScam under load (several simultaneous requests), the presence of necessary CAIDs, and behavior when switching channels.

If they don't provide a test — it's a red flag. Either the provider knows that the quality won't withstand scrutiny, or it's automated resale without real support.