Wicardd Anti-Cascading Setup: Config Guide

If you run a Wicardd-based card sharing server and your physical card is getting hammered with ECM requests, someone is probably reselling your line. Getting the Wicardd anti-cascading configuration right is how you put a stop to that — or at least make it expensive enough that it stops being worth doing. This isn't a simple copy-paste job. The thresholds matter, the sampling window matters, and setting it wrong will boot legitimate multi-tuner clients before it ever catches an actual reseller.

This guide goes through the actual config directives, how to derive sane starting values, and how to test without breaking things for real users.

What Anti-Cascading Actually Detects in Wicardd

The core idea is simple: one subscription line should produce ECM requests at roughly the rate a single receiver generates them. A well-behaved DVB-S2 receiver sends one ECM request per crypto period — typically every 8–10 seconds per active stream. If an account starts generating 15 ECM requests in the same window, something is feeding multiple downstream boxes from that one login.

That's cascading. One line, fanned out to several clients, each requesting decryption keys in parallel. The detection is based on concurrency and timing, not identity. Wicardd can't actually prove someone is reselling — it can only see that the request pattern doesn't match a single receiver.

Cascading vs. Legitimate Multi-Tuner Clients

A genuine multi-room setup with a DVB-S2 receiver and two or three extra tuners will generate parallel ECMs. So will picture-in-picture. A client recording one channel while watching another on the same box can easily hit 2–3 simultaneous ECM requests legitimately.

The difference between that and an abusive reseller is sustained concurrency at high counts. A two-tuner client peaks at 2–3 concurrent ECMs and drops back. A cascaded line running 8–12 downstream boxes sits at high concurrency constantly. That sustained pattern is what anti-cascading targets.

How Wicardd Counts Parallel ECM Requests Per Account

Wicardd maintains a per-account request counter internally. Each incoming ECM from an account increments that counter; the counter decrements as responses go out or as the rolling time window advances. What you configure is the ceiling — the maximum number of unresolved or in-flight ECMs allowed per account before the system takes action.

The evaluation is rolling, not fixed-interval. A burst at second 0 and another at second 4 are both in the window if your sampling interval is 10 seconds. That's intentional — it catches the rapid sequential requests that come from fast channel surfing, which otherwise look like low-level cascading.

ECM Time Windows and Request Rate as Detection Signals

Two numbers define the detection: the sampling window (in seconds) and the request count that triggers a flag within that window. A window of 10 seconds with a threshold of 6 means: if an account submits more than 6 ECM requests in any rolling 10-second span, Wicardd takes the configured action.

Narrow windows catch burst abusers but produce false positives on fast-zappers. Wide windows miss burst behavior but catch sustained overload. You'll need to find the right balance for your user base, which is why baselining before you configure is important — covered in Section 3.

Core Anti-Cascading Directives in the Wicardd Config

The Wicardd anti-cascading configuration lives in the main config file and optionally in per-user/account blocks. The default install path on most Linux setups is /etc/wicardd.conf. Some builds place it at /usr/local/etc/wicardd.conf or in the install directory as wicardd.cfg. Check your init script or systemd unit for the exact path being passed to the daemon — it's usually the -c argument.

Locating the Config File and the [account]/User Blocks

The global anti-cascading settings apply to all accounts unless overridden. Per-user blocks let you set tighter or looser limits for specific logins. In most Wicardd versions, user definitions look like this:

[USER]name = clientusernamepassword = clientpasswordmaxecm = 4anticascade_window = 10anticascade_threshold = 6anticascade_action = throttle

Global defaults go in the [ANTICASCADING] or equivalent global block, before any user definitions. Per-user overrides in the [USER] blocks take precedence. If you don't have per-user blocks and just use a flat user list, the global settings apply to everyone.

Setting Max Parallel ECM / Connection Limits Per User

The maxecm directive caps the number of simultaneous in-flight ECM requests for that account. This is your first line of defense. Set it too low (like 1) and a dual-tuner receiver can't function. Set it too high (like 20) and it does nothing useful.

A working starting point for a typical single-receiver client is 3–4. For a client you know runs a multi-room setup with up to 4 tuners, set it to 6–8. The anti-cascading threshold is a secondary check that watches the rate over time; maxecm is the hard simultaneous cap.

