Cardsharing on OScam: setting up the server from scratch

If you have already installed OScam on a receiver, router, or Linux set-top box and are now looking at an empty oscam.server, not knowing where to start — this material is for you. Cardsharing oscam works differently than CCcam: everything here is built on configuration blocks, the relationships between them, and precise syntax. One extra space — and the card will not initialize. We will go through everything step by step, with real configuration examples and diagnostics from the logs.

What is cardsharing on OScam and how does key exchange work

OScam is an open-source softcam written in C that can simultaneously read a physical smart card in a card reader and distribute keys to clients over the network. Or vice versa — receive keys from a remote server and pass them to its DVB adapter. This is the key difference from simpler solutions.

The principle of DCW and control words

Every ~10 seconds, the encrypted DVB stream contains an ECM packet (Entitlement Control Message). The smart card decrypts it and returns a DCW — a double control word of 16 bytes, which is used for decoding video. Without the current DCW, the picture freezes or breaks into artifacts.

In cardsharing, the card is on one machine, while the ECM request comes from another. The server sends the received DCW back to the client over the network. The delay of this transmission is what is referred to as ECM time, which can be seen in the OScam web interface.

The role of OScam as a client and as a server

In oscam.server, readers are described — both local (physical card) and network (remote server as a source of keys). In oscam.user, client accounts that connect to your OScam for keys are described. The same daemon can simultaneously be a client of a higher-level server and distribute keys downwards.

Local reader vs network connection

The local reader reads the card through the card reader: /dev/sci0 for the internal reader of the receiver or /dev/ttyUSB0 for a USB card reader on PL2303/FTDI chips. The network reader is a connection to someone else's server via the newcamd, CCcam, or cs378x protocol. The setup is fundamentally different, and they should not be confused.

Structure of OScam configuration files

Paths depend on the platform. On Enigma2 firmware (Dreambox, VU+, GigaBlue), configs are usually located in/etc/tuxbox/config/oscam/. On routers with OpenWrt or Entware — in/etc/oscam/ or/usr/local/etc/oscam/. On bare Linux — wherever you specify when starting with the key-c /path/to/folder. The exact path can always be checked with the commandps aux | grep oscam.

oscam.conf — global parameters and web interface

This is the main config. The minimum working section[global] and[webif]:

[global]

After starting, the web interface will be available athttp://IP:8888. Change the password from the default — this is not paranoia, but basic hygiene.

oscam.server — description of readers and connections

Each reader is a separate block[reader] with a header[reader]. This describes both the local card and network connections. The order of the blocks is not critical; the parameters inside are important. The syntax is strict:parameter = value, without spaces around the equals sign in some versions — it's better to put spaces everywhere, it's more reliable.

oscam.user — client accounts

Each client that connects to your OScam receives a block[account] in this file. Here, the login, password, group (group), and CAID restrictions are set. Without an entry in oscam.user, the client will not connect at all.

oscam.services and oscam.dvbapi

oscam.services allows grouping channels by SID and creating access profiles — needed for fine filtering. oscam.dvbapi manages interaction with the DVB adapter directly, relevant when OScam and the decoder are on the same machine. For basic configuration, these files can be left untouched.

Reader and protocol configuration: newcamd, cccam, cs378x

This is the most important part. Most problems with cardsharing oscam occur here: incorrect protocol, wrong key, or unlinked groups.

Local reader for smart card (protocol = mp35/internal)

For the internal card reader of the receiver:

[reader]

For USB card reader (PL2303, FTDI), change device and protocol:

[reader]

Aboutmhz andcardmhz: the value 357 corresponds to 3.57 MHz. Some cards are initialized only at 368 (3.68 MHz). If the card hangs during initialization — first try changing these two parameters. Try 357, 368, 600. The log will show something likecard init error or just silence afterATR.

Network reader using newcamd protocol (port 15000+)

Connecting to a remote server via newcamd:

[reader]

Keykey — this is 14 bytes in hex format without spaces and separators (28 characters). The standard test key 01 02 03 ... 14 is written as0102030405060708091011121314. If the server uses a different key — you will getwrong checksum in the log and zero DCW.

Standard ports: newcamd operates on 15000–15011 (often a separate port for each CAID), sometimes using 10000 or non-standard ones.

Connecting via CCcam (port 12000) and cs378x

CCcam is easier to configure — no DES key is needed, one connection transmits several cards:

[reader]

cs378x — Camd35 protocol over UDP, port usually 15000 or 10000:

[reader]
label = cs378x_server
protocol = cs378x
device = server.example.com,10000
user = mylogin
password = mypassword
group = 1

Parameters group, caid, ident and audisabled

This is the connection that everyone overlooks. The parametergroup in[reader] must matchgroup in[account] of the client. If the reader hasgroup = 1, and the client hasgroup = 2 — the card will not release keys, and there will be no errors in the log. Just silence.

caid filters by conditional access system (Irdeto = 0604, Viaccess = 0500, Nagra = 1800, etc.).ident filters by provider within CAID. If unsure — it's better not to set it, OScam will figure it out by itself.

audisabled = 1 disables card updates (AU/EMM). For a local reader, it usually needs to beaudisabled = 0, otherwise the card will become outdated. For network readers, AU is usually unavailable — the server decides whether to transmit EMM or not.

