CCcam lines: setting up C-line and F-line on the server

If you have already installed CCcam or OScam on your Enigma2 receiver and are now faced with the config asking "what should I write in these lines" — this article is for you. CCcam lines are not just lines of text; they are a precise syntax with specific fields, and an error in one character will give you a "no card" status instead of a normal picture. Let's break down the format, paths to configs, port opening, and diagnostics through logs.

What are CCcam lines and how is the protocol structured

CCcam is a card sharing protocol that works over TCP, not UDP. The client (receiver) sends an ECM request to the server via port 12000/TCP by default. The server receives this request, decrypts the control word (CW) on the physical smart card, and returns a DCW response to the client. The client uses this control word to decrypt the video stream.

All of this happens approximately every 10 seconds — that’s how long one control word lasts. If the server does not respond in time, you see a black screen or artifacts. Therefore, the speed and stability of the connection are critical here.

C-line (client line) — how the client connects to the server

C-line is a one-way client connection. Your receiver connects to a remote server, authenticates with a username and password, and gains access to the cards that this server shares. There is no reverse data flow from your side — you are just a consumer.

F-line (friend line) — two-way exchange between peers

F-line is a different story. Here, two servers agree to exchange: each one lists the other as a "friend," and both can use each other's cards. The uphops and downhops parameters control how deeply the reshare spreads through the chain. If uphops=1, your partner can only use your direct cards, not your clients' cards.

N-line and newcamd protocol for comparison

N-line is analogous to C-line, but for the Newcamd protocol. The syntax is different:N: host port user pass DES_key. Newcamd operates on port 28910/TCP by default and uses DES encryption. OScam supports both protocols, while CCcam only supports its own. They cannot be mixed: a client on CCcam will not communicate with a server on pure Newcamd without emulation.

What is actually transmitted: ECM, CW, and DCW response

ECM (Entitlement Control Message) is an encrypted packet from the DVB stream containing the control word. The server takes this packet, feeds it to the physical card, and the card returns the decrypted CW. This CW is the DCW response that flies back to the client. The entire chain must fit within ~300–400 ms, otherwise there will be freezes.

C-line and F-line format: precise syntax

This is where most articles fall short — they provide a ready-made line without explaining each field. Let's go through the syntax in detail.

C-line structure: C: host port username password

The basic C-line looks like this:

C: my.server.net 12000 myuser mypassword

Four fields: host (IP or domain), TCP port, username, password. Everything is separated by spaces. The case in the username and password matters —MyUser andmyuser are different accounts. If the server is behind dynamic DNS, the host field may contain something likeabc123.ddns.net.

Port 12000 is standard, but the server can use any other. If the provider gave you a line with port 15000 or 17000 — that’s fine, just non-standard. The main thing is that the client and server ports match.

Additional parameters: { N } and nodeid encryption

CCcam supports extended syntax with a parameter block in curly braces after the main line:

C: my.server.net 12000 myuser mypassword { nodeid=AA:BB:CC:DD:EE:FF:00:01 }

Node ID is a unique identifier for a node in the CCcam network. Some servers require it for client identification. In normal situations, this field is optional. The CCcam protocol version is automatically transmitted by the client during handshake, but in OScam it can be explicitly set — more on that below.

F-line structure: F: username password uphops downhops

F-line for two-way exchange:

F: friend_user friend_pass 1 0

Here are four parameters: your partner's login and password, thenuphops anddownhops.uphops=1 means that the partner has access to cards at a depth of 1 hop — only direct cards, not client cards.downhops=0 — you do not accept reshare from the partner (or only accept local ones, depending on the version). A value of 0 in downhops often means "no restrictions" — read the documentation for your version of CCcam.

Where to write the lines: CCcam.cfg and paths on Enigma2

On standard Enigma2 images (OpenATV, OpenPLi, OpenVision), the config is located in/etc/CCcam.cfg. In some builds, especially older ones, the path may be/var/etc/CCcam.cfg or/usr/keys/CCcam.cfg. Finding the actual path is simple:

find / -name "CCcam.cfg" 2>/dev/null

In OScam, cccam lines are written differently — through the block[reader] in the file/etc/oscam/oscam.server:

[reader]

And accounts for incoming C-line clients — in/etc/oscam/oscam.user. This separation (reader separately, users separately) confuses many.

Server setup: ports, firewall, and oscam.server

Suppose you are setting up your server for sharing — proper configuration is needed both from the OS side and from the OScam side.

Opening port 12000/TCP and forwarding on the router

First, make sure that the service is actually listening on the required port:

netstat -tlnp | grep 12000

Or if netstat is not installed:

ss -tlnp | grep 12000

If the line is not there — CCcam/OScam is not running or is listening on another port. If the line is there, add the iptables rule:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT

On the router, port forwarding is needed: external TCP 12000 → internal IP of the server, port 12000. The problem is that many providers now use CGNAT — and here port forwarding is physically impossible without contacting the provider or using a VPN tunnel. Iftelnet your.external.ip 12000 does not connect, but everything works inside the local network — it is most likely CGNAT.

Binding to a physical card through oscam.server and oscam.user

Inoscam.server describes a physical reader with a smart card:

[reader]

And inoscam.user — an account for your CCcam client:

