OScam: installation, configuration, and server launch

If you have already worked with CCcam and are tired of the black box that does not make it clear what it does and why it crashes — oscam is what you should switch to. Open source code, modular configuration, readable logs. Here we will break everything down step by step: from the structure of the configs to diagnosing specific errors.

What is OScam and how does it differ from CCcam

OScam as an open-source emulator and proxy

OScam (Open Source Conditional Access Module) is a software client, server, and proxy for working with conditional access systems (CAS). One process can simultaneously accept cards from readers, distribute keys to clients via different protocols, and proxy requests further down the chain. There is no separate "client" and "server" version — one binary, everything is managed by configs.

The source code is available in the official SVN repository (streamboard.de/svn/oscam/). This means that for any hardware — Enigma2 receiver, OpenWRT router, regular Debian server — you can compile the binary yourself. No compiled binaries with unknown content.

Key differences from CCcam: open code, modularity, logging

CCcam is a closed binary, the development of which has effectively stopped several years ago. One protocol, one config file, minimal logs. If something breaks — you look into the void and guess.

OScam is structured differently. The configuration is divided into separate files by purpose: global parameters, readers, users, channel filters. Logging is configured by masks with detail down to the level of individual subsystems. In the web interface, you can see the status of each reader, ECM response time, active client sessions — in real time.

There are several protocols: newcamd, cccam, camd35, cs378x, gbox. Oscam understands all of them simultaneously — you can accept cards via one protocol and distribute them via another.

When OScam is the right choice, and when it is excessive

If you need a simple client for one source and you are satisfied with CCcam — there is no point in migrating. OScam requires manual configuration of each file, understanding of CAID, SID, protocols, and access rights. It is not difficult, but it is work.

But if you have several sources with different protocols, several users who need to have restricted access to channels, or you are simply tired of guessing why it periodically freezes — the transition is justified. The transparency of oscam in diagnostics is unmatched.

Structure of OScam configuration files

All configs are stored in one directory. On receivers, this is usually/var/etc/ or/etc/tuxbox/config/. On a Linux server —~/.oscam/ by default, or any directory specified by the key-c at launch. It is better to specify the path explicitly:oscam -c /etc/oscam/.

oscam.conf — global parameters and web interface

The main configuration file. Here, global parameters, sections for each protocol-server, and the web interface are specified. The minimum working option:

[global]
logfile = /var/log/oscam/oscam.log
maxlogsize = 512
preferlocalcards = 1
saveinithistory = 1

[webif]
httpport = 8888
httpuser = admin
httppwd = yourpassword
httprefresh = 10

The section[webif] opens the HTTP interface. Port 8888 is a typical option, 16002 is also common. Access without a password is a vulnerability: anyone on the same network segment can see all your readers, user logins, and can restart the process. Always secure with a password, and never expose this port directly to the internet.

oscam.server — description of readers and sources

Each reader is a separate section[reader]. This can be a physical smart card in a USB/built-in reader, or a network source via the newcamd/cccam protocol:

[reader]
label = my_newcamd_source
protocol = newcamd
device = 192.168.1.100,15000
key = 0102030405060708091011121314
user = clientlogin
password = clientpass
caid = 0500
group = 1

Fieldcaid — identifier of the conditional access system. 0500 — Viaccess, 0604 — Irdeto, 0B00 — Conax, 0D00 — Cryptoworks. Specify only those CAIDs that are actually needed — unnecessary ones create unwanted request traffic.

oscam.user — client accounts

Each client connecting to your server is described in the section[account]:

[account]
user = stb_livingroom
pwd = password123
group = 1
caid = 0500
au = 1

The parameterau allows for authorization update (AU). Without it, cards that require periodic key updates will stop working. The fieldgroup links the user with readers — the client only sees the readers from their group.

oscam.services and oscam.dvbapi — channel and DVB filters

Inoscam.services named groups of channels by SID and CAID are described. Inoscam.user andoscam.server access to specific services can be allowed or blocked — convenient when you need to allow one client only on the sports package.

The fileoscam.dvbapi is only needed if OScam works locally with a DVB tuner via the dvbapi interface. On a clean server without a tuner, it is not needed.

