icam in OScam: protocol setup and config 2026

If you have already dealt with cccam and newcamd but are encountering icam for the first time — welcome to the club. The icam oscam combination raises questions even for people who have been sharing without problems for years. The protocol looks similar to newcamd, the config is almost the same, but the default settings do not work, channels do not open, or the picture freezes after 30 seconds. In this article — specific syntax, section examples, and step-by-step diagnostics.

What is the icam protocol and how does it differ from cccam and newcamd

icam is not a standalone protocol from scratch, but an extension on top of newcamd. The basic transport, DES encryption, packet structure — all the same. The difference lies in how the ECM timing is processed and how the control words (CW) are transmitted.

In classic newcamd, the server simply responds to the ECM request and provides the CW. Without time binding, without synchronization. icam adds a tunneling layer that requires the CW to arrive within a time window. If it arrives late — the decoder has already moved ahead, and the screen is black.

Origin of icam: an extension on top of newcamd

The format appeared in separate IPTV middleware builds and firmware for receivers — especially in Asian and Middle Eastern kits. Some providers intentionally use icam instead of standard newcamd to complicate unauthorized sharing. Technically, it is the same port 2222, the same DES key of 28 hex characters, but with additional session flags.

OScam supports icam specifically through the sectionprotocol = newcamd with a number of additional parameters. There is no separate protocol type in the config — it is important to understand this right away.

When is icam mandatory, and when can you get by with cccam

If the source explicitly states "icam connection" in the instructions and gives you port 2222 plus DES key — icam is mandatory. cccam will not work here because the packet structure is different. Attempting to connect via cccam to an icam source will either result in an authorization error or simply silence in the log.

If the source provides both cccam port and newcamd/icam — you can try both. In practice, cccam is easier for initial setup, but icam sometimes provides less latency and works more reliably in cascading.

Features of ECM/EMM transmission in icam

ECM (Entitlement Control Message) in icam goes through a tunnel with timestamps. If there is more than ~200 ms ping between your OScam and the source — the ECM response may be delayed. The decoder has already started the next period, while the CW is still on the way. Hence the classic symptom: the source writesfound in the log, but there is no picture.

EMM (Entitlement Management Message) in icam works similarly to newcamd — it is transmitted separately and is only needed for updating card rights. For pure sharing without a physical card, EMM is usually not needed.

Configuring the reader for icam in oscam.server

The configuration file for readers in most builds is located at/etc/tuxbox/config/oscam/oscam.server. In Enigma2 images, it is often found at/var/keys/oscam.server. Some custom builds place everything in/etc/oscam/oscam.server — check where your binary starts viaps aux | grep oscam.

Here is a working section[reader] for connecting icam oscam:

[reader]

Each parameter here is intentional. Let's go through the key ones.

Parameter protocol = newcamd and flags for icam

Yes, it is indeednewcamd, not "icam". OScam does not have a separate value for icam in the fieldprotocol. Some OScam builds from 2023–2026 add the parameternewcamd_extended = 1 — this enables an extended timing processing mode needed for icam. If you have a recent build, try adding this line.

There is also the parametericam = 1 in experimental OScam patches. If your build supports it — you will see it in the helposcam --help. The standard upstream OScam (SVN r11759 and newer) does not include this flag.

Specifying des key, ports, and caid

The DES key is 28 hex characters (14 bytes). You get it from the source along with the login and password. A common mistake: copying the key with spaces or separators. The config should have a continuous string without spaces.

The default port is 2222, but the source may use any other: 10000, 15000, 20000. Always take the port from the source instructions, do not guess. CAID depends on the conditional access system — for Irdeto it is usually 0600, for Viaccess 0500, for Nagravision 1800. Incorrect CAID = the reader will connect, but CW will not come.

The ecmwhitelist and cccmaxhops parameters for stability

ecmwhitelist — this is a filter: OScam will send ECM only for the specified CAID and ident. Without it, the system sends requests for all CAIDs, which creates unnecessary traffic and slows down the response. This is especially important for icam due to timing.

cccmaxhops = 2 limits the cascade depth. If the source itself takes the card from multiple levels, this parameter prevents delays from growing. For icam, I recommend keeping the value no higher than 3.

Configuring account and profile in oscam.user for sharing icam

If you are sharing further (to your receiver or client config), a section is needed inoscam.user. The file is in the same location asoscam.server —/etc/tuxbox/config/oscam/oscam.user.

[account]

The [account] section and binding to group

The most common mistake when setting up icam oscam is the mismatch ofgroup in[reader] and[account]. If in the readergroup = 1, but in the accountgroup = 2 — OScam simply does not link them. The log will showno matching reader or complete silence. The group must match.

