CCcam reshare: server setup in 2026 — guide

If you have already set up a CCcam server and exchanged lines with a couple of peers, sooner or later you will run into the issue of card reshare. CCcam reshare: setting up this mechanism is one of the most confusing topics because half of the instructions online show only one parameter, ignoring the other side of the connection. Let's break it down step by step: config syntax, hops, uphops, loop protection, and diagnostics through the web interface.

What is reshare in CCcam and how does it work

Reshare is when your CCcam server receives a card from a peer and reshares it to its own peers. You act as an intermediary in the chain. It sounds simple, but the devil is in the details: who to share with, how deep, and how to avoid creating a loop.

The principle of card reshare between peers

The scheme works like this:source server → your server → your peer. The source gives you a card with certain restrictions. You receive it and — if reshare is allowed — pass it down the chain. Your peer can reshare it even further if you allow it.

Each such transition from node to node is called a hop. The more hops the card has made, the further it is from the source. And the higher the risk of losing time on an ECM request — each additional hop adds delay.

The parameters hops and uphops in simple terms

hops — is how many nodes down the card can go from you. You set this value for your peer. If you wrotereshare 1 — the peer will receive the card and can pass it to one more node down, but no further.

uphops — is a filter for reception. You tell your server: "accept cards only if they came no deeper than N hops from the source." If the card came to you with hop=3, and your uphops=2, the card is cut off. This is where reshare often breaks — when uphops for one of the peers is set too strictly.

The valuereshare = 0 means a complete ban. The peer receives the card for personal use and cannot share it anywhere. This is the safest mode for client connections that do not need reshare.

How reshare differs from direct sharing

In direct sharing, the card goes directly from the reader or server to the peer — one hop. In reshare, the card is already "used": it came from somewhere above, and you are resharing it. The quality of the ECM response may suffer slightly due to accumulated delay in the chain. Therefore, there is practically no point in keeping reshare deeper than 2 levels.

Configuring reshare in CCcam.cfg: C/N and F lines

CCcam reshare: configuration starts with editing the CCcam.cfg file. The structure of the config allows you to set reshare both globally and for each peer separately — and for each CAID/provider in curly braces.

Client line format C: line

Basic syntax of the C line with reshare:

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

Fields in order: host, port (usually 12000 or 13000), login, password, AU activation flag (no/yes), and in curly braces — sharing parameters in the formatcaid:provider:reshare. The value0:0:2 means: allow reshare for all CAIDs and providers with a depth of 2.

If you need to limit reshare for a specific CAID, for example, only for Viaccess (0D05) with zero reshare:

C: hostname 12000 username password no { 0D05:000000:0 }

You can combine several entries in one set of braces with a comma:

C: hostname 12000 user pass no { 0D05:000000:0, 0622:000000:1 }

Here Viaccess is prohibited from resharing, while Irdeto is reshared for 1 hop down.

N line (N: line) — this is the server line that describes what you allow the incoming peer to accept. The syntax is similar, only it comes from the host that accepts the connection:

N: 192.168.1.100 username password { 0:0:1 }

Global parameters at the beginning of CCcam.cfg

In the header of the config, there are directives that affect reshare globally. A few important ones:

SHARE LIMITS: 10

SHARE LIMITS — the maximum number of cards that one peer can receive from you. If a peer requests more, the excess is cut off. This is a global ceiling that acts above individual reshare settings.

CACHE EX HOPS — the depth of the ECM response cache. Do not confuse with reshare hops — this is about cache, not about card redistribution.

ALLOW TIMEOUT set in milliseconds. 3000 is standard; for unstable lines, it can be raised to 5000.

Local reshare for a specific card through F: line

F-lines describe local users. If you want to redistribute a specific card to a specific user with a certain depth:

F: username password 1 0 0 { 0:0:1 }

Fields after login/password: allow AU (1=yes), maximum uphops (0=no limit), minimum uphops (0), and in parentheses — reshare for this client. If your reader distributes a local card, but the globalSHARE LIMITS cuts the CAID — the card will not reach the peer, even if everything is correct in the F-line. Always check both levels.

Where the config is located: /var/etc/CCcam.cfg and /etc/CCcam.cfg

On receivers with Enigma2 firmware (Dreambox, Vu+, GigaBlue), the config is usually found at/var/etc/CCcam.cfg. On other platforms —/etc/CCcam.cfg. Sometimes you can also find/usr/local/etc/CCcam.cfg, depending on how the daemon is installed.

After any config changes, the changes will not apply by themselves. A daemon restart is needed:

# On Enigma2:&& CCcam&

This is a common mistake: you fixed the reshare, waited — nothing changed. The daemon just didn't re-read the config.

Depth limitation: hops, uphops, and loop protection

This is the part that most manuals explain poorly. I will show how hops and uphops work together — because looking at one parameter without the other is meaningless.

Setting the maximum hop count

Imagine a chain:Server A → Server B (you) → Server C. Server A gives you a card withreshare 2. This means the card can go down another 2 nodes. You received it at hop=1. When you redistribute it to server C — it will receive it at hop=2. If you have in the C-line to server C writtenreshare 1 — server C can re-share it to another client below.

