How to connect card sharing: setting up CCcam and OScam 2026

If you have already received the data from the server — host, port, username, and password — then half the work is done. Now you need to correctly enter them in the config and ensure that the receiver actually starts decoding. You can connect card sharing without understanding the structure of the configs, but at the first problem, you will find yourself at a dead end. This article is about what exactly to write where and how to read the result.

Let's analyze both main clients: CCcam and OScam. Each has its own logic, its own paths to files, and its own diagnostics.

What you need before connecting card sharing

Before diving into the configs, make sure you actually have something to configure. It sounds trivial, but a third of the problems arise right here.

Compatibility of the receiver and firmware (Enigma2, DVB cards, emulators)

Most modern satellite receivers based on Enigma2 (Vu+, Dreambox, GigaBlue, Formuler, and their analogs) support softcam emulators directly. If you have a cheap hardware receiver without a Linux firmware — the options are fewer, some models only support the built-in emulator through a specific menu.

On Enigma2, the softcam is installed as a plugin: CCcam, OScam, or MGcamd. After installation, it appears in the "Softcam Management" menu (or Softcam Manager). Without an installed softcam, no configs will help — there is simply nothing to decode.

For PC-based DVB cards (TBS, Prof, Hauppauge) under Linux, the situation is different: there OScam works as a daemon with direct DVB API access to the card. CCcam is used less frequently in this case.

Required connection data: host, port, username, password

You need four parameters from the server:

• Host — IP address or domain name of the server (for example,my.server.com or185.10.x.x)
• Port — most often 12000–12010 for CCcam, but it can be anything
• Username — your account login
• Password — password, usually alphanumeric

Also, clarify the protocol with your provider. By default, CCcam is assumed, but some servers operate on newcamd or provide both options on different ports.

Checking access via SSH/Telnet and FTP to the receiver

Before editing the configs, make sure you can access the receiver. Via SSH (port 22) or through FTP — it doesn't matter. On Enigma2, SSH is available by default, the password is usuallydreambox orroot. If you don't know the receiver's IP — check the web interface of the router or run a network scanner like Angry IP Scanner.

Without access to the file system, you can only edit the configs through built-in plugins like DreamExplorer or via Telnet. This works, but it's inconvenient.

How to connect card sharing via CCcam (config example)

CCcam is the most common client precisely because it is simple. All configuration boils down to one line in one file.

Structure of the C-line: C: host port username password

The classic C-line looks like this:

C: my.server.com 12000 mylogin mypassword no { 0:0:1 }

Let's break down each field:

• C: — type of line, means "connect as client" (Client)
• my.server.com — server address
• 12000 — port
• mylogin /mypassword — your credentials
• no — disable reverse sharing (recommended for clients who do not have their own cards)
• { 0:0:1 } — hop limit to 1, means that the server must have the card locally, without additional retransmissions

Parameters in curly braces are optional, but hop-limit helps filter long chains and reduce ECM time. If channels do not open — try removing the limit (just delete{ 0:0:1 }).

Where to place the CCcam.cfg file and how to set permissions

On Enigma2, the config file is located at/var/etc/CCcam.cfg. This is where you write the C-line. If the file does not exist — create it. After editing, set the permissions:

chmod 644 /var/etc/CCcam.cfg

Without the correct permissions, CCcam may not read the file at all or may only read it when launched from root. On some Enigma2 firmware, the path is slightly different — it may be/etc/CCcam.cfg. Check where the file already exists usingfind / -name "CCcam.cfg" 2>/dev/null.

Restarting softcam and checking connection status

After editing the CCcam config, it needs to be restarted. Via SSH:

killall -9 CCcam

CCcam will start automatically if configured as a service. You can also use the Softcam Manager menu in Enigma2 — there is a "Restart" button. Wait 10–15 seconds after restarting before checking the status.

CCcam web interface on port 16001 for diagnostics

CCcam raises its own web interface on port 16001. Open in your browserhttp://<IP_receiver>:16001 and see the list of your C-lines with their status.

