CCcam Radegast Setup: Full Config & Port Guide

If you've landed here, you already have a CCcam or OScam box running and something about the Radegast side of your chain is broken. The documentation is sparse, the forum threads contradict each other, and nobody seems to agree on which config file does what. This article covers the complete CCcam radegast protocol setup and configuration process — from the server-side port binding all the way through to debug logs and tunneling. No fluff, no fake benchmarks. Just the config lines that actually work.

What the Radegast Protocol Actually Is (and Why It Confuses People)

The confusion almost always starts with naming. People see "Radegast," "newcamd," and "CCcam" used interchangeably in the same forum post and assume they're variants of the same thing. They're not — and conflating them will waste hours of your time.

Radegast vs newcamd vs CCcam protocol

Newcamd is an encrypted protocol using 3DES. Every connection requires a shared key (the 14-byte DES key in the client config), and authentication happens at the handshake level. CCcam's native protocol is its own binary format with a different handshake and its own encryption layer. Radegast is neither of those. It's a stripped-down, largely plaintext control word (CW) exchange protocol — designed for simplicity, not security.

The practical difference: with newcamd you have a login username, password, and DES key. With Radegast, there's none of that. The server either allows your IP or it doesn't. That's the whole access control model.

Where Radegast fits in a CCcam/OScam chain

Most real-world setups that involve Radegast look like this: an OScam instance sits between the card hardware (or upstream source) and the rest of the network. OScam exposes a Radegast listener that local or LAN clients can connect to. If the final downstream device only speaks native CCcam protocol, you chain a local CCcam instance to the OScam reader.

Pure CCcam-to-Radegast without OScam in the middle is technically possible but poorly supported. CCcam's own Radegast handling is limited compared to OScam, which has had first-class Radegast support for years. If you're trying to make CCcam act as a native Radegast server directly, you're going to hit walls fast. The working path is OScam as the Radegast endpoint.

The cs357x (Radegast) and cs378x (Radegast-over-camd35/HTTP) naming

This is where most documentation falls apart entirely. In OScam's terminology, cs357x is the classic Radegast reader protocol — the plaintext one. The name comes from historical port conventions. cs378x is a different beast: it's a camd35-over-TCP variant (sometimes called Radegast-over-HTTP) that adds a light protective layer on top.

When you're editing oscam.server, you'll set protocol = radegast for cs357x connections and protocol = cs378x for the camd35/HTTP variant. Most guides never explain this distinction, which is why people end up trying random keywords until something sticks. When you see protocol = cs357x — that's an older notation and not universally accepted across builds. Use protocol = radegast in the reader block for the classic protocol.

Plaintext, unauthenticated design and what that implies

Radegast has no encryption and no user authentication by design. The original intent was a simple, low-overhead CW distribution on trusted local networks. It does the job fine for that use case. But this design choice means anyone who can reach the port can request control words. No username, no password, no key exchange — just an open TCP connection.

This is why Radegast is appropriate on a trusted LAN and a genuinely bad idea over the open internet without a tunnel. More on that in the security section.

Server-Side Configuration: Exposing a Radegast Port

The server side lives in two OScam files: oscam.conf (global listener) and potentially oscam.server (where you map specific readers to the Radegast output). Get the listener block right first.

OScam oscam.conf radegast block

Open /etc/oscam/oscam.conf and add a [radegast] section if it doesn't already exist. A minimal working block looks like this:

[radegast]port = 8888allowed = 127.0.0.1,192.168.0.0-192.168.0.255

That's the minimum. OScam will listen on TCP port 8888 and accept connections only from localhost and the 192.168.0.x subnet. Don't leave allowed empty — on some builds that defaults to accepting all connections, which is exactly what you don't want.

You can also add nodeid or user parameters depending on your OScam version, but for a basic LAN setup the above two lines get you running. Save, then restart OScam.

Setting the listen port and allowed IP ranges

