CCcam reshare: server setup and C-line in 2026

If you already have a working CCcam server and understand what a C-line is, this article is for you. CCcam reshare: setting up card sharing between peers is a topic that most guides either avoid or explain at a level of "just set it to 2 and it will work." It won't. At least, not always. Let's break it down specifically: syntax, parameter priorities, typical loops, and integration with OScam.

What is reshare in CCcam and how does hop work

Reshare in simple terms: sharing the received line

CCcam receives ECM from the upstream peer, decrypts it, and provides DCW to its clients. Reshare is when the server not only provides DCW to the receiver client but allows another CCcam server to take this service and distribute it further to its clients. In other words, reshare.

The scheme looks like this: supplier peer → your server → your client (or another peer). Your server is in the middle of the chain. It received the card and can either keep it for itself or distribute it further, depending on what the upstream peer allowed and what you have configured.

What is hop and how are levels 1, 2, 3 calculated

Hop is the number of intermediate servers between the card source and the end user. Hop 1 means the card came from a local reader or smart card directly. Hop 2 means you received the card from a peer and are distributing it to your clients. Hop 3 means your client is also a CCcam server and is resending further.

The reshare parameter in the line tells the server: "allow the next level to reshare this again." If you setreshare = 1, the card will go one level below you, but it won't go further. The value0 means a complete prohibition on reshare.

The difference between local cards and those reshared from a peer

Local cards (physical smart cards in the reader or EMM) always have hop 1. They can be distributed without restrictions — they are yours. Cards from a peer come with hop 2+. This is where the uphops parameter is important: it shows how many intermediate servers were already before you.

If a peer sent a card withuphops = 1 and without reshare rights — the channel will open for you, but you won't be able to give this card to your sub-peer. This is not a config error — it's a restriction set higher up the chain.

Configuring reshare in CCcam.cfg: C-line, N-line, and F-line

Global parameter in CCcam.cfg

The configuration file is usually located in one of two paths:/var/etc/CCcam.cfg (Enigma2 boxes) or/usr/keys/CCcam.cfg (some distributions). Rarely, but it can be found at/etc/CCcam.cfg. Check the running process with the commandps aux | grep CCcam — it will show the path to the config.

Global reshare parameters look like this:

RESHARE : 2

RESHARE : 2 means that by default all cards are shared with a reshare depth of 2. But this is just the default — line parameters in C-line and F-line take precedence over global ones. This is a key point that is often overlooked.

The reshare parameter in C-line and N-line

C-line is a connection string to someone else's server, meaning you are the client:

C: hostname.example 12000 myuser mypassword no { 0:0:2 }

Parsing the curly braces{ caid:provid:reshare }:0:0:2 means "all CAID, all providers, reshare = 2". This value tells your server with what hop-limit to accept cards from this peer and pass them on.

N-line works similarly, but is used for Newcamd connections. The syntax is slightly different, but the principle is the same — curly braces define reshare for a specific connection.

Setting up sharing via F-line (friend)

F-line is a line where you describe your "friend" or client-server to whom you are sharing cards:

F: frienduser friendpass 1 0 0 { 0:0:2 }

The three numbers after the password: the first is uphops (how many hops to accept from the source), the second is downhops (how many hops down to allow), the third is reshare (whether to allow further sharing). In curly braces is fine-tuning by CAID and provider.

If globally setRESHARE : 2, but in F-line it says{ 0:0:0 } — the card will not go further. The line overrides the global setting. Always.

Where the file physically resides: /var/etc/CCcam.cfg and /usr/keys/

After editing the config, the service needs to be restarted. On Enigma2:

killall -9 CCcam&

Or via init scripts:/etc/init.d/CCcam restart. On some builds, the path to the binary is —/usr/bin/CCcam, on others —/usr/local/bin/CCcam. Check viawhich CCcam.

Reshare limitation: control of hops, providers, and CAID

Limitation by CAID and provider ID in parentheses

The filtering format allows for precise control over the reshare of specific cards. Example: allow reshare only for Viaccess with provider ID 032830 and only to one level:

{ 0500:032830:1 }

For Nagravision 3 (CAID 1830) with a reshare prohibition:

{ 1830:000000:0 }

Multiple entries in parentheses are separated by commas or written on separate lines. If a peer has given you several cards — you can set your own reshare value for each CAID.

Parameters MAXHOPS and RESHARE globally

MAXHOPS : 3 — a hard ceiling. Cards with hop > 3 will not be accepted by the server at all, even if the peer offers them. This is protection against long unstable chains.

RESHARE : 2 — the default depth for all connections where no individual parameter is set. A good value for a typical network: you accept from a peer (hop 2) and share with your clients (hop 3), it does not go further.

Prohibition of reshare for specific cards (no reshare)

Sometimes you need to give a client a specific package but prohibit them from sharing a specific card. For this, in the F-line, you set{ caid:provid:0 }:

F: clientuser clientpass 2 1 0 { 0500:032830:0, 0:0:1 }

Here, for Viaccess 032830, reshare = 0, for everything else, reshare = 1. The client will receive both, but Viaccess 032830 will not be able to share further.

Control of the number of connections and uphops/downhops

DirectiveDOWNHOPS : 2 in the global config limits how many levels down the card goes from your server. Uphops — the limit on the number of hops from the source to you when receiving. These parameters work as additional filters on top of the values in the lines.

Port forwarding, firewall, and connection check

Opening port 12000 (TCP) on the router

CCcam listens on TCP 12000 by default. If the server is behind NAT, port forwarding is needed. On most home routers, this is done in the "Port Forwarding" or "Virtual Servers" section. Forward external TCP 12000 to the internal IP of the server, the same port.

Double NAT (provider + router) is a separate pain. If the provider uses CGNAT, your external IP is gray, and incoming connections simply won't reach you. In this case, either negotiate with the provider for a public IP or use a VPN tunnel (OpenVPN, WireGuard) between peers.

On the server itself, check the firewall. For iptables:

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

Checking via telnet and the CCcam web interface (port 16001)

Quick check of port availability from the outside:

telnet 12000

If the connection is established — the port is open. CCcam also holds an HTTP interface on port 16001. Go to the browser athttp://<ip>:16001 — there you can see all connected clients, servers, active cards, and their hops. This is where you check if reshare is being transmitted: in the "Clients" section, the connected peer should show cards with the corresponding hop value.

Configuration on the OScam side: reader and [account] reshare

If your network has a mixed CCcam ↔ OScam setup — you need to know the equivalents of the parameters. In the file/etc/oscam/oscam.server for the reader connecting to the CCcam server:

[reader]

The parametercccreshare here is analogous to reshare in the C-line CCcam. In the file/etc/oscam/oscam.user for the account to which OScam distributes cards:

[account]

Protocol version negotiation viacccversion is important: if the CCcam server is running on 2.3.x and OScam presents itself as 1.x — reshare may be interpreted differently or not transmitted at all.

Checking the status of peers and active reshare

In the OScam web interface (http://<ip>:8888) see the "Readers" section — it shows the connection status to the CCcam peer and the number of received cards. In the CCcam interface (port 16001), the "Servers" section will show what your server received from each peer and with which hop.

Typical reshare errors and what DOES NOT work

Channels open, but reshare does not go further

This is the most common question. The channel opens — which means the DCW reaches your decoder. But the sub-peer complains that the card is not visible. Reasons in descending order of probability:

• In the F-line for the sub-peer, it is set to{ 0:0:0 } or reshare = 0 explicitly — check the line
• The upstream peer gave the card without reshare rights — uphop came, but reshare = 0 on their side
• GlobalMAXHOPS is too small, and the card with hop 2 is not passed further
• Firewall blocks incoming connection from the sub-peer to port 12000

Check the logs:tail -f /tmp/CCcam.log orcat /tmp/CCcam.log | grep reshare. It will show why the card is not being passed.

Looping and card duplicates in the network

If two CCcam servers added each other in the C-line and both allowed reshare — a loop is formed. Server A receives a card from B and retransmits it back to B. B sees "its" card twice: the original and the retransmitted duplicate with hop+1. This clogs the network, increases the load, and can cause instability.

The solution is simple: if you are connected to a peer as a client (C-line), do not add the same peer in the F-line with reshare > 0. Or use the directiveCARD LOOP PROTECTION : yes in CCcam.cfg — it filters duplicates by card ID.

Too large hop — instability and freezes

Each additional hop is an additional delay in receiving DCW. In practice: hop 1 gives a delay of 50–150 ms, hop 3 — already 300–500 ms and more. For standard CAID (Nagravision, Viaccess) this is still tolerable. But for cards with frequent key changes — every 10–30 seconds — a delay of 400 ms at hop 3–4 guarantees constant freezes.

Keep the chain short. Hop 1–2 is normal. Hop 3 is a borderline state. Hop 4+ — almost always freezes on dynamic channels.

What to avoid when setting up reshare

Do not exceed the reshare that the peer allowed. If their line says reshare = 1 — it means they allow the card to be shared one level below you. If you set reshare = 3 on your side, the retransmitted card beyond the first level will still not go — the limitation works on the source side. But trying to bypass this violates the agreement and, if the peer monitors the hop of their cards, will lead to a ban.

Negative reshare values (for example, -1) are simply ignored by CCcam, treating them as 0. Duplicating the same card from two different peers does not increase stability — the server will use the first responding source, the second will be idle. For real redundancy, proper prioritization is needed throughPRIORITY CAID OVER PROVID or OScam with its load-balancing.

CCcam reshare: setting it up wisely is not only about correct syntax but also understanding agreements with peers and the architecture of the entire network.