Setting up anti-cascading in GBox: guide 2026

If you administer CCcam or OScam with the GBox plugin and notice an abnormal increase in ECM requests from a single peer — most likely, your card is already circulating through a chain of servers further than you allowed. This is where gbox anti-cascading is needed: configuring this mechanism is not just one line in the config, but a combination of parameters that together block the possibility of resharing.

In this guide, I will cover specific paths to files, real directives, the sequence of restart commands, and how to read the log when the protection is triggered. No theoretical digressions — just what really works.

What is cascading and why is anti-cascading needed in GBox

Cascading is when your trusted peer not only views the shared card but also becomes a server for its clients. From the protocol's perspective, it looks like this: an ECM request comes to you with hop count = 1 (direct peer), but the number of requests and their distribution across channels indicate that there are actually another 5–10 clients behind this peer.

How cascading occurs: the peer shares your card further

GBox is a protocol over UDP (default port 8888, set in the launch string or plugin config). It transmits CW (control words) between nodes with its own hop counter in the packet header. The peer receives CW from you, and if it has no restrictions on resharing, it broadcasts it further across its network. Formally, the hop count increases, but if the peer forges it or you have no checks — you won't see it.

The most common scenario: you gave access to a "friend," and he sold 20 sub-accounts, and his server generates 200 ECM/min on your card instead of the usual 5–10.

Why cascading is dangerous: card ban by the operator and overload

Operators monitor abnormal decryption patterns. If simultaneous requests come from one card across multiple multiplexes — the detection algorithm triggers, and the card gets banned. This really happens, and recovery takes from several days to a complete card block.

Moreover, an overloaded uplink starts responding unstably. ECM time increases, peers experience picture freezes, and you end up being blamed, even though the problem lies in the cascade below.

The principle of anti-cascading operation: ECM limits and response time

GBox anti-cascading works through three mechanisms simultaneously: hop limit, limit on simultaneous connections per share/account, and control of ECM request frequency. None of them alone provides complete protection — only the combination does.

The hop limit cuts off peers whose hop count in the packet header already exceeds the allowed value. The connection limit cuts off those who try to establish too many parallel sessions. ECM-rate control catches cases where everything looks clean formally, but too many requests come in a unit of time.

Key parameters of anti-cascading in the GBox config

Here the main thing is to understand that gbox anti-cascading: configuration in different firmware and setups looks slightly different, but the logic is the same everywhere. Let's break down specific files and lines.

Limits in CCcam.cfg: G: line and GBox parameters

The main CCcam config on Dreambox is located in/var/etc/CCcam.cfg. On TuxBox firmware —/etc/tuxbox/config/CCcam.cfg. GBox peers are added throughG:-lines:

G: hostname.peer.net 8888 mypassword 2 1

Format:G: host port password downhops uphops. The parameterdownhops — how many hops down you allow the peer to share. Setting it to 0 means prohibiting further sharing.Uphops — how many hops up you accept from the peer.

Global restrictions are set by separate directives in the same file:

CCCMAXHOPS 2

CCCRESHARE NO — complete prohibition of resharing for all C:-clients. If you need to allow only direct peers, writeCCCRESHARE 1, which limits sharing to one hop below.

Hop count limitation and uphops/downhops

CCCMAXHOPS 2 — global maximum. For direct trusted peers, I recommend setting it to 1, a maximum of 2. At a value of 3 or higher, you effectively open the possibility of a third-level cascade, and tracking it becomes extremely difficult.

Parameterdownhops=0 in the G:-line is a strict prohibition for the peer to share your card further. Its absence is often what leads to unplanned cascades. Set it explicitly, do not rely on defaults — they may differ across different versions of CCcam.

Setting max connections and ECM-rate on share

MAX CONNECTIONS 1 in CCcam.cfg limits the number of simultaneous connections from one C:-client. For home users with two receivers, you need to set it to 2–3, otherwise you will get false triggers (more on this below).

The control of ECM frequency in pure CCcam is implemented weaker than in OScam. For fine-tuning ECM-rate, it is better to use OScam with the GBox plugin — this is done through the parametersecmnotfound andfailban in the service configuration.

File locations: /var/etc/CCcam.cfg, /etc/oscam/, GBox config

For OScam, anti-cascading is configured in two files simultaneously./etc/oscam/oscam.server — description of readers and cards./etc/oscam/oscam.user — parameters of each account, including hop limits and connection limits.

Example section inoscam.user:

[account]

cccreshare = 0 prohibits this account from resharing cards.maxconn = 2 allows two devices to connect simultaneously — this is enough for one peer with a backup receiver.cccmaxhops = 1 accepts requests only from the first hop.

Logging OScam is configured in/etc/oscam/oscam.conf:

[logging]

debuglevel = 64 enables detailed output on CCcam/GBox connections. To troubleshoot cascade issues, sometimes level 128 or their combination — for example, 192 — is needed.

Step-by-step setup for cascade protection

Doing everything at once and restarting is a bad idea. Check each change separately, otherwise, if a problem arises, you won’t understand what exactly broke the legitimate connections.

Step 1: set the maximum number of hops (1-2 for direct peers)

Start with hop limit. In CCcam.cfg add or adjust:

CCCMAXHOPS 1

For OScam — in each account inoscam.user addcccmaxhops = 1. If you have peers you trust a bit more and allow one level of sharing (for example, a colleague who has several receivers at home), set them to 2, but no more.

Step 2: set the connection limit for each share/account

In CCcam.cfg globally:MAX CONNECTIONS 2. In OScam — at the level of each [account]:maxconn = 2. For commercial sharing (if for some reason you allow a peer to forward), you can set it to 5, but then the hop limit must be 1.

