Wicardd WebIF Monitoring: Setup & Config Guide

If you've got Wicardd running and decoding but you're flying blind — no idea whether readers are actually connected, what your ECM times look like, or which clients are hitting your server — this is the fix. The Wicardd webif monitoring setup is what gives you that live dashboard, and getting it working properly is mostly a config-and-firewall problem. This guide covers enabling it, reading the data it gives you, locking it down, and digging out when it refuses to cooperate.

Enabling the Wicardd WebIF: Config Block and Ports

The WebIF is off by default on most builds. You have to explicitly enable it in the config file and then restart the daemon. Sounds obvious, but I've seen people spend an hour checking firewall rules before realizing they never turned the thing on.

The [webif] section in wicardd.conf

On a standard Linux install, wicardd.conf lives at /etc/wicardd/wicardd.conf. On some builds — particularly older router firmware like OpenWRT or Enigma2 images — you'll find it at /var/wicardd/wicardd.conf or even /usr/local/etc/wicardd/wicardd.conf. Check with find / -name wicardd.conf 2>/dev/null if you're not sure.

The block you're looking for looks like this:

[webif]enabled=1port=8888bindaddr=0.0.0.0user=adminpassword=changeme

If there's no [webif] section in your config at all, add it manually. A missing section is just as disabling as enabled=0, and unlike a parse error, it fails silently — Wicardd keeps decoding normally while the WebIF never starts. That's the kind of thing that costs you an afternoon.

Setting the listen port and bind address

Port 8888 is the most common default, but it's entirely config-defined. Some builds ship with 8080, some with 8000. Whatever you set here is what you'll use in your browser. Pick something above 1024 so the daemon doesn't need root just for the WebIF.

The bindaddr key is where most people go wrong. 0.0.0.0 means listen on all interfaces — reachable from your LAN. 127.0.0.1 means localhost only — the WebIF is invisible to every other machine on your network. If you're troubleshooting LAN access issues, check this value first. It's the source of the problem more often than the firewall is.

Restarting the daemon to apply changes