[ANTICASCADING]enabled = yesdefault_maxecm = 4default_window = 10default_threshold = 8default_action = throttlefreeze_time = 30

Defining the Detection Time Interval and Request Threshold

The default_window value is in seconds. The default_threshold is the ECM count that, if exceeded within that window, triggers action. So window = 10 and threshold = 8 means: more than 8 ECMs in any 10-second rolling period flags the account.

Why 8 and not 4? Because fast zapping. A client switching channels rapidly can submit 3–4 ECMs in quick succession as the decoder tries each service. Giving a small buffer above your maxecm simultaneous cap prevents those short bursts from triggering the rate limit.

Choosing the Action: Throttle, Freeze, or Disconnect

Wicardd typically offers three response modes:

• throttle — extra ECMs beyond the limit are delayed or ignored, the client degrades but isn't cut off
• freeze — the account is paused for freeze_time seconds, then automatically restored
• disconnect — the connection is dropped immediately, requiring the client to reconnect

Start with throttle. Hands down. The cost of a false positive on a legitimate client is a degraded picture — annoying but recoverable. The cost of a hard disconnect on a legit multi-tuner client is an angry user and a support request. Run on throttle for a week, read the logs, then decide if sustained offenders need escalating to freeze or disconnect.

After any edit to the config file, restart or reload the daemon. Changes do not apply until the daemon picks them up. On systemd setups: systemctl restart wicardd or systemctl reload wicardd if a reload is supported. A common mistake is editing the file, checking behavior, and wondering why nothing changed — the daemon is still running the old config in memory.

Tuning Thresholds Without Banning Real Users

This is where most guides fail. They give you the directives and leave you to guess the numbers. The right approach is to measure first, then set thresholds based on what you actually see.

Baselining Normal ECM Rates Per Channel and Card

Pick a known-good client — one receiver, one stream, sitting on a channel for 30 minutes. Watch the ECM rate in the Wicardd logs or status interface (more on that in Section 4). A standard DVB stream on a healthy card will clock one ECM response every 8–10 seconds. That's your baseline: roughly 6 ECMs per minute, or about 1 ECM per 10-second window.

Now you know what a single clean tuner looks like numerically. Set your threshold to accommodate that, multiplied by your expected max tuner count, plus a buffer for zapping and PiP.

Accounting for Zapping Bursts and PiP/Multi-Tuner

Channel zapping is the main false-positive trigger. When a viewer flips through several channels quickly, the decoder sends ECM requests for each one — often 3–5 in rapid succession before settling on a channel. These are legitimate requests, and they happen in a very short window.

Picture-in-picture is similar. Two streams from one box means two parallel ECM streams. That's not abuse — that's a feature of modern receivers. Your thresholds need to handle this without triggering.

A reasonable rule: set your anticascade_threshold to (max expected tuners × 2) + 2, evaluated over a 10-second window. For a client with up to 2 tuners, that's 6. For 4 tuners, that's 10. This gives room for zapping bursts while still catching an account feeding 8+ downstream clients simultaneously.

Per-Account Overrides for Trusted Multi-Room Clients

If you have specific clients you trust — friends with large multi-room setups, your own test boxes — give them explicit per-user overrides rather than raising the global threshold for everyone.

[USER]name = trustedclientpassword = securepasswordmaxecm = 8anticascade_window = 10anticascade_threshold = 12anticascade_action = throttle

This way your high-threshold exceptions don't create cover for actual abusers using default accounts. Everyone else stays at the tighter global limit.

Be careful with CGNAT clients. A user on a carrier-grade NAT shares a public IP with dozens of other subscribers. IP-based limits will flag them unfairly, but ECM concurrency limits work just fine because they're keyed to the account login, not the source IP. Keep that in mind when you're setting connection and IP limits alongside anti-cascading.

Verifying It Works: Logs, Counters, and Live Testing

Configure it, then prove it. Don't assume the settings are working just because they're in the file and you restarted the daemon.

Reading Anti-Cascading Hits in the Wicardd Log

The log path is set in the config — look for a logfile or log_path directive, often pointing to /var/log/wicardd.log or /tmp/wicardd.log. When anti-cascading fires, you'll see an entry with the account name, the ECM count that triggered it, the window it was evaluated in, and the action taken. It looks roughly like:

[2026-03-12 14:22:31] ANTICASCADE: user=clientX ecm_count=11 window=10s action=throttle

If you're not seeing these entries, either the feature isn't enabled, the log level is too low, or the daemon didn't reload the config. Check your log verbosity setting — most builds have a loglevel or debug directive; set it to at least 2 or INFO during initial setup.

Watching the Live Status/Web Interface for Flagged Accounts

Wicardd typically exposes a status interface on a local port — often TCP 8080 or a similar web UI port configured in the [STATUS] block. This shows per-account active connections, current ECM/s, and flags. It's more useful than tailing logs when you want a real-time view of who's hitting limits.

Sort by ECM rate in the live view. A cascaded account will sit at the top with an obviously disproportionate rate compared to everyone else. A single clean receiver won't even appear suspicious next to an account pushing 20+ ECM/s.

Controlled Test: Simulate Parallel Requests to Confirm Triggering

The cleanest way to verify is a controlled test. Take a spare account — not one that real clients use — and point two or three receivers at it simultaneously. Or use a test tool that can fire parallel ECM requests to the same account. Within your configured sampling window, the counter should trip and you should see the throttle or freeze action in the logs.

Then test the negative: a single receiver on its own account with normal zapping behavior should never trigger. Watch the logs over 10–15 minutes of real usage with channel changes. If you see any hits on a single-receiver account, your threshold is too low — raise it or widen the window.

Don't tighten the thresholds after one day of logs. Run the current config for several days before adjusting. ECM patterns vary by what's on air, by time of day, and by how actively your clients are zapping. A full week of data is better than a few hours.

Combining Anti-Cascading With Other Abuse Controls

Anti-cascading catches the concurrency pattern of reselling. But it's one layer, and a careful reseller who knows your thresholds can stay just under them. You need complementary controls.

Connection/IP Limits and Dynamic-IP Caveats

Per-account connection limits cap how many simultaneous TCP connections an account can maintain. For most single-receiver clients, this should be 1 or 2. A reseller feeding 10 clients needs 10 connections — even if they disguise the ECM rate, the connection count gives them away.

But don't use source IP limits as your primary abuse control. Dynamic IPs change. CGNAT means multiple legitimate users sharing one IP. A client traveling or on mobile changes IP regularly. IP-based bans will hurt real users more than determined abusers who know to reconnect. Use connection-per-account as the primary cap, IP limits as a supplementary signal only.

ECM Rate Limiting and Freeze Times

ECM rate limiting — distinct from anti-cascading — caps the ECMs-per-second an account can push through regardless of concurrency patterns. Where anti-cascading looks at parallel in-flight requests, rate limiting looks at throughput over time. Together they catch different evasion patterns.

A reseller who paces their downstream clients carefully might avoid triggering concurrency limits by staggering requests. But if 12 clients are all watching different channels, the aggregate ECM/s from that one account will still be elevated. Rate limiting catches that where anti-cascading might not.

The freeze_time value (in seconds) determines how long an account is suspended after a hard limit is hit. Thirty seconds is enough to disrupt a reseller's downstream clients — they all freeze simultaneously, which is noticeable — without being a catastrophic penalty for a legitimate client who triggered a threshold by accident.

Card Protection: ECM-Per-Second Caps to Avoid Card Bans

This is the real motivation behind all of this. Official smart cards have ECM rate limits built in at the conditional access system level. Push too many ECMs too fast and the card flags as suspicious, gets rate-limited by the headend, or gets outright banned. Card bans are not recoverable without contacting the provider.

Anti-cascading protects the card indirectly by preventing any single account from generating excessive load. But you should also set a hard card-level ECM/s cap in the server config — a value like max_ecm_per_second = 12 globally ensures that even if multiple accounts hit spikes simultaneously, the card never sees more than 12 ECMs/s total. That's the actual protection that prevents a ban, regardless of who's causing the load.

The combination of proper Wicardd anti-cascading configuration, per-account connection limits, and card-level ECM rate caps gives you three independent layers. A reseller who evades one will likely trip another. And even accidental overload from legitimate users gets caught before the card takes damage.