StatusCONNECTED means that the connection to the server is established, but there are no cards. StatusCONNECTED (card) — there are cards, decoding should work.OFFLINE or empty status — connection not established, check address/port/firewall.

How to connect card sharing via OScam

OScam is more complex in initial setup, but offers much more control. If you need flexibility — multiple servers with priorities, local card, detailed logs — OScam is the right choice.

Configuration separation: oscam.conf, oscam.server, oscam.user

Unlike CCcam with its single file, OScam uses multiple configurations:

• oscam.conf — global settings: logs, web interface, general parameters
• oscam.server — description of readers (servers or cards from which we take keys)
• oscam.user — accounts for clients connecting to your OScam

Paths depend on the distribution. On Enigma2, it is most often/etc/tuxbox/config/oscam/, on regular Linux —/etc/oscam/, sometimes/var/keys/. Check the actual location viafind / -name "oscam.conf" 2>/dev/null.

Setting up reader in oscam.server (protocol cccam)

Example block reader for connecting to a CCcam server:

[reader]

Parameterlabel — arbitrary name for identification in logs.protocol = cccam indicates that we are using the CCcam protocol to connect to the server (OScam itself is the client).cccmaxhops = 1 is analogous to hop-limit in C-line.reconnecttimeout = 30 — how many seconds to try to reconnect after a disconnection.

If the server operates under the newcamd protocol, changeprotocol = newcamd and add the linekey = 0102030405060708091011121314 (encryption key, taken from the provider).

User and group profile (group) for routing

Here is a common reason for a non-working setup that almost no one explains. In OScam, groups (group) are a routing mechanism between readers and users.

Reader withgroup = 1 is available only for users withgroup = 1. If a different group is specified in oscam.user for your account (or for the built-in dvbapi client), requests to this reader will not go through, and channels will not open, even though the server shows "connected."

Example block inoscam.user for local decoding via DVB API:

[account]

And inoscam.conf you need to ensure that DVB API is configured:

[dvbapi]

OScam web interface on port 8888 and logs

Inoscam.conf add the section:

[webif]

After restarting OScam, the web interface will be available athttp://<IP_receiver>:8888. There you can see all readers, their status, ECM time, and the latest requests.

For debugging inoscam.conf enable logging:

[global]

View the log viatail -f /tmp/oscam.log — there will be lines with the results of each ECM request.

Ports, protocols, and firewall

A common misconception: people think that to make the client work, you need to "open ports." For incoming connections — yes, for outgoing — no.

CCcam protocol (port 12000+) and newcamd

CCcam operates over TCP. Port 12000 has historically become standard for CCcam servers, but this is just a tradition — the server can listen on any port from 1 to 65535. The newcamd protocol more often uses ports in the range of 10000–15000, but also without a strict standard.

The difference between the protocols lies in their purpose: CCcam was specifically created for sharing between receivers with a proprietary packet format. Newcamd is an older protocol, often used in client-server schemes. MGcamd is a separate emulator with its own config format (mg_cfg), but as a client, it can connect to the same CCcam servers.

Port forwarding on the router and white IP

If you are just a client, you don't need to forward anything. Your receiver will initiate an outgoing TCP connection to the server by itself. The router allows outgoing connections by default.

Port forwarding and a static (public) IP are needed if you are setting up your own server and want others to connect to you. In that case, you need to forward the TCP port (for example, 12000) from the router to the receiver and either have a public IP or set up a DDNS service (No-IP, DynDNS, Afraid.org).

Port availability check: telnet and nc

The fastest way to check if the server is available on the required port, directly from the receiver via SSH:

telnet my.server.com 12000

If the connection is established (a blank screen or a set of characters appears) — the port is open. If "Connection refused" — the port is closed or the server is not listening. "Connection timed out" — the firewall is blocking or the address is unavailable.

If telnet is not installed:

nc -zv my.server.com 12000

Some internet providers block non-standard ports. If the standard port does not work, but ping to the server is available — ask your card sharing server for an alternative port (80, 443, 8080 are usually not blocked).

What to do if card sharing is not working

Diagnostics always start with the tuner, not with the logs. This is not obvious, but it will save time.

