OScam test: checking configuration and connection

If you've just set up OScam and don't know whether it's actually working or just pretending to — this text is for you. A proper oscam test isn't a single command or a single "check" button. It's a sequence of several steps: the process is running, the configs parsed without errors, the readers connected, and the card actually responds to ECM requests. I'll go through each step the way I do it myself when setting up a new server — with specific paths, commands, and logs.

Below is the working methodology I use when putting OScam into operation. No fluff, just what you actually need to check before considering the server operational.

What "OScam test" means and where to start checking

People often confuse "the server started" with "the server is working." These are different things. The daemon can start, listen on ports, and yet not decrypt a single channel — because the card expired, the provider dropped, or the config has an indentation error. A full oscam test always follows the chain: process → configs → readers → actual decryption. There's no point skipping steps, because the problem is almost always not where it seems at first glance.

Checking the daemon startup and build version

The first thing I do on a new server is check whether the process is even alive:

ps aux | grep oscam

If there's a line with oscam in the output and it's not grep itself — the process is running. Next I check the build version, because it determines protocol support and the presence of bugs that have already been fixed in newer revisions:

oscam -V

The command outputs the version number, build date, list of enabled modules (CCCAM, NEWCAMD, CONSTCW, WEBIF, and so on), and the path to the config directory. If the WEBIF module isn't compiled in — the web interface won't work at all, no matter how much you edit the configs.

Key configuration files and their location

Paths differ across different builds. The classic location is/etc/tuxbox/config/oscam/ or/var/tuxbox/config/, on some receivers and Linux distributions — simply/etc/oscam/. Three files you'll be working with constantly:

• oscam.conf — global settings: webif, logging, cache, timeouts
• oscam.server — list of readers: network sources and local cards
• oscam.user — client accounts and their rights/groups

It's worth memorizing these paths by heart — during diagnostics you'll be opening them dozens of times in a single evening.

Enabling the web interface (webif) for monitoring

Without webif, the OScam test turns into reading raw logs blindly, which is inconvenient. Inoscam.confwe look for or add the section:

[webif]

After restarting the daemon, open in the browserhttp://server_IP:8888. If the page opened and asks for a login — half the job is done: the daemon is alive, the config parsed, webif is listening on the port. Next comes the actual content check.

Configuration test and reader status

The web interface on port 8888 is your main tool. In the Readers section you see a list of all connections: local cards, and network sources via cccam, newcamd or camd35. This is where the main oscam test happens — you literally see who's online and who's not.

Checking oscam.server and oscam.conf syntax

OScam is very demanding about file format. Tabs instead of spaces, a BOM marker at the start of the file (a common problem if the config was edited in Windows via Notepad), an extra space before a key — and the parser either silently ignores the block, or the reader doesn't appear in the list at all. You can check syntax two ways: see if the reader appeared in webif, and read the log at startup — there OScam usually explicitly states which section it couldn't parse.

Example of a correct reader block for a network source:

[reader]

Port 12000 is standard for the cccam protocol, but the provider may use any other one — this is always specified separately.

Reader statuses: connected, unavailable, error

The status column in webif usually has three states that are important to distinguish:

Status	What it means
connected / ONLINE	Connection established, authorization passed
unavailable / OFFLINE	Server unavailable: port closed, network issue, wrong host
error	There is a connection, but authorization or protocol doesn't match

ONLINE doesn't yet guarantee decryption — it's only about the network connection. But error almost always indicates a wrong login/password or an incompatible protocol.

Checking a local card via oscam.dvbapi and PID

If the card is physically inserted in the receiver's card slot, the reader is described differently — without a network device, but with a physical slot specified:

[reader]

In the webif Card infos section for such a reader, you see the card's CAID, provider ID, and, importantly, entitlements — a list of open packages with subscription end dates. If the card reads but entitlements are expired — this is not a server error, it's the state of the card itself, and no oscam test will fix it.

Decryption test: reading ECM logs and timings

The ONLINE status in the reader list is only half the job. A real oscam test ends where you see actual ECM lines in the log with the result found. Everything else is just preparation.

How to read an ECM line in the log (found, not found, timeout)

Run the daemon in foreground mode for live monitoring:

oscam -b

The path to the log is set by the parameterlogfile in oscam.conf, and by default it's often/tmp/.oscam/oscam.log. A typical line looks something like this:

