'%3E%3Cpath d='M0,0 v30 h60 v-30 z' fill='%23012169'/%3E%3Cpath d='M0,0 L60,30 M60,0 L0,30' stroke='%23fff' stroke-width='6'/%3E%3Cpath d='M0,0 L60,30 M60,0 L0,30' clip-path='url(%23t)' stroke='%23C8102E' stroke-width='4'/%3E%3Cpath d='M30,0 v30 M0,15 h60' stroke='%23fff' stroke-width='10'/%3E%3Cpath d='M30,0 v30 M0,15 h60' stroke='%23C8102E' stroke-width='6'/%3E%3C/g%3E%3C/svg%3E)
How to connect card sharing: setting up CCcam and OScam
If you want to connect card sharing on your receiver and already have line data from the server — half the work is done. The rest comes down to correctly entering the line in the config, restarting the emulator, and ensuring that the port is not blocked. Below are specific paths, commands, and typical errors, without fluff.
What you need to connect card sharing
Before diving into the configs, make sure you have everything necessary. A missed item from this list — and then you spend half an hour wondering why the channel won't open.
Compatible receiver or set-top box on Enigma2
The overwhelming majority of modern satellite receivers running Enigma2 are suitable without question: Vu+, Dreambox, GigaBlue, Formuler, Xtrend. OpenATV 7.x, OpenPLi 9.x, and OpenViX firmware support CCcam and OScam out of the box via the softcam manager. The tuner must support DVB-S2 for most current satellite packages.
Old Enigma2 firmware — for example, OpenATV 6.2 — is sometimes incompatible with current builds of CCcam 2.3.x or OScam 11.x. If the emulator does not start at all after installation, the first thing to check is the firmware version.
Access data (N-line or C-line)
The server provides either a C-line for the CCcam protocol or an N-line for newcamd. They look different and are entered into different emulators. C-line starts withC:, N-line — withN:. More about this in the section on CCcam and FAQ.
Stable internet and port forwarding
The minimum channel speed for normal decoding is from 1 Mbps, but stability and ping are more important. If your receiver acts as a client (outgoing connection to the server), a public IP is not needed — regular internet access is sufficient.
Port forwarding is only needed if you are sharing cards with other clients. An important point: some providers use CGNAT — in this case, port forwarding is physically impossible without changing the tariff or using a VPN tunnel. If your provider uses CGNAT, sharing through a home receiver will not work.
Choosing a protocol: CCcam or newcamd
CCcam is the de facto standard, most servers provide C-line. Newcamd is older, used less frequently, but still found with some operators. OScam can work with both protocols simultaneously, making it a more flexible client.
Connecting via CCcam: configuring the config
CCcam is the most common way to connect card sharing for beginners. The config is minimalist, one line solves everything.
Installing CCcam on Enigma2
On most OpenATV and OpenPLi firmware, CCcam is installed through the menu:Menu → Settings → System → Softcam Manager. Select CCcam, install, activate. Or via telnet/SSH:
opkg install enigma2-plugin-softcams-cccamAfter installation, the binary is located at/usr/bin/CCcam, the config — at/usr/keys/CCcam.cfg (OpenATV) or/etc/CCcam.cfg (some other builds). Before entering anything, make sure where the file is located:
find / -name "CCcam.cfg" 2>/dev/nullStructure of the CCcam.cfg file
The basic config looks like this:
DESCRIPTION: My CCcam clientMost parameters can generally be left at their default values. The main thing is to correctly enter the server line.
Writing C-line and string parameters
C-line format:
C: hostname port username passwordFor example:
C: share.example.com 12000 user123 pass456Port 12000 is standard for CCcam, but the server can specify any other. The line is taken from the email or personal account of the server as is — no need to add or change anything. Multiple servers — multiple C: lines in the config, one per line.
If the server issued a line with additional parameters likeno oryes at the end — these are encryption and resolver flags. Leave them as they are.
Restarting the service and checking the status
After changing the config:
/etc/init.d/softcam restartOr directly:
killall CCcam&& sleep 2&& CCcam&The CCcam web interface is available athttp://[receiver-IP]:16001. In theServer section, you can see the list of connected servers, their status (connected/disconnected), number of hops, and number of available shares. If the server showsconnected and hops 1 — everything is fine. Hops 3-4 and above — a signal that the card came through a long chain of resolvers.
Connecting through OScam: files and protocols
OScam is more complex to configure, but significantly more flexible. It can work simultaneously with CCcam servers, newcamd, and local cards — all through a single config.
Key files: oscam.conf, oscam.server, oscam.user
OScam configs are located in one of the paths:
/etc/tuxbox/config/oscam//var/etc/oscam//usr/keys/oscam/
To find out the exact path on your firmware:
oscam --help | grep configThree main files:oscam.conf — global settings and web interface;oscam.server — description of readers (servers/cards);oscam.user — users, if OScam shares cards with other clients. File permissions should be restricted:
chmod 600 /etc/tuxbox/config/oscam/oscam.serverThis is not paranoia — the OScam web interface does not require authentication by default, and if it is accessible from the outside, configuration files with passwords become public.
Configuring newcamd and cccam client in oscam.server
To connect to a CCcam server, the section inoscam.server:
[reader]For newcamd, the format is different — an encryption key is also needed:
[reader]The keykey for newcamd is provided by the server along with the login and password — it is not something that can be invented.
If inoscam.server several readers are specified for the same CAID, OScam may give unpredictable results. The solution is to distribute them across different groups (group = 1,group = 2) and explicitly specify the priority through thecaid parameter or rules inoscam.conf.
Enabling the web interface (httpport 8888)
Inoscam.conf the section[webif]:
[webif]After this, the web interface is available athttp://[receiver-IP]:8888. Be sure to set a password — it is not set by default. If the receiver is on a home network and behind NAT, this is not critical, but it's a good habit.
Reading the log oscam.log and statuses
The path to the log is specified inoscam.conf:
[global]Monitor the log in real time:
tail -f /tmp/oscam.logReader statuses in the log:connected — connection established;CONNECTED (uppercase) — reader is authorized and ready to decode;CARDOK — the card on the server is responding normally. If you see onlyconnected withoutCARDOK — the server is responding, but the card is unavailable or there is an authorization issue.
Checking operation and why channels are not opening
Black screen after everything seems to be set up — a classic situation. Usually, the reason is one of five, and all of them can be diagnosed in a few minutes.
Checking line and hops status
In the CCcam web interface (port 16001) or OScam (port 8888), it is immediately visible whether the reader is connected. If the statusdisconnected — the problem is either with the network availability of the server or incorrect authorization data. Try from the receiver:
telnet share.example.com 12000If the connection cannot be established — the port is closed or blocked by the provider's firewall. Some providers block non-standard outgoing ports — this is especially relevant in cases of double NAT or corporate networks.
Mismatch of CAID and provider ID
The most common reason for a black screen with a working reader is that the channel's CAID is not in the list supported by the server. In the OScam log, this appears as lines like:
ECM not found for CAID 0500 PROVID 000000Check which CAIDs your server supports and compare them with what the satellite package transmits. Confirm with the server provider the list of supported operators.
Problems with ports and firewall
If the receiver is behind a home router and you want to share cards with others — port forwarding is needed. But if the receiver only receives (client), no forwarding is needed; the receiver initiates the connection outward itself.
With double NAT (receiver → home router → provider's router), port forwarding for sharing is impossible without special solutions. If the provider uses CGNAT, this is a standard situation with mobile operators and some home providers.
Local time and ECM desynchronization
This is a place that is constantly ignored. ECM requests critically depend on the correct time on the receiver. A discrepancy of more than 30-60 seconds with real time can completely break decoding — the channel does not open, although the reader is connected and the CAID matches.
The problem often arises after switching to summer/winter time — the time zone on the receiver remains old. Set up NTP in Enigma2:
ntpdate -u pool.ntp.orgOr through the menu:Settings → System → Time settings → Synchronization via NTP.
ECM time can be viewed in the OScam log — lines likeECM time: 320 ms. The norm is up to 500 ms. 500-1000 ms is acceptable, but there will be noticeable delays when switching channels. More than 1000 ms guarantees freezes, either due to an overloaded server or a long chain of resolvers.
How to choose a card sharing provider: criteria without names
When you want to connect card sharing and not guess the server — you need to look at specific technical indicators, not marketing promises.
Stability of uptime and ECM response time
ECM time is the main indicator of server quality. A good server with local cards gives 100-300 ms. If the test access shows a stable 600+ ms — most likely, the card is coming through several levels of resolvers, and during peak hours there will be freezes.
Server uptime below 99% per month is already noticeable in practice. More than 7 hours of downtime per month during prime time viewing means real losses.
Support for necessary CAIDs and packages
Before payment, make sure that the server supports the specific CAIDs of the operators you need. Ask for a list of CAIDs or check during the test access. For most European satellite packages, CAIDs are known and easily checked through satellite databases.
Local cards vs resolvers
A local card on the server = hops 1 in CCcam. A resolver of someone else's card = hops 2 and above. The more hops, the longer the chain: your request goes through several servers, and each adds delay.
A server with hops 3-4 on average is a resolver of a resolver. Such servers are cheaper, but under load at any link in the chain you will have freezes. A server with hops 1 is a local card, which is what you should be looking for.
Trial period and technical support
A normal provider gives test access for 24-48 hours. During this time, you can check the ECM time on the necessary channels, hops in the web interface, and stability in the evening (peak load is usually 19:00-23:00).
The response speed of support is no less important — if the server goes down on Friday evening, and support responds on Monday, that's a problem. Check the response time even at the testing stage.
What is the difference between C-line and N-line?
C-line is a line for the CCcam protocol, written inCCcam.cfg or in the section[reader] OScam with the parameterprotocol = cccam. Format:C: hostname port username password. N-line is a line for the newcamd protocol, format:N: hostname port username password key, where key is a 14-byte encryption key, provided with access. In OScam, N-line is written as a separate reader withprotocol = newcamd. Writing C-line in the newcamd client config and vice versa will not work.
What port is used for card sharing?
The port is set by the server, not the client. For CCcam, 12000 is most commonly used, but 10000, 15000, 17000, and any others can be found. There is no single standard for newcamd. The port is always specified in the access line provided by the server. If the receiver acts as a client — port forwarding on the router is not needed. If you are sharing cards — you need to forward the port on which CCcam or OScam is listening (by default, CCcam listens for incoming clients on 12000).
Why does the channel take a long time to open or freeze?
Three main reasons: high ECM time, a large number of hops, overloaded server. ECM time is visible in the OScam log — linesECM time: XXX ms. The norm is up to 500 ms. If it is consistently more than 800-1000 ms — the server is either overloaded, or the card is coming through a long chain of resolvers. Another reason is a weak internet channel with high ping or packet loss. Check the ping to the server with the commandping hostname — values above 100-150 ms will already affect channel opening.
Which is better — CCcam or OScam?
For a simple connection of one server — CCcam is easier and faster to set up. OScam is better in everything else: it supports multiple protocols simultaneously (CCcam, newcamd, camd35), keeps a detailed log with ECM time, and allows flexible configuration of reader priorities by CAID. OScam can be used as a client to a CCcam server — write a reader withprotocol = cccam, and it will connect to the server via the CCcam protocol, providing all the flexibility of OScam on the client side.
Why is the correct time important on the receiver?
The ECM protocol is tied to the current time — this is part of the mechanism to protect against the reuse of old requests. If the clock on the receiver is off from the real time by more than 30-60 seconds, the server rejects ECM requests, and the channel does not open — meanwhile, the reader in the log shows the statusconnected, which is misleading. This often breaks after switching to summer or winter time. It can be fixed by setting NTP:ntpdate -u pool.ntp.org or through the Enigma2 menu in the time settings section.
Is it possible to connect card sharing without a white IP?
Yes, no problem — if the receiver works only as a client (connecting to the server). In this mode, the receiver initiates the outgoing connection itself, and a white IP is not needed. A white IP or port forwarding is only required if you want to share cards with other clients, that is, if the receiver itself acts as a server. If the provider uses CGNAT — port forwarding is fundamentally impossible without additional solutions (VPN tunnel, static IP service from the provider).
Practical checklist for smooth viewing
Even the best CCCam or OSCam line needs two or three simple preparations. Update your receiver firmware, reset the ECM cache once a week and keep 15–20% free space on the USB stick or internal flash so that the reader can store keys without delays.
When tuning a dish, aim for MER/BER reserve: a two‑degree offset or a loose F‑connector often causes the “freezing” that users blame on cardsharing. Keep a short patch cord to test alternative routers, and save two profiles in OSCam — one for TCP, one for UDP — so you can switch instantly if your ISP starts filtering a protocol.
Utgard.tv monitors each hub 24/7, but you can speed up diagnostics by keeping a short log of your receiver actions. Note the time when you changed the channel, which CAID was active and whether you used Wi‑Fi or Ethernet. This tiny “journal” helps engineers reproduce your environment in the lab and return with a solution in minutes instead of hours.
- Keep two line slots enabled: if the first server hits a maintenance window, the second one instantly takes over without re-entering credentials.
- Run a monthly speed and latency test. Stable 1–2 Mbps with ping <80 ms is enough for SD/HD, but if jitter exceeds 20 ms, switch the router to wired mode.
- Save the Utgard.tv status page and Telegram bot @utgard_tv_bot to bookmarks — they publish maintenance notices before SEMrush or uptime monitors raise alerts.