Channels do not open, but the server is Connected

First, check: are FTA channels (free, unencrypted) opening on the same transponder? If not — the problem is with signal reception, not with sharing. Check the signal level and quality in the receiver menu. A common mistake: confusing the absence of a signal with the absence of decoding.

If FTA works, but encrypted channels do not open, although CCcam Web shows CONNECTED (card) on :16001 — most likely, the required CAID is missing. Each package of channels has its own CAID (encryption system identifier) and Provider ID. If the card on the server does not cover the required CAID — you simply will not receive the key.

In OScam, this is visible in the log: the linenot found (0500:020000)means that the request for CAID 0500, Provider 020000 was not fulfilled by any reader. Compare the channel's CAID (visible in the package list or via BISS) with what is actually available on the server.

Authorization error: login failed / wrong password

In the OScam logs, this looks likelogin failed for user 'mylogin'. In CCcam on :16001, the reader will be in OFFLINE status without attempts to reconnect to another address.

Check: spaces at the beginning and end of the login/password (especially when copying via clipboard), case sensitivity (passwords are case-sensitive), correctness of the config file (in case you are editing the wrong one).

Long channel switching (high ECM time)

ECM time is the time from the moment the decryption key request is made until it is received. Normally, this is 100–400 ms. At 800+ ms, channel switching becomes noticeably slow, and at 1500+ ms, the channel may not open at all within the allotted time.

Causes of high ECM time: a physically distant server (high ping), server overload (too many clients on one card), long hop chain (the key goes through 2–3 intermediate servers). This can be reduced by choosing a server with local cards and low ping — 20–50 ms to the server gives ECM around 200–300 ms.

Freeze and pixelation on HD channels

HD channels require a stable stream of 8–18 Mbps. If SD channels work fine, but HD is freezing — the problem is likely not with card sharing. The keys are the same for SD and HD, the difference is only in the amount of data after decoding.

Check: the signal level should be above 70%, quality — above 80%. Try the same HD channel on an FTA transponder (if available) — if it freezes there as well, it's the antenna or cable. Also, freezes in the evenings while working fine during the day — a classic sign of an overloaded server during peak hours.

Another reason for disconnections every few minutes is the limit on simultaneous connections. If your account is being used by multiple clients at the same time (resold access), the server will periodically drop old connections. In the logs, this looks like disconnect + immediate reconnect with successful authorization.

How to choose a card sharing provider: criteria

I won't name specific names, but there are several parameters that immediately indicate whether it's worth paying.

Stability and uptime of the server

A decent provider specifies a specific uptime — 99%+ per month. This means no more than 7 hours of downtime over 30 days. If it just says "stable server" without numbers — consider it marketing.

A good sign is the presence of backup lines (failover). This means that if the main server goes down, the receiver automatically switches to the backup. In CCcam, this is implemented with a second C-line with the same login, in OScam — a second reader with the same group.

ECM time indicators and local cards

A provider with local cards (not reselling someone else's sharing) will give ECM time of 200–400 ms. If ECM is constantly above 700–800 ms — you are facing a chain of several retransmissions, and the stability of such a scheme is low.

Request a test access for 24–48 hours. During the test, measure ECM time in the OScam web interface (:8888) or CCcam (:16001) at different times of the day. The difference between daytime and evening readings will show how overloaded the server is during peak times.

Support for required packages and CAID

Before payment, clarify the CAID and Provider ID of the packages you need. This is not magic — the information can be found in open databases of satellite TV or in the receiver itself (the encryption system is usually displayed in the channel information). Compare with what the server actually supports.

Popular encryption systems: Viaccess (CAID 0500/0600), Irdeto (0600), Nagravision (1800/1810), Conax (0B00), Cryptoworks (0D00). The provider should clearly indicate which CAID and satellites are covered.

Trial period and technical support

No test access — a bad sign. Normal providers offer a trial without the need to pay in advance or leave card details. Technical support should answer technical questions, not just "when to pay." If the response to a question about CAID is "everything works, just set it up" — that is not support.