2026-07-20 21:14:03 client (10) source1 cluster: ECM 0100/0021/0100 found (190 ms)

Let's break it down by fields: the system CAID (0100), the provider ident (0021), then the card itself (0100), the result found, and the response time in milliseconds. If instead of found we see not found — the source received the request but couldn't decrypt it. Timeout means the response didn't arrive at all within the allotted time.

Normal response time and what counts as slow

In my experience, a response within 300-400 ms is a comfortable zone, and the picture opens without delay. Values above 600 ms already produce noticeable freezes when switching channels and sometimes picture breakup for a few seconds. If the time jumps from 150 to 900 ms over the course of one evening — look into source load or the network quality between you and the server.

For detailed debugging, raise the loglevel in oscam.conf:

[log]

With loglevel = 4, debug messages for each reader individually also get logged, which greatly simplifies finding a specific problem.

Checking via dvbapi on the receiver itself

The dvbapi section is responsible for transmitting the CW (control word) from the server to the receiver:

[dvbapi]

If the receiver works as a separate device, and OScam is installed on it or on a linked server, boxtype needs to be specified exactly according to the model (for example, dreambox, dm7025, or coolapi for some Android set-top boxes) — an incorrect boxtype often breaks CW transmission even with a fully working reader. Open any channel on the receiver and watch the log: if the ECM lines appear at the same time as the picture opens — dvbapi is configured correctly.

Diagnosing problems after a failed test

When oscam test doesn't pass the first time — that's normal, it happens almost always during initial setup. Below is a table of typical symptoms and what to do about them.

Symptom	Probable cause	How to check
Reader OFFLINE	Port closed, firewall, wrong host	telnet host port
ECM not found	CAID/provider or group mismatch	Compare caid and group on the reader and client
Persistent timeout	Source overload, network delays	ping, traceroute to the server

Reader OFFLINE: network, port, firewall

First I check the port availability directly, without OScam:

telnet host 12000

If the connection is not established — the problem is at the network or firewall level, not in the OScam configuration. Check iptables on your side (iptables -L) — the INPUT chain often blocks outgoing connections to non-standard ports by default. Also double-check the device itself in oscam.server — a typo in the IP address happens more often than it seems.

ECM not found: incorrect CAID/ident or group

The reader is online, the connection is established, but every request returns not found — a classic parameter mismatch. The source server has a specific set of CAID and provider ident that it actually serves. If your oscam.server specifies a caid that the source doesn't have, or the wrong group (client in group 2, but the reader is only configured for group 1) — there will never be a response, regardless of connection status.

Persistent timeouts and picture freezes

If ECMs consistently arrive delayed or time out specifically in the evening — it's most often due to source overload, when many clients are requesting decryption at the same time. Check the parameters in oscam.conf:

[global]

The fallbacktimeout parameter determines how long to wait for a response from the primary reader before switching to the backup one. cccmaxhops limits the number of intermediate servers in the reshare chain — the more there are, the higher the total latency. If you only have one source configured with no fallback, there's simply nothing to switch to when it's overloaded.

How to choose a card source for testing (general criteria)

At the testing stage, many people connect the first public source they find, just to check that the configs are written correctly. This is a working approach for diagnosing OScam itself, but don't confuse a temporary test line with a permanent solution.

What to look at: stability, uptime, card locality

If you're still choosing a permanent source, several objective parameters matter, not loud promises. Server uptime — how rarely it goes down and how quickly it recovers after failures. Ping to the server — the lower it is, the more stable the ECM timing and the lower the chance of timeout. CAID and provider ident matching the channels you actually watch — a source can be excellent but simply not serve the package you need. And a reasonable reshare value — too long a chain of servers between you and the card almost guarantees added delay.

The danger of public and unstable sources

Public free lines are convenient for quickly checking that OScam is in principle capable of decrypting the signal, but you shouldn't rely on them for permanent operation. They're overloaded, drop without warning, and often deliver ECM with timing well over 600 ms — the picture will freeze even with a perfectly configured server. For a full oscam test this is an acceptable temporary option, but not a permanent solution.

Legal context of use

Card sharing touches on copyright issues related to content broadcasting, and the rules here vary depending on the country and the specific broadcast operator. Use OScam and similar tools only within the framework of the legislation in force in your jurisdiction and only for content to which you have legal access rights. Responsibility for complying with local regulations lies with the user.