Port 8888 is conventional for Radegast but it's not mandatory — you can use anything above 1024 that isn't already taken. Check what else is running first: ss -tlnp gives you a full list of bound ports. If you're also running the OScam web interface, watch for conflicts — the webif often runs on port 8888 or 16002 depending on your build. Set one of them to something else.

The allowed field accepts individual IPs, CIDR-style ranges, or dash-separated ranges. For a single trusted remote host: allowed = 192.168.1.50. For a full subnet: allowed = 192.168.1.0-192.168.1.255. Keep it tight.

Also think about which interface you're binding to. By default OScam binds to all interfaces (0.0.0.0). If your machine has both an external NIC and an internal LAN NIC, binding to all interfaces means the Radegast port is technically reachable from the external side too — your firewall rules might block it, but defense in depth matters. You can add bindaddr = 192.168.0.1 inside the [radegast] block to pin it to the LAN interface only.

Mapping a reader/CAID to the Radegast output

OScam routes ECM requests through its reader pool automatically based on CAID matching. You don't need explicit wiring between a reader and the Radegast listener — as long as your reader in oscam.server is in a group that Radegast clients can access, the routing happens internally.

If you want to restrict which cards a Radegast client can query, set the caid and ident filters on the reader entry, and configure groups carefully. A Radegast client user (auto-created or defined in oscam.user) can be restricted to specific groups that only contain the readers you want them to see.

Restarting and confirming the port is listening

After restarting OScam, run this on the server:

ss -tlnp | grep 8888

Or if your system is older:

netstat -tlnp | grep 8888

You should see something like 0.0.0.0:8888 (or your specific bind address) with the OScam PID. If nothing shows up, OScam either failed to parse the config block or your build doesn't include the Radegast module. Check OScam's startup log — it logs which listeners it activated.

To confirm the module is compiled in: oscam --show-info 2>&1 | grep -i radegast. If you get nothing back, your binary doesn't have the Radegast reader/server compiled. You'll need a different build. This is more common than people realize with pre-packaged builds.

Client-Side Configuration: Reading a Radegast Feed

Once the server is confirmed listening, the client side is where most of the day-to-day troubleshooting happens. The config goes into the client machine's /etc/oscam/oscam.server file.

OScam cs357x reader in oscam.server

Here's a complete, working reader block for a Radegast (cs357x) source:

[reader]label = radegast_lanenable = 1protocol = radegastdevice = 192.168.0.10,8888caid = 0500ident = 0500:000000group = 1reconnecttimeout = 15

The device field is IP and port as a comma-separated pair — no spaces. The caid field tells OScam only to ask this reader about CAID 0x0500 services. Without it, OScam will query this reader for everything and you'll get ECM timeouts on CAIDs the source can't serve.

Required fields: device (host,port), protocol, caid, ident

Skipping caid and ident is the most common config mistake I've seen. The reader will connect fine, but OScam routes every unknown ECM through it, which adds latency and fills your logs with failed queries. Always filter down to what the source actually carries.

The ident field format is CAID:ProviderID. If you don't know the provider ID, start with 000000 as a catch-all, then narrow it once you can see the actual provider IDs in the ECM log. Overly strict ident filtering is one of the causes of "connected but no cards" — covered in the troubleshooting section.

cs378x for the camd35/HTTP variant and when to prefer it

The cs378x reader block looks nearly identical, but the protocol keyword and authentication change:

[reader]label = radegast_remoteenable = 1protocol = cs378xdevice = remote.example.internal,8888user = youruserpassword = yourpasswordcaid = 0500ident = 0500:000000group = 2

cs378x adds a username/password layer and is more NAT-friendly because the client initiates the connection outbound — useful when the server side is behind a firewall that allows outbound traffic but not inbound. It also handles some edge cases around multi-byte CW encoding that older Radegast implementations get wrong. For any link that crosses the internet (even over a tunnel), cs378x is the less problematic choice.

On a trusted LAN where you control both ends, classic Radegast (cs357x) is fine and has less overhead.

