Server R2 CCcam: Reshare Configuration, Setup and Limitations

If you have already set up your CCcam server and are distributing lines to clients, sooner or later the question will arise: what level of reshare should be set? The topic of server r2 cccam causes confusion even among experienced admins — some confuse reshare with hops, others set R2 for everyone and wonder why the server is down. I will break everything down: what R2 means, how to configure it in CCcam.cfg, what pitfalls await, and how not to kill performance.

This article is not an advertisement for anyone's lines. It only covers the technical side: syntax of configs, real ECM timing numbers, log analysis, and specific recommendations for configuring server r2 cccam for different scenarios.

What R2 Means in CCcam Server

The letter R and the number after it represent the level of reshare, which is the permission for redistributing (resharing) a card-sharing line. R2 means that the recipient of your line can share it further, and the person who receives it from them can also share it one level down. Two levels of redistribution from the original server.

Reshare Levels in CCcam: from R0 to R5

Here’s how the hierarchy works:

• R0 — line for personal use only. The client receives the card, decodes channels, but cannot share it further with anyone. Period.
• R1 — the client can share the received line one level down. Their clients will be able to watch, but will not be able to share.
• R2 — two levels of redistribution. The client shares with their clients (R1), and those share with theirs (R0).
• R3–R5 — similarly, each level adds another depth. In practice, R3+ is rarely used — ECM timings become unacceptable.

Visually, the chain at R2 looks like this:

Card → [Your server] → Client A (R2, can share) → Client B (R1, can share) → Client C (R0, can only watch)

Each transition adds additional latency. And additional load on the original server, because all ECM requests ultimately reach it.

How Hop Count is Related to Reshare Level

A hop is the number of servers through which an ECM request has passed from the client to the card. Reshare is the permission, while hops measure the actual distance. When you give a client a line with R2, you allow the creation of a chain up to 2 additional hops.

But hops can exist without reshare. If your server itself receives a line from another server — that’s already one hop. Add R2 reshare, and the final client may end up 3-4 hops away from the card. ECM time at such depths is a lottery.

In CCcam logs, hops are displayed as hop 0 (direct access to the card), hop 1 (through one server), hop 2 (through two), and so on. When configuring F-lines, it is useful to correlate the reshare level with the actual hops in the log.

R2 vs R1 and R0: Practical Differences

R0 is ideal for end users. They simply watch channels. No surprises, minimal load on your server from each such client.

R1 is for trusted peers who need to share the line with their 5-10 clients. You control the first level, they control the second. ECM timings grow moderately.

R2 is already serious. You are effectively giving someone the right to build a mini-network from your card. One client with R2 can generate load equivalent to 20-50 end users. Use it only when you clearly understand why.

How to Set Up R2 Reshare in CCcam.cfg

All the magic of reshare lives in the CCcam configuration file. On most Enigma2 images, it is /etc/CCcam.cfg, on some older images — /var/etc/CCcam.cfg. On Linux servers, the path depends on where you installed CCcam, but usually it is also /etc/CCcam.cfg.

F-Line Syntax for Managing Reshare

The F-line defines the client account. Here’s the complete syntax:

F: {username} {password} {reshare} {caid} {provider}

Examples:

# Client with full R2 reshare for all cards
F: user1 mypass123 2

# Client without reshare rights (view only)
F: viewer1 viewpass 0

# Client with R1, limited to one CAID
F: peer1 peerpass 1 { 0:0:2 }

# Client with R2, only for a specific provider
F: reseller1 respass 2 { 0500:032830:2 }

The third parameter after the password is the reshare level. The number 2 means R2. If the parameter is not specified, CCcam defaults to the value from global settings (usually 0).

Setting Reshare for Each User Individually

This is the most correct approach — to set reshare individually. There’s no need to give R2 to everyone when most clients are end viewers.

# === End users — view only ===
F: client01 c01pass 0
F: client02 c02pass 0
F: client03 c03pass 0

# === Trusted peers — one level of reshare ===
F: peer_alex peerA123 1
F: peer_boris peerB456 1

# === Reseller — two levels of reshare ===
F: reseller_ivan resI789 2

I recommend adding comments directly in the config — in six months you won’t remember who and why you gave R2. CCcam supports comments using # at the beginning of the line.

If you have a server r2 cccam and want to limit a specific user, simply change the number in their F-line and restart the service. Downgrading from R2 to R0 will instantly cut off all downstream clients at the next ECM request.

Global Reshare Settings with CAID and Provider Filtering

In addition to per-user settings, CCcam allows filtering reshare by specific cards. This is critically useful when there are multiple cards on the server and you want to share only part of them.

# Allow reshare only for Canal+ (CAID 0500, provider 032830)
F: user1 pass1 2 { 0500:032830:2 }

# Allow R1 for Sky UK (CAID 0963) and R0 for everything else
F: user2 pass2 1 { 0963:000000:1 }

# Block a specific CAID from reshare (R0 for it)
F: user3 pass3 2 { 0500:032830:0 }

The filter format is: { CAID:PROVIDER:RESHARE_LEVEL }. You can specify multiple filters separated by commas. If PROVIDER = 000000, it means "all providers for this CAID".

There is also a global option in CCcam.cfg:

RESHARE : 2

This sets the maximum reshare by default for all F-lines where reshare is not explicitly specified. But I do not recommend relying on this setting — it’s better to specify reshare explicitly in each F-line. This reduces the chances of accidentally giving someone R2 when you intended R0.

R2 Server Performance and Impact on ECM

This is where the reality begins that those selling R2 lines won’t tell you. Each level of reshare is a load multiplier. And ECM timings grow not linearly, but in jumps.

How R2 Reshare Affects ECM Response Time

Typical ECM timings that I have observed in practice:

Level	ECM Time (ms)	Comment
R0 (local card)	200–400	Card in the reader, direct access
R1 (one hop)	350–700	Acceptable for HD channels
R2 (two hops)	500–1100	On the edge, freezes possible
R3+ (three or more)	800–2000+	Practically non-functional

The critical threshold is 800 ms. Above this, visible freezes begin, especially on HD and 4K channels. At R2, you are balancing on this edge. If the original server is slightly slower than usual — everything will collapse down the chain.

Load on the Channel and Number of Connections at Reshare Level 2

One client with R0 = one ECM connection. One client with R2 = potentially dozens of ECM connections, if they and their downstream clients are actively sharing. The problem is that...