Setting up and starting the OScam server

Building from source and ready binaries for the required architecture

This is an important point that is often ignored. Oscam is built for a specific architecture: ARM (most modern receivers), MIPS (old Dreambox), x86/x86_64 (regular server). Taking a binary "for Dreambox" and running it on Vu+ Solo — will not work, or it may work, but will silently crash without any errors.

Building for x86 Linux:

svn checkout http://streamboard.de/svn/oscam/trunk oscam-svn
cd oscam-svn
make USE_LIBCRYPTO=1 HAVE_DVD=0

For cross-compilation for ARM, the corresponding toolchain is needed. Usually, it is already included in the SDK of your receiver (for example, as part of Enigma2 OE-core). It is specified through the variableCROSS:

make CROSS=/opt/toolchain/bin/arm-linux-gnueabi-

Ready binaries for popular platforms are published on the streamboard.de forum. But if you take a ready one — check the build date and SVN revision version. A 2023 build will miss several important patches.

A separate story — receivers with small flash memory (8-16 MB). The OScam binary weighs from 700 KB to 2 MB depending on the included modules. If space is insufficient, configs and log files are moved to a USB drive: mount it in/mnt/usb/ and start oscam with-c /mnt/usb/oscam/.

First launch and command line parameters

Basic launch:

oscam -b -c /etc/oscam/ -r 2

Parameters:-b runs as a daemon (background process),-c specifies the directory with configs,-r 2 enables auto-restart on crash (level 2 — restart with reloading configs). Without-r on crash the process will simply disappear.

Check that the process has started:

ps aux | grep oscam

The web interface athttp://localhost:8888 should open within a few seconds after startup — the time depends on the number of readers and their initialization speed.

Autostart via systemd or init script

On any modern Linux with systemd, create a unit file/etc/systemd/system/oscam.service:

[Unit]
Description=OScam Cardserver
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/oscam -b -c /etc/oscam/
WorkingDirectory=/etc/oscam/
Restart=on-failure
RestartSec=5
User=oscam

[Install]
WantedBy=multi-user.target

Create a user, enable and start:

useradd -r -s /sbin/nologin oscam
systemctl daemon-reload
systemctl enable oscam
systemctl start oscam

The parameterRestart=on-failure withRestartSec=5 does the same as-r, but at the OS level — more reliable. View logs viajournalctl -u oscam -f.

On older receivers without systemd, create an init script in/etc/init.d/. The structure depends on the distribution (OpenPLi, BlackHole, OpenATV), but the essence is the same:start-stop-daemon --start --exec /usr/bin/oscam -- -b -c /var/etc/.

Protocols and network ports in OScam

Newcamd protocol and its configuration

Newcamd — TCP protocol with encryption, one port per CAID. If you have three CAIDs — you need three ports. Inoscam.conf section[newcamd]:

[newcamd]
key = 0102030405060708091011121314
port = 15000@0500:000000
port = 15001@0604:000000

Format:port@CAID:SID-filter. Zeros in the SID filter mean "all channels".

The 14-byte encryption key is the same for the server and the client. The standard test key of all zeros or0102...0Eshould not be used in production — change it to something unique.

The cccam protocol inside OScam as client and server

OScam can act as a CCcam client (connecting to a CCcam server) and as a CCcam server (accepting clients that use CCcam). To accept CCcam clients inoscam.conf:

[cccam]
port = 12000
version = 2.3.0
build = 11700
reshare = 1

Port 12000 is the de facto standard for CCcam, but any port above 1024 can be used. If a real CCcam server is running on the same host — a conflict is inevitable, change the port in one of them. By the way, having both the old CCcam and oscam running on the same server is a common situation during migration. Just do not give them the same ports.

Port selection and forwarding on the router

To accept external clients, port forwarding is needed: TCP ports newcamd (15000+) and/or cccam (12000) from the router to the server. The web interface port (8888 or 16002) should not be forwarded externally — never.