Group, fallback, and CAID/provider filtering

OScam uses groups to control which readers are available to which users. If you're chaining OScam → CCcam on the same box, the local CCcam instance usually shows up as an auto-created user in OScam with group access defined in oscam.user. Make sure the group on the Radegast reader matches what that user has access to.

Setting fallback = 1 on a Radegast reader tells OScam to only use it when other readers fail. Useful if you have a primary local card and the Radegast source is a backup — it prevents unnecessary ECM forwarding to the remote when the local card can handle it.

Troubleshooting: No Cards, No Decode, Connection Refused

This is the section that actually matters. Most guides dump a config block and call it done. The real work starts when the config is in place and something still isn't working.

Reading OScam logs with debug level 4 for reader traffic

First step: turn up the logging. In oscam.conf under the [global] section:

[global]logfile = /var/log/oscam.logmaxlogsize = 1000loghistorylines = 1000

Then restart with debug level: oscam -d 255 (from command line) or add debuglevel = 255 to the [global] block for persistent debug logging. At level 4+ you'll see individual ECM lines showing the CAID, provider ID, the hex ECM itself, and whether the reader returned a CW or a "not found" response. At 255 you get everything — noisy but complete.

An ECM line that succeeds looks roughly like: ECM 0500 <hexstring> CW found (127ms) by radegast_lan. A failure looks like: ECM 0500 <hexstring> CW not found. The distinction between "not found" and "no answer" matters — see below.

'Connection refused' vs 'connected but no ECM answer'

"Connection refused" means one thing: the TCP connection failed. The port isn't listening, or a firewall dropped the SYN. Check the server with ss -tlnp | grep 8888, then check iptables/nftables on the server side. Also verify the allowed list in oscam.conf — OScam drops connections from IPs not in that list before the reader even sees them, and this can look like a firewall refusal from the client side.

"Connected but no ECM answer" is a different problem entirely. The TCP path is fine. Something at the protocol layer is wrong. CAID or ident mismatch is the most common cause — the upstream source simply doesn't have a card that can decrypt the requested service. Check with tcpdump: tcpdump -i any port 8888 -X while the client tries to decode. If you see ECM packets arriving at the server and nothing going back, the server received the request but couldn't find a CW.

CAID/provider mismatch and empty card lists

A reader that connects but returns empty card lists almost always has a filtering problem. Either the caid field on the reader doesn't match what the source carries, or the ident field has a provider ID that doesn't exist on the card.

Pull the OScam web interface on the server (port 8888 or 16002 — not the same port as Radegast, pick different values for each) and check the reader status. It should show what CAIDs and provider IDs the card reports. Compare that against your reader config on the client. Even a single hex digit off in the provider ID will produce an empty result with no error message.

Also: some builds of OScam have the Radegast module compiled in but with subtly broken CAID enumeration. If everything else checks out and you're still getting empty lists, test with caid and ident removed entirely — if cards appear, your filtering values were wrong. Add them back one at a time.

MTU, NAT, and firewall issues over the internet

If you're running Radegast over a WAN link (already a bad idea for plaintext, but let's debug it anyway), MTU fragmentation can silently corrupt ECM payloads. The classic symptom is intermittent decoding — some channels work, others don't, and it seems random. Run ping -M do -s 1400 remote_server_ip from the client to test path MTU. If you get fragmentation-needed responses, lower your MTU on the tunnel or add a clamp rule.

CGNAT is a harder problem. If the client machine is behind carrier-grade NAT, incoming connections to that machine simply won't work — cs357x requires the server to be reachable. Either use cs378x (client initiates the outbound connection) or set up a WireGuard tunnel that creates a stable routable path.

Freezes and CW-not-found on high-bitrate channels

Freezing after a few seconds, especially on high-bitrate channels, is nearly always a latency problem. DVB-S2 crypto periods run about 10 seconds. The client needs to receive a fresh CW before the current one expires. If your Radegast reader is on a slow WAN link with 200ms+ RTT, the ECM round-trip can eat enough of that window that the CW arrives too late.