Step 3: enable ECM-time control and request threshold

In OScam for accounts that raise suspicion, add:

[account]

failban = 30 blocks the account for 30 minutes after a series of failed ECM.ecmnotfound = 5 — the threshold of failed requests before banning. The parameters should be adjusted to your situation: if the peer has an unstable uplink, too low values will result in false bans.

Step 4: restart the service and check the log

For CCcam, restart it like this:

killall CCcam&& sleep 2&& CCcam

For OScam on systems with systemd:

systemctl restart oscam

On older firmware without systemd:

/etc/init.d/oscam restart

After restarting, immediately check the log. For OScam:

tail -f /var/log/oscam/oscam.log | grep -i "hop\|cascade\|maxconn\|blocked"

If the log shows lines withhop limit exceeded ortoo many connections — the protection is working. If you see such lines on accounts that should not be blocked — proceed to diagnose false triggers.

Step 5: test connection with peer behavior monitoring

Ask the peer to connect and watch the channel. At the same time, monitor the log. A normal picture: 1–2 ECM requests when opening the channel, then rare requests every few minutes (when changing the key). If ECMs are continuously flowing — something is wrong: either cascading or a very unstable uplink from the peer.

Diagnosis and elimination of false triggers

The most common complaint after enabling anti-cascading: "I have a normal peer, but it is being blocked." Usually, the reason is not cascading, but quite legitimate usage scenarios.

Why a legitimate peer is defined as a cascade

A user with three receivers at home means three simultaneous connections from one account. If you havemaxconn = 1, they will definitely get blocked. The solution is simple: raisemaxconn to 3–4 for the specific account, but keepcccmaxhops = 1 strict.

Another situation is a peer behind a NAT or CGNAT of the provider. In this case, several physically different clients of the provider may connect from one IP address. Here, it is important to look not at the IP, but at the number of hops and the account.

The impact of zapping (quick channel switching) on the ECM rate

If a peer actively switches channels — each switch generates an ECM request. 10 switches per minute means 10 additional ECMs. With a low thresholdfailban, this can look like an attack.

In such cases, I raiseecmnotfound to 15–20 for accounts with multiple receivers and keep a strict hop limit. Zapping itself is not a sign of a cascade — it needs to be distinguished from a systematically high ECM rate, which is characteristic of re-sharing.

Setting thresholds based on the actual number of receivers in the family

The formula is simple:maxconn = number of receivers + 1 (buffer for reconnection). If a peer has 2 receivers — set it to 3. At the same time,cccmaxhops remains 1. This separates legitimate multi-device usage from a real cascade.

A peer with a dynamic IP adds another complexity: when reconnecting, it may briefly create two sessions (the old one hasn't closed yet, the new one has already opened). The parameterkeepalive in OScam helps manage the session lifetime — setkeepalive = 1 in [account] so that OScam actively controls the connection.

Reading the log: which lines indicate a cascade and which indicate overload

In OScam withdebuglevel = 64 enabled, cascade lines look like this:

2026/06/15 14:23:11 c [peer_alex] CAID 0D00 hop count 3 exceeded max 1, blocked

This is a real triggering of anti-cascading — hop count exceeds the allowed limit. However, the overload line looks different:

2026/06/15 14:23:45 c [peer_alex] too many connections (3> maxconn 2), rejected

This is not a cascade — it is simply exceeding the connection limit. It's easy to confuse them, but the solutions are different: for the first, you need to deal with the peer, for the second — just raisemaxconn.

A sign of a real cascade in the log is an increase in ECM on channels that the peer usually does not watch, unstable ECM-time (jumping from 300 ms to 2000 ms and back) and requests during non-working hours (4 AM, for example).

What is important when choosing sources of cards and peers

gbox anti-cascading: the setting loses its meaning if your uplink itself is an uncontrolled cascade. Therefore, it is important to understand how to evaluate peers to whom you trust your sharing.

Criteria for a reliable source without reference to specific names

A reliable peer is one who is willing to discuss hop policy explicitly and agrees todownhops=0 in the G:-line. If a peer avoids talking about hops or insists ondownhops=2 and above without explanations — this is a red flag.

The stability of the uplink is checked simply: look at the ECM-time in the log over several days. Values of 200–800 ms with rare spikes are normal. Constant jumps to 2000–3000 ms indicate an unstable channel, and then your peers will experience freezes regardless of anti-cascading.

Signs of a peer that is cascading itself

In the log, look at the uphop count of incoming ECM. If requests from a peer regularly come with hop count = 2 and above, while you expect only direct connections — it is itself an intermediate node in someone else's cascade.

Another sign: an abnormally high number of unique CAID/SID in requests. One home user rarely watches more than 5–10 channels a day. If requests from one account have gone through for 80 different SIDs in a day — this is clearly not one person.

Checklist of signs of an unreliable peer:

• Refuses to explicitly agree on hop policy
• ECM-time is constantly unstable (jumps> 5x from the average)
• The number of unique SIDs per day is abnormally high
• Connections come from a large range of IPs (CGNAT is an exception, but it is visible)
• Activity at unusual times (deep night in their time zone)

Agreements on hop policy between administrators

The best protection is an agreement before sharing begins. Clearly specify:downhops=0,maxconn for a specific usage scenario, and that upon detection of a cascade, the account will be immediately disabled without warning.

In mixed networks CCcam + OScam, hop policy is interpreted slightly differently. CCcam counts hops according to its logic, OScam — according to its own. When switching between them, hop count may be miscalculated or recalculated. Therefore, in mixed networks, I recommend setting the hop limit even stricter — 1 for all external peers without exceptions — and checking logs on both ends.