On systemd-based distros: systemctl restart wicardd. On SysV init systems: /etc/init.d/wicardd restart. On embedded router builds without either of those, you're usually doing killall wicardd && wicardd & or using whatever the firmware's service manager provides (on OpenWRT, that's often /etc/init.d/wicardd restart too, but the path differs).

A HUP signal (killall -HUP wicardd) works for reloading config on some builds, but not all implementations honor it for WebIF changes specifically. A full restart is safer.

Verifying the WebIF is listening

Before you open a browser, confirm the port is actually bound:

ss -tlnp | grep wicardd# or on older systems:netstat -tlnp | grep wicardd

You want to see the process holding your port. Then do a quick sanity check from the box itself:

curl -s http://127.0.0.1:8888/ | head -20

If curl returns HTML, the WebIF is alive. If it returns "connection refused," the daemon either didn't start, ignored the WebIF block due to a config parse error, or started and crashed. Check ps aux | grep wicardd to confirm the process exists, then look at your log file.

Reading the Monitoring Dashboard: Readers, Clients, ECM/EMM

Once you're in, the dashboard is more useful than it first looks — but you have to know what you're reading. Each section tells you something different about the health of your setup.

Reader status indicators and what green/red mean

The readers section shows each upstream card source you've defined. Green means the daemon considers that reader connected and active. Red or grey means it's disconnected, timed out, or failing to authenticate. A reader that keeps flipping between states is unstable at the source end — or there's packet loss between you and it.

Pay attention to the "last decode" timestamp if your build shows it. A reader that's "connected" but hasn't decoded anything in 20 minutes is not actually serving you.

Client connection list and protocol columns

Each row in the clients section is a connection to your Wicardd instance from a downstream device — a set-top box, another softcam, whatever's using your shares. You'll see the client IP, which protocol it's speaking (newcamd, CCcam, etc.), and the CAID:ProviderID combination it's requesting.

A client showing the right CAID but stuck on a provider ID you don't have coverage for will never decode. That's a config mismatch on the client side, not a Wicardd problem. The dashboard makes it immediately obvious.

ECM time, decode rate, and cache hits

ECM time is your most useful single metric. It's the round-trip time in milliseconds from when an ECM request arrives to when Wicardd returns a control word. Low and consistent is what you want. Spiky or climbing ECM times mean either your network path to the card source is degrading, the source is overloaded, or you're hitting a reader that's geographically far away.

Cache hits are free decodes — the control word was already in memory from a recent identical request. High cache hit rates are genuinely good; they reduce load on your upstream source and speed up client decoding. If you're seeing zero cache hits on a multi-client setup where clients are watching the same channel, something's wrong with how caching is configured.

Uptime, load, and EMM updates

The uptime counter tells you when the daemon last restarted. If it resets unexpectedly, Wicardd crashed or was killed — worth investigating. EMM counts track entitlement management messages, which are how smart card key updates propagate. If EMM counts are climbing normally, your card is receiving updates. If EMMs drop to zero and stay there, the card may lose decoding ability after the current key period expires. For softcam setups where you're forwarding EMMs upstream, watch this metric.

Some builds auto-refresh the dashboard every 30–60 seconds. Others don't refresh at all and require a manual page reload to get current data. If your stats look frozen, try hitting F5 before assuming something's broken.

Securing WebIF Access: Authentication and Network Exposure

The Wicardd WebIF shows operational data — reader addresses, client IPs, protocol info, CAID coverage. That's enough to be genuinely useful to someone who shouldn't have it. Running it on plain HTTP with no authentication on a publicly reachable port is a bad call, and I'd say that even if it weren't sensitive: all WebIFs should have auth.

Setting WebIF username and password

The user and password keys in the [webif] block enable HTTP basic auth. Set them and restart the daemon. When you next load the dashboard, your browser will prompt for credentials. This is a bare minimum — it's not strong security, but it stops casual exposure.

[webif]enabled=1port=8888bindaddr=192.168.1.100user=myadminpassword=use-something-real-here

If your build doesn't support these keys, they'll be silently ignored. Verify auth is actually working by opening the page in an incognito window and checking whether it challenges you.

Binding to LAN vs exposing to WAN

Binding to your specific LAN IP (like 192.168.1.100) or to 0.0.0.0 with firewall rules is the right approach for local access. Never bind to 0.0.0.0 without firewall rules if the host has a public-facing interface. The Wicardd WebIF monitoring setup sends everything in plaintext HTTP — there's no TLS built in, so credentials and data go over the wire unencrypted.

Reverse proxy with HTTPS

If you need remote access, put nginx in front of it. Here's a minimal config that adds TLS termination and basic auth at the proxy layer:

server { listen 443 ssl; server_name monitor.yourdomain.example; ssl_certificate /etc/ssl/certs/your-cert.pem; ssl_certificate_key /etc/ssl/private/your-key.pem; auth_basic "Wicardd Monitor"; auth_basic_user_file /etc/nginx/.htpasswd; location / { proxy_pass http://127.0.0.1:8888; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }}

One thing to watch: some Wicardd WebIF builds use relative asset paths, so if your reverse proxy changes the URL structure (a non-root location block, or a trailing slash mismatch), the page loads but the CSS and JS don't — you get unstyled HTML. If that happens, add a sub_filter directive or adjust the proxy path to match what the WebIF expects.

An SSH tunnel (ssh -L 8888:127.0.0.1:8888 user@yourserver) is the zero-configuration alternative if you just need occasional remote access without setting up nginx.

Firewall and port restrictions

Lock the WebIF port to trusted IPs only. With iptables:

# Allow trusted LAN rangeiptables -A INPUT -p tcp --dport 8888 -s 192.168.1.0/24 -j ACCEPT# Drop everything else on that portiptables -A INPUT -p tcp --dport 8888 -j DROP

With ufw: ufw allow from 192.168.1.0/24 to any port 8888. Either way, the principle is the same: this port should not be reachable from untrusted networks.

Troubleshooting WebIF Problems

There are really only a handful of ways this breaks. Work through them in order and you'll find it fast.

WebIF unreachable or connection refused

Start with the process: ps aux | grep wicardd. If the daemon isn't running, nothing else matters. Get it running first.

If it is running, check the port: ss -tlnp | grep 8888 (substitute your port). No output means the WebIF block was either disabled, malformed, or silently ignored. Pull up your config and look for syntax errors in the [webif] section — an extra space, a typo in the section header, mismatched brackets. Wicardd often keeps decoding normally when it hits a parse error in one config section while silently ignoring that section entirely. Check your log file for any warning about the webif block.

Port reachable from localhost but not from your LAN? It's the bind address. Change bindaddr=127.0.0.1 to your LAN IP or 0.0.0.0, restart, and retest.

Page loads but shows no readers or clients

The WebIF only reflects what the Wicardd daemon actually knows about. If your readers aren't defined in the main config, or they're defined but failing to connect, the dashboard will show nothing or show them as disconnected. This isn't a WebIF bug — it's accurate reporting.

Check that your reader entries in wicardd.conf are correct: hostname/IP, port, protocol, credentials. Then look at the daemon log for connection attempts and errors. A reader that's misconfigured won't appear as "connected" no matter how many times you reload the dashboard.

Wrong or blank stats after restart

Stats reset on daemon restart — that's normal. ECM counts, decode rates, uptime all go back to zero. If stats stay at zero after clients connect and channels start decoding, check whether log level is set high enough for the WebIF to get activity data. Some builds require loglevel=5 or similar to populate full dashboard stats.

Also: if you're running multiple Wicardd instances on the same host (test setup, multiple card profiles), they can't both bind to port 8888. One will start, the other will silently fail to bind the WebIF port. Give each instance a different WebIF port in its respective config.

Port already in use conflicts

Run ss -tlnp | grep 8888 before assuming Wicardd owns that port. Sonarr, Plex, various NAS services, and a dozen other things default to 8888 or common high ports. If something else is there first, Wicardd loses the bind silently. Change your WebIF port to something less contested — 9000, 9080, 18888 — and restart.

Choosing a Reliable Card Source for Stable Monitoring

Here's where the Wicardd webif monitoring setup actually earns its keep beyond just showing you a status page. The metrics in your dashboard are the most objective measure you have of whether a card source is any good.

Why source stability shows up in your WebIF stats

Every quality problem a source has shows up as a measurable signal in your dashboard. High ECM times mean distance or overload. Frequent reader disconnects mean unstable infrastructure. Decode failures on specific CAIDs mean the source doesn't actually have the coverage it claims. You don't need to take anyone's word for it — run a source for 24–48 hours and the dashboard tells you the truth.

Generic criteria to evaluate before committing

What you're looking for: ECM times that are consistent and low, with minimal variance over time. A source that averages fast but spikes wildly is worse in practice than one that's slower but predictable. You also want clean reconnection behavior — when a reader drops and reconnects, it should recover quickly and not stay in a failed state.

CAID and provider ID coverage matters too. Confirm in your dashboard that the specific CAID:ProvID combinations you need are actually decoding successfully, not just that the reader shows as "connected." Connected and decoding are different things.

Uptime is the other big one. A source that goes down for hours every few days is not a stable source regardless of how good its ECM times look when it's working.

Red flags visible in the dashboard

Watch for: ECM timeouts that keep incrementing while the reader stays "connected" (phantom connection — the TCP socket is up but the source isn't responding), decode failure rates above a small baseline, and EMM delivery dropping to zero for extended periods. If you see a reader that looks connected but ECM requests are timing out rather than decoding, the source is either overloaded or broken at the application layer. A reader that oscillates between connected and disconnected every few minutes is practically useless for smooth decoding regardless of ECM time when it's up.