Parameterau = 1 allows the transmission of EMM to the client. If there is no physical card, it can be left off; it will only add traffic.

Parameters au, betatunnel, and caid mapping

betatunnel is the on-the-fly conversion of CAID. Suppose the source provides CW for the Irdeto system (CAID 0600), while your receiver expects Viaccess (0500). The linebetatunnel = 0600:0500 tells OScam: "take what came as 0600 and give it to the client as 0500." Without this conversion, the receiver will receive CW but will not understand it — black screen whenfound is in the log.

This is one of those moments that most instructions are silent about. I spent several hours before I understood: the source gives, OScam receives, but the receiver still does not open — precisely due to the CAID mismatch.

Access control through services in oscam.services

The file/etc/tuxbox/config/oscam/oscam.services allows you to restrict which SIDs (channel identifiers) are available to the account. Example:

[mypackage]

If icam works on one package of channels but not on another — most likely, the problem lies here. Either the SID is not listed in the services section, or the section itself is not linked to the account through theservices parameter.

Diagnostics and solutions for typical icam problems in OScam

The first tool is the live log. We start:

tail -f /var/log/oscam.log

Or we look through the OScam web interface on port 8888 (or 16002 in some builds) — there is a Live Log tab. It is based on the log lines, not on "feelings," that the problem should be diagnosed.

Channels do not open: checking CW and ECM time

Look for two lines in the log for each ECM request. A line likefound (7 ms) means: CW received, response time 7 ms. A linenot found ortimeout means there is no response.

If it saysfound but there is no picture — this is a classic icam problem. CW arrived with a delay or unsynchronized timing. Check the ping to the source:ping your.server.host. More than 150 ms is already a risk. More than 250 ms — almost guaranteed problems with icam.

Also check that the port is available:

netstat -tlnp | grep 2222

If the port is occupied by another process (for example, a simultaneously running instance of the newcamd daemon) — the connection will be rejected or hang.

Freezes and FreezeTV: tuning ecm timeout and lb

Freezes on HD/UHD channels while SD works normally — is a separate story. HD channels have a shorter ECM period, and the time allowance is smaller. If the ecm timeout is set too low — OScam does not have time to receive a response and switches to the next reader (or does not decode at all).

In the file/etc/tuxbox/config/oscam/oscam.conf in the section[global]:

[global]

ecmtimeout = 3500 — this is 3500 ms. For a stable source, you can keep it at 2000–2500, for an unstable one — raise it to 4000. Above 5000 usually does not help, it only adds delay when switching channels.

lb_mode = 1 enables the load balancer.lb_nbest_readers = 2 indicates to keep the two best readers active based on response speed. If you have one icam reader — these parameters are less critical, but do not hurt.

Errors in the log: no matching reader, group mismatch

no matching reader — OScam did not find a reader capable of responding to this ECM. Reasons: incorrect CAID in the reader, group mismatch, reader not connected (check the status in the web interface).

group mismatch directly states: the group parameter in[reader] and[account] is different. It can be fixed in 30 seconds — just set the same number and restart OScam with the commandoscam -r 2 (or through the web interface, the Restart button).

invalid des key — the key is of incorrect length or contains invalid characters. Count the number of characters: it should be exactly 28.

How to choose an icam source: what to look for technically

Choosing a source is not about trusting advertising texts, but about the numbers in the OScam log. Any source can be objectively evaluated after 10–15 minutes of operation.

Stability of ECM time and uptime of the node

A good source for icam oscam should provide ECM time consistently below 100 ms, ideally 20–50 ms. Check the log: if the time jumps from 30 ms to 800 ms — this is an unstable source, there will be freezes.

Uptime is checked over several days of observation. Look in the OScam web interface in the Readers section — it shows the number of successful/failed requests. If failed is more than 5% of total — something is wrong.

Matching caid/provider with your equipment

The source must provide exactly the CAID that your receiver understands. The required CAID can be found through the OScam log — when the receiver makes an ECM request, the log shows which CAID it is using. Compare it with what the source provides.

If the CAID does not match, but the difference is known — you can apply betatunnel (described above). But it is better when the source immediately provides the correct CAID without conversion.

Signs of an unreliable source

Several red flags that are visible directly in the log:

• ECM time constantly > 500 ms — the source is overloaded or geographically far away
• Frequentconnection lost in the reader — unstable server or network problems on the source side
• CWfound, but the picture periodically disappears — a synchronization problem specific to icam
• One package works, the other does not — filtering on the source side that you were not told about

If the source provides a stable ECM time, a low percentage of failed requests, and the correct CAID — that's a good sign. Everything else is marketing.