UHD channels are worse — they sometimes use shorter crypto periods and higher ECM frequency. A link that's fine for SD will freeze on UHD. Measure actual ECM response times in the debug log (the time value in the ECM line). Anything over 2-3 seconds is a problem for most channels. Fix the underlying routing before blaming the protocol.

Mixed-endian firmware on older receivers is a separate edge case. Some older STB firmware misreads CWs from a Radegast source — the bytes come in reversed — producing intermittent black screen that clears and re-freezes on a roughly 10-second cycle. If you're seeing this on one specific receiver but not others, the STB firmware is the suspect, not your OScam config.

Security and Reliability Hardening for Radegast

This part gets skipped in most writeups, which is part of why Radegast has a reputation for being inherently insecure. It's not the protocol's fault — it was designed for a trusted LAN. The problem is people using it beyond that context without any additional protection.

Never expose a plaintext Radegast port to the open internet

Raw Radegast on a public IP means anyone who can reach port 8888 can send ECM requests and receive CWs. Your firewall allowed list helps, but IP spoofing and hijacking are real on the open internet. Beyond the access control problem, the data itself is plaintext on the wire — visible to anyone on the path between client and server.

If you have port 8888 open in your router's port forwarding rules and bound to a public IP, close it now. Use a tunnel instead.

Tunneling Radegast over SSH or WireGuard/OpenVPN

SSH local port forwarding is the quickest solution if you already have SSH access to the server:

ssh -L 8888:127.0.0.1:8888 user@your_server_ip -N

This binds port 8888 locally on the client machine and forwards it over the encrypted SSH connection to the server's localhost:8888. Your OScam reader on the client then points at 127.0.0.1,8888 instead of the server's IP. The Radegast traffic is encrypted end-to-end and never hits the open internet as plaintext. The server's allowed list should include 127.0.0.1 for this to work.

WireGuard is the cleaner option for a persistent setup. Once the WireGuard tunnel is established, the Radegast reader points at the server's WireGuard internal IP (e.g., 10.0.0.1,8888), and all traffic transits through the encrypted tunnel automatically. No need to maintain an SSH session. On a Raspberry Pi or similar low-power box, WireGuard adds minimal CPU overhead compared to OpenVPN.

Tightening the 'allowed' access list and per-reader groups

Even on a LAN, don't leave allowed set to a broad range unless every device in that range should have access. If only one machine should connect, put only that machine's IP in the list. OScam logs rejected connection attempts, so you can see if something unexpected is trying to connect.

OScam's group system is also your friend here. If a client's credentials (or IP, for Radegast's IP-based access) get compromised, a well-configured group setup limits the blast radius. That compromised connection can only reach readers in its assigned groups — not your full card pool.

Preferring cs378x when a remote link is unavoidable

If you absolutely must run a Radegast-style link over the internet and a tunnel isn't an option, cs378x is the better choice over raw cs357x. The authentication layer means a random IP can't just connect and start pulling CWs — they need valid credentials. It's not encryption in the strong sense, but it's meaningfully better than open Radegast.

Combine cs378x with a tight allowed list that restricts to the client's static IP, and you've got a setup that's at least defensible for a private home lab.

Getting CCcam radegast protocol setup and configuration right is mostly about understanding which layer a problem lives in — TCP/firewall, CAID routing, or the protocol itself — and having the right debug tools to tell them apart. The config lines above are the working baseline. When something breaks, the OScam ECM log and a quick tcpdump will tell you exactly where the chain is broken.

One last edge case worth noting: if you're doing a full CCcam radegast protocol setup and configuration from scratch and OScam silently ignores your [radegast] block, always check oscam --show-info first. A binary compiled without READER-RADEGAST will parse the config file without error and just not activate the listener — no warning, no log entry, just a port that never opens. This catches a lot of people using pre-built packages from repositories that compile with a minimal feature set.