ICam setup: configuration and connection of OScam

If you have already set up OScam and connected the source, but the channels still do not open — the problem is most likely in the icam settings. This is where most people get stuck: the parameters look similar to newcamd or camd35, but work differently, and one incorrect line can bring down the entire reader. Let's break it down step by step, without fluff.

What is ICam and why is it needed in conjunction with OScam

Purpose of ICam (Internet Cam) and its role in the chain

ICam is a protocol for transmitting ECM requests over the internet, designed for specific packages with a non-standard conditional access system. In fact, it is a client-server architecture: the receiver sends an encrypted ECM packet to a remote server, which decodes the CW (Control Word) and returns it back. OScam acts as a proxy between the tuner and the remote ICam server.

The protocol is tailored for situations where standard newcamd or CCcam is insufficient — most often, these are packages with specific CAIDs that require local processing of some requests on the receiver's side before sending.

How ICam differs from standard newcamd/CCcam clients

Newcamd operates on a proven scheme: the receiver connects to the server, sends ECM, and receives CW. ICam adds another layer — it has its own authentication system and a different packet structure. For example, ICam requires an exact match not only of CAID but also of ident (provider identifier within CAID), otherwise the server simply will not return a response, and OScam will silently show a timeout.

Another difference is that keepalive works differently. The ICam connection does not reconnect immediately upon losing keepalive, and with a short timeout, you can experience periodic drops that appear as a freeze of the picture for 3–5 seconds.

When ICam is really needed and when it is excessive

ICam is needed if the source explicitly requires this protocol — this is usually specified in the connection data. If you have a choice between newcamd and ICam from one source — choose newcamd. It is easier to debug, has lower overhead, and most problems with it are resolved faster. Use ICam only where it is the only option.

Where the configs are located and which files to edit

Paths to the files: /etc/tuxbox/config/oscam/ and /var/keys/

On Enigma2 receivers, the standard path to OScam configs is/etc/tuxbox/config/oscam/. There are three key files:oscam.conf (global settings),oscam.server (readers) andoscam.user (users for incoming connections). Keys for some systems are stored separately in/var/keys/ or/usr/keys/ — it depends on the firmware.

An important nuance: on different Enigma2 firmwares, the paths may vary. OpenPLi and OpenATV usually keep configs in/etc/tuxbox/config/oscam/, while some DreamOS or VTi builds may use/etc/oscam/. If you are not sure — check with the commandfind / -name "oscam.conf" 2>/dev/null via SSH.

Structure of oscam.server and oscam.conf for ICam

Inoscam.conf we are interested in the section[monitor] (for WebIF) and[global] with logging parameters. Inoscam.server we add a block[reader] for each ICam source. The file is read from top to bottom, each block starts with a header in square brackets.

Access rights and service restart

After editing the files, it is important to check the permissions. OScam must have read permissions for the configs:chmod 644 /etc/tuxbox/config/oscam/oscam.server. If you place key files in/var/keys/, they need 644 permissions.

Restarting depends on the firmware. On most Enigma2 systems,/etc/init.d/oscam restart orsystemctl restart oscam works. On some firmwares, OScam is launched from/usr/bin/oscam directly — then we kill the process with the commandkillall oscam and start it again. The easiest way to restart is through WebIF by clicking the Restart button in the Info section.

Step-by-step configuration of the ICam reader in oscam.server

Minimal working block [reader] for ICam

Here is a real example of a block foroscam.server that works. This is not an abstract template, but a configuration with the correct parameters for icam settings:

[reader]

Each parameter here is intentional. Let's break down what is what.

Parameters protocol, device, port, and group

protocol = icam — it must be exactly this, no alternatives. OScam supports dozens of protocols, and if you writenewcamd orcamd35 — the reader will not work with the ICam server.

device — this is the host and port separated by a comma. Typical ports for ICam: 17000, 17001, 15000, 12000. You take the specific port from your source data — there is nothing to choose from.group must match the group you assigned to users inoscam.user, otherwise the reader will not be used for decryption.

Binding caid/ident and setting ecmwhitelist

This is the most important place where people make mistakes.caid — conditional access system (for example, 09C4 for NDS Videoguard, 0500 for Viaccess, 1801 for Nagravision).ident — specific provider within this system. Format:CAID:IDENT.

How to find the correct ident? Through the OScam log when scanning the channel — there will be a line likeECM 09C4/000000/.... Or through WebIF in the Services section after trying to open the channel — OScam will show which CAID and ident it tried to decrypt.

ecmwhitelist restricts which ECM requests to send to this reader. If not set — the reader will pull all requests in a row, which creates load and can cause blocking on the server. Set explicitly:ecmwhitelist = 09C4:000000.

Checking the status of the reader in the OScam web interface (port 8888)

OScam WebIF by default hangs on port 8888 — openhttp://IP_receiver:8888 in the browser. The Readers section will show the status of each reader: Connected, Disconnected, or a specific error. If the reader shows Connected, but channels do not open — look at the ECM time in milliseconds. More than 800–1000 ms indicates a problem with the source or network.

Setting up ports, firewall, and network access

Which ports to open (TCP) and port forwarding on the router