[account]

The parametercccreshare in oscam.user controls whether this client can reshare cards further. 0 — not allowed, 1 — allowed to the depth specified bycccmaxhops.

The parameters cccam version and cccmaxhops

The CCcam protocol version is more important than it seems. If the client claims version 2.3.x, and the server expects 2.1.x, the handshake may fail or work incorrectly. In OScam, you specify the version explicitly throughcccversion = 2.3.0 in the reader block. In native CCcam, the version is embedded in the binary.

cccmaxhops — maximum depth of reshare. A value of 1 means only direct server cards, 2 — server cards and its readers, and so on. A high value increases delays.

Restarting the daemon and checking logs

On Enigma2:

/etc/init.d/softcam restart

Or directly via killall and restart:

killall CCcam&

For OScam:

/etc/init.d/oscam restart

After the restart, immediately check the logs — the first seconds are the most informative.

Diagnostics: why the line is not working or drops

This is the most useful part that is usually skipped. Most problems with cccam lines can be solved in 5 minutes if you know where to look.

Line status: connected, no card, server down

In native CCcam, open a browser:http://ip_receiver:16001 — this is the status web interface. There you can see all readers and their status. Three basic statuses:

• connected — connection established, cards available
• no card available — connection exists, but there are no cards on the server or they are not shared for your account
• server down / not connected — connection is not established at all

“No card available” is often confused with a connection problem, but these are different things. The session is open, authorization has passed, but the required card is absent on the server — or you do not have rights to it.

Reading logs CCcam and oscam.log

Live logs of OScam:

tail -f /var/log/oscam/oscam.log

Or:

tail -f /tmp/oscam.log

The path depends on the config — see the parameterlogfile inoscam.conf. In the logs, look for lines withECM — there you can see the processing time of the request (in milliseconds) and the result:found ornot found.

For native CCcam, logs are usually in/tmp/CCcam.log. Look for entries like[NETWORK] — there you can see connections and disconnections.

Check via web interface (port 16001 / OScam webif)

OScam webif is by default on port 8888 (http://ip:8888), unless overridden inoscam.conf in the section[webif]. The "Readers" section shows each reader with ECM count, last response time, and status. If you see ECM time 800+ ms — the line will freeze.

CCcam webif on 16001 is less informative, but gives a quick overview of the number of connections and available cards by CAID.

Typical errors: wrong password, ECM timeout, freeze of the picture

Wrong password in the log — check the case of the login and password. Literally character by character. Often the problem is a copied space at the end of the line.

ECM timeout — the server did not respond in the allotted time. Reasons: high ping to the server, overloaded server, unstable physical card on that side. Try increasing the timeout in the OScam config (ecmwhitelist andecmtime in oscam.conf).

The picture goes for the first few seconds, then a black screen — a classic case of overload or reboot of the source card. If the server shares a card that has gone into reboot or exceeded the limit of simultaneous ECM requests, the first CW worked (it was cached), but the next one did not come.

The line operates on one CAID but does not open channels from another provider — mismatch of provider ID. In OScam, you can set a filter by CAID and provider in oscam.user: parametersident andcaid. If the required provider is not specified, requests are simply ignored.

The line drops every few minutes — almost always this is a dynamic IP on your side when linking the account to the IP on the server. Either negotiate to disable IP-lock, or use DDNS and ask to allow connection via the domain.

How to choose a source of lines: criteria without binding to names

I won't name specific services — it's pointless in a niche where everything changes every few months. It's better to discuss how to evaluate any source of cccam lines independently.

Stability: uptime and ECM response time

Normal ECM time is up to 300–400 ms. Anything above 600–700 ms will cause periodic freezes, especially on channels with short control word periods. In OScam webif, check the "ECMtime" column for each reader in real time.

Checking uptime is more difficult — usually visible only after several days of observation. A good sign if the source provides availability statistics through its interface. A bad sign — if the server goes down every Sunday evening.

Number of hops and card locality

Hop 1 — the card is directly on the server you are connecting to. This is ideal. Hop 2 — the card is on a neighboring server. Each additional hop adds latency and a point of failure. At hop 3 and above, freezes are almost guaranteed on channels with intensive sharing.

In CCcam webif (port 16001), the hop number is visible in the Cards section. In OScam — in the logs with each ECM request.

Support for required CAIDs and providers

CAID is the identifier of the conditional access system. For example, Viaccess — 0x0500, Nagravision — 0x1800, Irdeto — 0x0600. Within one CAID, there can be different providers with different channel packages.

Before taking a line, clarify the exact CAID and provider ID of the package you need. "Supports Viaccess" is not an answer. You need a specific CAID+provider for a specific transponder. Otherwise, you will get a connection without the required channels.

Signs of an unstable source

ECM time jumps from 100 ms to 900 ms — the source card is overloaded or unstable. Periodic "no card" status without an obvious reason — someone on the other end is rebooting the equipment. The picture freezes exactly once every ~10 seconds — the new CW does not arrive in time, a classic of high latency. The line drops when changing channels — the limit of simultaneous ECM requests has been exceeded on the source side.

And one more point: if the source offers cccam lines with reshare depth of 5+ hops, it's garbage. Such a chain is unviable for normal viewing.