CCcam reshare: configuration of C/F lines and protocol

If you have set up a CCcam server and connected to several peers, sooner or later the question arises: how to properly organizeCCcam reshare: configuration so that the cards go to your clients instead of turning the network into a mess of loops and freezes. Let's break it down step by step — from the mechanics of hop to the actual config in/var/etc/CCcam.cfg.

What is reshare in CCcam and how does hop/depth work

Reshare is when your server takes a card received from a remote peer and distributes it further to its clients. That is, you not only consume cards from above but also transmit them down the chain. The mechanism is simple, but configuring it without understanding the hop parameters means running into problems.

The principle of resharing: from card to client through peers

The scheme looks like this: the provider has a physical reader with a card → your server connects to its CCcam server → your clients connect to you. The card is physically located at the source, and only ECM requests and CW responses (Control Words) go down the chain. Reshare is the transmission of these CW from your server to clients who are not connected to the source themselves.

The hop parameter: what do the values 0, 1, 2 mean

Hop is a counter of the "jumps" of the card from the source to the current node. A card inserted into a physical reader on the server hashop 0 (local). When you receive it through a C line from a peer — it comes to you ashop 1. If you distribute it to your client, for them it is alreadyhop 2. Each jump adds ECM delay — usually from 50 to 150 ms per node, depending on the hardware and load.

Depth and why it limits the chain

Depth is the maximum allowable hop value at which the card can still be distributed further. If the depth is 2, a card with hop 2 will not go to the next client. The parameter is set through downhops in the F line. It determines how deeply the card can "sink" down the distribution chain from your server.

How reshare differs from direct access to the card (local)

A local card (hop 0) is what you have in the reader directly on the server. It is the fastest, with minimal ECM time. A reshared card always goes through the network, and each node adds time. Providers often impose a limit on the maximum hop — for example, they do not accept cards with hop higher than 3. This is not a whim, but a protection against degradation of the ECM signal in long chains.

Configuring reshare in the CCcam.cfg file: F lines and values

All CCcam reshare configuration comes down to two types of lines in the config: C lines (client) receive cards from a peer, F lines (friend) distribute cards to their clients. They cannot be confused — these are fundamentally different directions of flow.

Location of the config: /var/etc/CCcam.cfg

The main config is located at/var/etc/CCcam.cfg. On some Linux distributions, you may encounter/etc/CCcam.cfg or/usr/local/etc/CCcam.cfg — it depends on how the package is built. Always check the actual path viaps aux | grep CCcam — there will be the key-c indicating the file.

Structure of the F line: F: { username password downhops uphops }

The format is as follows:

F: username password downhops uphops

username andpassword — the credentials of the client connecting to your server.downhops — how many levels the client can share your card further to their clients.uphops — how many levels of cards from the client you accept in exchange (in mutual sharing). A value of 1 for downhops means that the client receives the card and can pass it down to one more level. A value of 0 means the card is received but not shared further.

Global RESHARE directive and local per-user

You can globally enable reshare with a directive at the beginning of the config:

RESHARE: 1

This allows sharing by default for all F lines. But it can be overridden at the specific user level by adding before their F line:

RESHARE: 0

Then this specific user will not receive cards for further sharing, even if global RESHARE is enabled. The per-user setting overrides the global one — this is convenient when you have a mixed client base.

The parameter 'F: user pass 1 0' — share only your cards without receiving

The lineF: clientuser pass123 1 0 means: the client receives cards and can share them one more level down (downhops=1), but you do not accept anything from them (uphops=0). This is a typical scheme for one-way resharing — when you have cards, you share them, but do not want anything in return.

Example block for resharing a specific card

A working example of a minimal config with a C line for receiving and an F line for sharing:

# Receiving a card from a peer

After any changes to the config — be sure to restart the daemon. Via init.d:/etc/init.d/CCcam restart. Or forcefully:kill -9 $(pidof CCcam)&& CCcam. Without a restart, changes do not take effect — this is not nginx with reload.

Limiting and filtering resharing by cards and providers

Sharing all cards with everyone is a bad idea. Especially if you have local cards that should not go into reshare, or if you want to limit sharing by specific CAID.

Sharing only needed CAID/provid through F: { caid:provid }

CCcam supports filtering by CAID and provider directly in the F line. Syntax:

F: username password 1 0 { caid:provid }

For example, to share only Viasat cards (CAID 0x0500) from provider 0x040E00:

F: viaclient viapass 1 0 { 0500:040E00 }

You can list several separated by commas. Anything that does not match the filter will not be seen by the client — even if you have other cards on the server.

Prohibiting resharing of specific cards (sid/ident filters)

Filtering by SID (Service ID) works similarly — through the extended syntax of blocks. But honestly: in pure CCcam, this is implemented weaker than in OScam. If you need fine filtering by SID — it's better to consider OScam conversion (more on this below).

The parameter 'RESHARE: 0' to prohibit further sharing