Client configuration in oscam.user and web monitoring

When the readers are configured, you need to specify the clients that will connect to you. Or at least specify one test account for verification.

Block [account]: user, pwd, group

[account]

The parameterau = local_card indicates from which reader the client will receive EMM updates. Herelocal_card is thelabel from the[reader] block. Without this, the client only receives DCW, but not card updates.

Restriction by CAID and services

Want to restrict the client to a specific system:

[account]

Parameterservices refers to the profile from oscam.services. If the file is missing — just do not set this parameter.

Viewing the status of readers and ECM time through webif

In the web interface athttp://IP:8888 the Readers section shows the status of each reader: CARDOK (card is read), CONNECTED (network reader is connected), or red status in case of problems. A green reader — good. Everything else is a reason to check the log.

In the Clients section, active connections and ECM time in milliseconds are visible. The normal value for comfortable viewing is up to 300–400 ms. At 500+ freezes begin when switching channels. I observed values of 80–150 ms on good servers and 800+ ms on overloaded ones — the difference is noticeable.

Reading the log oscam.log and debug levels

The path to the log is set in[global]:logfile = /var/log/oscam.log. The level of detail is the parametercs_log_level. The default value is 1, the maximum for debugging is 255 (but that’s a lot of text):

[global]

To monitor the log in real time:tail -f /var/log/oscam.log. Lines withrdr — reader events, withclient — client connection events. Lines withAU — card update events.

Diagnosis of typical cardsharing errors

This is where experience really helps. Most guides stop at "it should work," without explaining what to do when it doesn’t work.

Reader in CARDOK status, but no DCW

The card is initialized, but channels do not open. The first thing I check is the parametergroup. In 80% of cases, this is where the problem lies: the reader hasgroup = 1, but the client account in oscam.user has —group = 2 or is not set at all. No group match — no DCW.

Next, we checkcaid andident. If a specific CAID is specified in[reader] and the client requests another — the request will go nowhere. Changing CAID or ident by the broadcasting provider is another common reason why it worked yesterday but not today. Providers periodically change ident, and if you have strict filtering — update the config.

Connect/handshake error and closed ports

Check if the server port is accessible from the client machine:

telnet server.example.com 15000

If the connection cannot be established — the port is closed. Reasons: firewall on the server, NAT without port forwarding, or OScam is not running at all. Port forwarding on the router is mandatory for server mode: TCP port 12000 for CCcam, 15000 for newcamd, 8888 for webif (the last one is better not to expose to the outside).

For double NAT (router behind router, typical for OpenWrt on TP-Link), port forwarding is needed at both levels. On OpenWrt, the config paths may be in/etc/oscam/ or/opt/etc/oscam/ depending on whether OScam was installed via opkg or Entware. File permissions for config files should be 644, for the folder — 755.

Invalid DES key newcamd (14 bytes)

The log shows something like:wrong checksum, expected XX got YY. The reason is clear — the keykey in the block[reader] does not match the key on the server. The key must be exactly 28 hex characters (14 bytes). Check: there are no extra spaces, no line breaks, all characters are in lower or upper case (OScam is case insensitive, but it's better to standardize).

CAID conflict and problems with AU/EMM

If you have several readers providing the same CAID — OScam will query them in order of priority. The parameterlb_weight sets the weight of the reader during load balancing,fallback = 1 makes the reader a backup — it is used only when the main one is unavailable. It works like this: if reader A and reader B have the same group and CAID, but B hasfallback = 1, then B will automatically activate when A fails.

Problem with AU: if for the local readeraudisabled = 1 — EMM packets are not processed and the card is not updated. A card with an expired term or invalid entitlements stops providing DCW. This can be seen in the log by lines withEMM.

High ECM time and image freezes

ECM time above 500 ms is already a cause for concern. Reasons: high ping to the server, overloaded server, unstable communication channel. What to do: add a second reader to the same group as a backup, check CPU load on the machine with OScam, ensure that there is no QoS on the router cutting this traffic.

Ping directly determines the base ECM time. If the server has a ping of 200 ms — you will not get less than 400 ms even under ideal conditions. The geographical proximity of the server is just as important as its technical specifications.

How to choose a key source: criteria without reference to names

Here I will discuss the methodology for evaluation, without mentioning specific services — you will have to evaluate them yourself.

Stability and uptime of the server

Real uptime is visible from the connection statistics in oscam webif — if the reader regularly reconnects (see the reconnects column), this is an indicator of an unstable server. A good server has a minimum number of reconnects per day. Claimed "99.9% uptime" without the possibility of verification is marketing.

Low ECM time and geographical proximity

Request a test line before purchasing and check the actual ECM time in webif, not just the provider's words. For European packages, the server must be in Europe. A server in Asia when watching European channels will add 100–300 ms just for network latency.

Support for required CAID and packages

Make sure the server actually provides the CAID you need. In the oscam webif, the reader's status shows which CAIDs are available after connecting. If the required CAID is not in the list, the channel will not open, and this is not a problem with your configuration.

Transparency of conditions and technical support

Adequate technical support means substantive answers with a request for oscam.log, not just "restart the receiver." A good sign: the provider can explain which protocol they use, on which port, and which CAID they provide. If there are no answers to these questions, look for another source.