I recommend keeping reshare at a value of 1 in most cases. Value 2 is only needed if you have a three-link chain and you know what you're doing. Value 3 and above — the card goes somewhere on the internet uncontrollably.

The uphops parameter for receiving cards

Now the receiving side. If you setuphops 2 in the N-line or in the user settings — you are saying: "accept only cards that have passed no more than 2 hops." A card with hop=3 will be cut off at the entrance.

A classic situation: you turned on reshare, the peer says "I don't see any cards." You look — in their configuphops 1, and the card comes to them already with hop=2. It gets cut off. The solution: either reduce the depth of the chain or increase uphops for the peer.

The parameterEMU RESHARE deserves a separate mention. It controls the re-sharing of cards decrypted through software emulators (SoftCAM). If your CCcam works with a built-in emulator and you want these cards to go to peers as well — you need to explicitly enable:

EMU RESHARE: yes

By default, emulated cards are not ready for re-sharing.

Preventing line looping

A loop occurs when two servers mutually re-share the same card with each other. Server A receives a card from B and re-shares it to B. B receives a card from A (which he gave) and re-shares it back to A. The cache gets clogged, the load increases, and ECM responses start to lag.

CCcam tries to detect loops by the card identifier, but not always successfully. The best protection is a conscious architecture: if you are exchanging lines with a peer, at least one of you must setreshare 0 for cards from the other side. Or use different CAIDs in sharing so that the same card doesn't go back and forth.

Checking and diagnosing reshare

Configuring is half the battle. You also need to ensure that reshare is actually working. CCcam provides several tools for this.

CCcam web interface on port 16001

By default, the CCcam web interface is available on port 16001. Open in your browserhttp://192.168.1.X:16001 and see the server status. The port can be changed via a directive in the config:

WEBINFO LISTEN PORT: 16001

If the port is occupied or the web interface is unresponsive — check if the daemon is running and if the port is not blocked by a firewall.

Reading the Active clients and Shares section

In the web interface, two sections are of interest when debugging reshare:Shares andActive clients.

In the Shares section, you can see all the cards that the server knows: their CAID, provider, and — importantly — with what hop they arrived. If a card arrived with hop=1, it means you received it directly from the source. Hop=2 — through one intermediate node. You can also see the reshare value for each card — the parameter with which you received it and with which you are sharing it.

In Active clients, you can see connected peers and what cards they are requesting from you. If a peer is connected but the card is not going to them — look at the hop column and reshare value for that card. If reshare=0, the card is not being re-shared. If the hop of the card is greater than the uphops of the peer — the same story.

Telnet and log files for debugging

CCcam supports telnet. You connect to port 16000 (or another specified in the config) and can view the status in real-time:

telnet 192.168.1.X 16000

The CCcam log file is usually located in/tmp/CCcam.log or/var/log/CCcam.log. It shows the events of connecting/disconnecting peers and, more importantly, the failures in card resharing with a reason. Look for lines withRESHARE andHOP — they will indicate where the chain is broken.

If the card appears in the log, but the peer does not see it — the problem is on the peer's side (its uphops or its config). If the card does not appear in the log at all — the problem is at the entry, at the source.

Reshare in OScam: equivalent of the setting

OScam is increasingly used as a replacement for CCcam — it is more stable, flexible, and actively supported. But the logic of reshare there is different, and when transitioning from CCcam, people get confused. Here’s how it works in OScam if you are communicating with CCcam peers using the CCcam protocol.

The cccreshare parameter in oscam.server

The file/etc/oscam/oscam.server describes the readers and connections to peers. For each CCcam peer, you can set the depth of reshare directly in the reader section:

[reader]

cccreshare here is analogous to reshare in the C line of CCcam. A value of 1 means that cards from this reader are reshared 1 hop down.ccchop — a limit on the depth of accepted cards (analogous to uphops).

Global cccreshare in oscam.conf

In the file/etc/oscam/oscam.conf there is a section[cccam], where a global default value is set:

[cccam]

The parameterreshare here is the global default for all CCcam connections. The value in the[reader] section (viacccreshare) takes precedence over the global one. So if you want different behavior for different peers — set it in each reader separately.

cccmaxhops limits how deeply OScam accepts cards from CCcam sources. This is a global uphops filter for the entire system.

reshare_mode — resharing mode. A value of 0 means that only cards from readers with explicitly setcccreshare are reshared. A value of 1 means everything available is reshared. It’s better to keep it at 0 and manage explicitly.

Linking OScam server with CCcam peers

Mixed chainCCcam → OScam → CCcam works because OScam implements the CCcam protocol. But there is a nuance: when OScam receives a card from a CCcam source and gives it to a CCcam peer, the hop counter continues to grow. If the source gave the card withreshare 2, and the OScam node adds +1 hop, the card will arrive at the final CCcam client with hop=2 — and if it hasuphops 1, it will be cut off.

That is why, in mixed chains, it is necessary to explicitly monitor the total depth. CCcam reshare: configuration in such heterogeneous networks requires a clear understanding of how many hops accumulate at each node — otherwise, you will be searching for the problem for hours.