If you need the client to not be able to share cards at all — setRESHARE: 0 before their F-line and both hop values to 0:

RESHARE: 0

This works like a "dead end" in the chain. The card reaches there and stays there.

The oscam.server file when working through OScam conversion

If part of your network operates through OScam, the resharing setup goes through/etc/oscam/oscam.server and/etc/oscam/oscam.user. Inoscam.server for the cccam reader, the parameter is added:

[reader]

The valuecccreshare = 2 means that OScam will share the received cards up to hop 2. Inoscam.user for each user similarly:

[account]

The hop logic is the same as in CCcam F-lines, but the syntax is different. In a mixed network (some peers on CCcam, some on OScam), this is one of the most common sources of confusion — people set hop on one side and forget to coordinate with the other.

Ports, protocol, and checking reshare operation

Setting up the config is half the battle. It is important to ensure that reshare is actually working, not just looking correct on paper.

The default CCcam port is 12000 and the directive SERVER LISTEN PORT

The standard CCcam port for exchanging with peers is —12000. In the config, it is set by the directive:

SERVER LISTEN PORT: 12000

This port must be open in the firewall and forwarded on the router if the server is behind NAT. The classic case: everything is set up, but the client is behind CGNAT and their port 12000 is not accessible from the outside — reshare from their side simply will not start. You can check the port's availability from an external machine usingnc -zv your.server.ip 12000.

CCcam protocol version 2.x.x and peer compatibility

The CCcam protocol version 2.x.x (currently 2.3.x) is the de facto standard. Compatibility issues arise when one server operates on an old version 2.0.x, while another on 2.3.x. Specifically, this manifests in incorrect transmission of hop values and truncation of the card list. If a peer "sees" fewer cards than it should — check the versions on both sides.

Viewing active cards in the web interface (port 16001)

The CCcam web interface is available on port16001. Open it in a browserhttp://your.server.ip:16001 — there is a tabShares shows all the cards that the server currently sees. For each card, CAID, provider, and the current hop value are displayed. This is the fastest way to ensure that the reshare has been raised and the card has reached the desired level.

If the card is in Shares with hop 1, but the client does not see it — the problem is in the F-line or RESHARE directive. If the card is not in Shares at all — the problem is with the C-line or the connection to the peer.

Diagnostic commands: line status, hop cards, ECM time

View the log in real time:tail -f /tmp/CCcam.log. It shows the ECM time for each request — a normal value is up to 500 ms, anything above 1000 ms is already alarming, above 2000 ms guarantees freezes. In the web interface, the tabECM info shows the average time for each card. If the ECM time for the reshare card is significantly higher than that of the same card from the source — the chain is too long.

Common reshare configuration errors and what DOES NOT work

Let's analyze the anti-patterns — what people most often do wrong.

Looping when two servers are mutually resharing

Classic loop: server A exchanges cards with server B, both with uphops=1. Server A gives a card to server B → B considers it its own and gives it back to server A → A receives the same card with hop increased by one. As a result, duplicates of the same card circulate in the network with different hop values, the load increases, and ECM requests start taking an suboptimal route.

Solution: when mutually exchanging, limit uphops from both sides. If A has a local card with hop 0, then B should accept it with uphops no more than 1, and when giving it back to server A — A should reject cards with hop >= 1 from B (that is, uphops=0 for the reverse direction). Set up mutual exchange asymmetrically — do not copy-paste the same F-line on both servers.

The card does not appear for the client: hop exceeded

If the card is in Shares on the server with hop 2, but the client does not have it — check downhops in the F-line. If downhops=1, the client will receive the card only if it comes with hop no higher than 1 (that is, local card + 1 hop). A card with hop 2 will not pass. Increase downhops to 2 or optimize the chain so that the card comes with a smaller hop.

Channel freezes due to a long hop chain

A long chain is not just a theory. In practice: hop 1 gives ECM time ~200–400 ms, hop 2 — 400–700 ms, hop 3 and above — it's already a gamble. Some channels start freezing at ECM time above 600 ms — especially channels with aggressive EMM or frequent CW changes. Reshare does not "fix" a slow source — if the card at the top gives 800 ms, further down the chain it will be 1200+ and freezes are inevitable.

Why 'F: user pass 0 0' blocks sharing

This is the most common confusion among beginners. The lineF: user pass 0 0 creates a user account, but with zero hops — they will not receive any cards. This is not "a client without a reshare," this is "a client without anything." If you want to give the user cards but prohibit further sharing — useRESHARE: 0 before the line, and leave downhops at 1. Or simply do not add the RESHARE directive, but set downhops=0 — then the client sees the cards but cannot pass them on.

And one more case: peer behind NAT/CGNAT. If the client has port 12000 closed and it is not forwarded — incoming connections to it do not pass. They can connect to your server through an outgoing connection, but they will not be able to raise a reverse channel for reshare. Port forwarding or a VPN tunnel is the only solution.