If the server is behind NAT with a dynamic IP — the readers of remote clients will periodically lose connection when the address changes. This can be solved through a DDNS service: DynDNS, No-IP, or any similar service. In the reader's config on the client, a hostname is specified instead of an IP. But it is important to understand: when the server's IP changes, there is a pause before the DNS record is updated — usually from a few seconds to a couple of minutes. During this time, the reader will show ERROR.

Diagnostics and solving typical errors

Reading logs: debug levels and what they show

The logging level is set by the parameterdebuglevel in the section[global]. The value is a bitmask from 0 to 65535, where each bit enables logging of a specific subsystem:

• 1 — general debugging
• 2 — client connections
• 4 — readers
• 8 — ECM requests
• 16 — EMM (authorization update)
• 256 — network traffic

For diagnosing problems with channels, a value ofdebuglevel = 64 (ECM + readers) is sufficient. Full debug65535 produces a huge amount — on weak hardware, this significantly loads the system and fills the flash memory if the log is written there.

The timestamp in the log must be trusted. If the time zone on the receiver is incorrect (which happens after a firmware update or RTC battery discharge) — all records will have the wrong time, and correlating events with real actions is impossible. Check:date on the receiver should match the real time.

The reader is not connecting or the status is CONNECTED but there is no ECM

Status OFF means that oscam is not trying to connect at all — most likely, there is an error inoscam.server: incorrect IP, port, or protocol. Status ERROR — the connection was attempted, but a refusal or timeout was received.

The situation "CONNECTED but channels do not open" is a separate story. Most often, the reasons are:

• Inoscam.user the client does not have the required CAID specified or has an incorrect one
• Inoscam.services there is a filter that blocks the requested SID
• The source is connected, but this specific channel is not included in its package
• Mismatch between the reader group and the user group

Verification algorithm: look at the log for the line "ECM rejected" or "no card found for". If there is "ECM rejected" — the problem is in the rights. If there is no record of the ECM request when switching channels — the problem is earlier, at the DVB interface level or client settings.

Long ECM response times and image freezes

ECM time — the time from the key request to its receipt, measured in milliseconds. You can view it in real-time in the web interface, section ECM history, or through the fileecm.info.

Normal values: 100-400 ms for direct connection to the card, 200-800 ms for a network source. Values above 1000 ms start to cause noticeable freezes. Above 1500 ms — the picture will "break" at each refresh interval.

Causes of high ECM time: overloaded source (too many clients on one card server), long proxy chain (each intermediate server adds latency), slow network between you and the source.

How to choose a source for OScam and not make a mistake

Technical criteria for evaluating a source

The first thing to look at is the supported protocols. OScam can do a lot, but the source may only support one. Ask in advance: newcamd or cccam, and on which port.

The second — declared CAIDs. A source that "supports everything" often does not open half of the packages upon real checking. Check the specific CAIDs you need — oscam shows what exactly responds to ECM requests.

The third — information about uptime and restarts. A source that restarts once a day to update keys is normal. A source with several outages per week is already a problem.

Signs of an unstable and resold source

A resold source is when too many clients are connected to one physical card server. Signs in oscam: ECM time is unstable and jumps from 200 ms to 2000+ ms throughout the day, periodic "ECM timeout" without visible reason, the reader goes into ERROR and returns by itself.

If freezes occur during prime time (19:00-23:00) and disappear at night — it is almost guaranteed to be a resold server. The load correlates with how many people are watching TV at the same time.

Another sign of problems — frequent disconnections with immediate reconnections. In the log, this looks like cycles CONNECTED → ERROR → CONNECTED with intervals of a few seconds. The reason is usually in the unstable network of the source or its attempts to rotate clients under load.

Trial period and verification before permanent use

Normal practice is a trial period of 24-48 hours before drawing conclusions. During this time, you need to capture at least one prime time period and one night for comparison.

Specific checklist for verification through the oscam web interface:

• Average ECM time over 24 hours — should be stable, not jumping 3-5 times
• Number of "ECM timeout" in the log — single instances are acceptable, systematic ones are not
• Continuous uptime of the reader — breaks should be rare
• All necessary channels open — check each CAID separately

If the source has passed 48 hours without significant problems — it can be considered a working option. If not — look for another, do not waste time on "it will fix itself".