ICam works exclusively over TCP — UDP is not needed here. Open only the port specified indevice. If the receiver is behind a NAT router, and the ICam server initiates a reverse connection (rare, but it happens) — port forwarding is needed. But in most cases, the receiver connects to the server itself, and port forwarding is not needed for outgoing TCP connections.

A separate story with CGNAT. If the provider uses Carrier-Grade NAT, you will not get a public IP at all — no port forwarding will help. Solution: ask the provider to issue a real IP (sometimes a paid option) or use VPN/tunnel.

Checking the connection via telnet/nc

Before diving into OScam configs, check if the port is accessible at all. From the receiver via SSH:

telnet your-server.example.com 17000

Or via netcat:

nc -zv your-server.example.com 17000

If telnet hangs or nc says Connection refused — the port is unavailable. Either the server is not listening on this port, or your provider is blocking non-standard TCP ports. This is a classic situation: icam settings are correct, but the internet provider is cutting traffic on non-standard ports. Check if the connection works from another connection (for example, via mobile internet).

Channel stability and keepalive

keepalive = 1 activates periodic pings to maintain the connection.reconnecttimeout = 30 — how many seconds OScam will try to reconnect when the connection is lost. Set 30–60 seconds, not less — too aggressive reconnect creates unnecessary load and can trigger protection on the server.

Another nuance: a discrepancy in system time on the receiver and server of more than 60 seconds breaks keepalive in some implementations of ICam. Check if the time is synchronized:date on the receiver and compare with the real time. If not — set up NTP:ntpd -qg or add synchronization to autostart.

Diagnostics and analysis of typical errors

Reading oscam logs: where to look and how to enable debug

Inoscam.conf in the section[global] we add:

[global]

debuglevel = 64 — this is the level for debugging readers. Level 255 — maximum, shows everything, but do not leave it constantly: on receivers with internal flash memory, a high logging level quickly kills the memory and can lead to system hang. Use only during diagnostics, then remove it or setdebuglevel = 0.

You can view the log throughtail -f /tmp/oscam.log in SSH or directly in WebIF on the Logs tab. Key lines start with a timestamp and level:2026/06/04 12:34:56 [icam_reader] ....

Error 'card not inserted' and 'CW not found'

card not inserted in the log usually means that the reader connected to the server, but the server does not see the required card or the required package. This is not an issue with your icam settings — it is a source problem. Ask for confirmation that the required CAID is active.

CW not found orECM failed — the reader could not obtain the Control Word. Reasons: incorrect CAID/ident, absence of the package at the source, server overload. In the log, look for the line withCAID — OScam will show which CAID the error occurs on.

Hanging on ECM and picture freeze

The picture freezes for 3–5 seconds, then recovers — this is a classic sign of high ECM time or occasional connection losses. In WebIF, check the ECM time column opposite the reader. Normal value — up to 300–500 ms. If consistently more than 800–1000 ms, the source is overloaded or the network is unstable.

Another reason for freezes — conflict of several readers with the same CAID. OScam starts to loop ECM requests between readers, and until it receives a response — shows noise. Check if there are two readers with the samecaid andgroup in oscam.server — spread them across different groups or explicitly specify priorities throughlb_weight.

Problems with caid mismatch and incorrect ident

In the log, it looks something like this:[icam_reader] CAID 09C4 not supported by reader orident mismatch. OScam compares the CAID from the ECM request with what is specified in thecaid parameter of the reader — if they do not match, the request is simply not sent to this reader.

How to find the correct ident: enabledebuglevel = 64, try to open the channel and look for a line in the log likeECM 09C4/00006A/.... The number after the second slash is the ident in hexadecimal format. This is what you should enter inident = 09C4:00006A.

How to choose a source and what to pay attention to

Criteria for a stable source (uptime, ECM response time)

A good source for ICam is primarily low and stable ECM time. Aim for 100–300 ms as the norm, up to 500 ms is acceptable, above that — problems start. You can only check this practically: connect the reader, open the channel of the required package, and watch the ECM time in WebIF for about 15–20 minutes at different times of the day.

Uptime is important, but stability is more important — a source that works 99% of the time without interruptions is better than one that promises 99.9% but drops out for a minute once a day during peak evening viewing.

Signs of an overloaded or unreliable server

An overloaded server is immediately visible: ECM time increases in the evening hours from 18:00 to 22:00, CW not found messages occasionally appear during a formally working connection, and keepalive starts to fail. This means that more clients are connected to the server than it can handle.

Another sign is an unstable ident. If the source's idents change periodically without warning, it indicates problems with the card source on their side. This happens less frequently, but when it does — channels stop opening for no apparent reason in your configs.

Parameters to request in advance

Before configuring anything, you need to obtain from the source: host and port, username and password, supported CAID and ident, protocol (icam, newcamd, camd35), and preferably — the maximum allowable number of simultaneous ECM requests. The last parameter is often not provided, but if you connect OScam with several tuners — you may hit the limit and receive constant refusals.

A good practice is to immediately ask for a specific list of CAIDs. If the source supports, say, 0500 and 1801, but you need 09C4 — it’s a waste of time for both parties.