iCAM in OScam: configuration and connection of the protocol

If you have already figured out the basic installation of OScam and are now trying to set up exactly icam oscam — this article is for you. There will be no fluff about "what conditional access is" — only specific configs, real parameters, and an analysis of why something doesn't work. I went through this myself, so I know where people usually get lost.

What is iCAM and how does it work in OScam

iCAM is a key exchange protocol (CW) between the client and the card server. By structure, it works over TCP, transmits ECM requests, and receives back control words. Nothing fundamentally new — but there are differences in the packet format and authentication method compared to newcamd.

Support for iCAM in OScam appeared in builds starting from revision 11000+. In older binaries, the option may be present in the code but work unstably — this is important if you have a 2-3-year-old build on your receiver. Update the binary to the current version.

The place of iCAM among OScam protocols

OScam supports several protocols for readers: newcamd, cccam, cs378x, gbox, radegast, and iCAM. Each is a separate type of connection to the source. The protocol is specified in the parameterprotocol of the section[reader] in the fileoscam.server.

iCAM is more often used as a protocol on the client side — that is, OScam connects to a remote server that "provides" CW. It is less commonly found in server-server schemes.

How iCAM differs from newcamd and cccam

Newcamd is old, proven, works everywhere. But it has a fixed packet format and authentication via DES. iCAM uses a different exchange mechanism and, based on practical experience, incurs slightly less overhead per session. CСcam is a completely different story; it has a different principle of working with card sharing at the protocol level.

In practice, the difference in latency between newcamd and iCAM is minimal — a few milliseconds. The choice of protocol is usually dictated by the source: whatever it supports, you use. If the source provides iCAM — you configure iCAM.

When iCAM is used in real schemes

I most often encounter icam oscam in schemes where the source is a specialized server with specific CAID. It is also sometimes used in chains: physical card → local OScam server → client via iCAM. If the source supports multiple protocols, it sometimes makes sense to try iCAM instead of newcamd and compare ECM time in the log.

Configuring iCAM in OScam configuration files

OScam configuration files are located in different places depending on the build and platform. On Enigma2 receivers, it is most often/etc/tuxbox/config/oscam/ or/usr/keys/. On pure Linux — usually/etc/oscam/ or/var/keys/. You can determine the exact path with the command:

ps aux | grep oscam

In the output, there will be a key-c with the path to the config directory. This is more accurate than any assumptions.

The reader section in oscam.server

All connections are described in the fileoscam.server. For icam oscam, the section looks something like this:

[reader]
label         = my_icam_reader
protocol      = icam
device        = yourserver.example.com,15000
user          = mylogin
password      = mypassword
caid          = 1830
ident         = 1830:000000
group         = 1
reconnecttimeout = 30

Let's break down each line:

• label — arbitrary name of the reader, displayed in the web interface and logs. Use something understandable.
• protocol = icam — this is the key difference from other readers.
• device — host and port of the source separated by a comma. No spaces around the comma — this is a common typo.
• user / password — credentials provided by the source.
• caid — conditional access system identifier. It needs to be known exactly — the source will tell you.
• ident — formatCAID:provider. If you don't know the provider — you can try000000, but it's better to clarify.
• group — group to which the reader is attached. It must match the group inoscam.user and mapping.
• reconnecttimeout — timeout in seconds before reconnecting after a disconnection.

Protocol parameters and default port

iCAM does not have one fixed "standard" port — it is specified in thedevice line and agreed upon with the source server. In practice, ports in the range of 10000–20000 are encountered. The specific value is always indicated by the one providing access. If the port is not specified — the reader will not start.

Additionally, you can specifyecmwhitelist andecmcache, but this is not necessary for initial connection. First, achieve a basic connection, then tune it.

Editing oscam.conf and oscam.user

Inoscam.conf in the section[global] make sure that logging is enabled and the debug level is set. For initial setup, I setloglevel = 6 — this is a detailed output without any very low-level junk:

[global]
logfile       = /tmp/oscam.log
loglevel      = 6
cwlogdir      = /tmp/cw

Inoscam.user you need to add or check the user section, where the group matches the reader's group:

[account]
user          = localclient
password      = clientpass
group         = 1
caid          = 1830

If the groups do not match — the reader exists, but the client is not bound to it and ECM requests will not reach the source.

Example of a working config with comments

Minimal working template foroscam.server, which can be copied and adapted:

[reader]
label            = icam_test
protocol         = icam
device           = 192.168.1.100,12000
user             = testuser
password         = testpass
caid             = 0604
ident            = 0604:000000
group            = 2
reconnecttimeout = 20
log              = /tmp/oscam.log

After editing the files — a restart is mandatory. On Enigma2:

/etc/init.d/oscam restart

Or viakill -1 $(pidof oscam) for a soft restart with re-reading of configs. On systems with systemd:systemctl restart oscam.

Permissions on config files:oscam.server must be readable by the user under which OScam is running. Usually, it is enough tochmod 644.

Checking the connection and reading logs

After starting, the first thing to do is to look at the log. Not in the web interface — in the log. The web interface shows the status, but the log explains the reason.

tail -f /tmp/oscam.log

This is your main tool when debugging icam oscam. Keep the terminal open and watch what happens in real-time when switching channels.

Enabling detailed logging in oscam.conf

If there is almost nothing in the log — most likely,loglevel is set too low. Values range from 0 (minimum) to 9 (maximum). For diagnostics, set it to 6 or 7. On a production server, after debugging, it can be lowered to 3-4, otherwise, the log grows quickly.

The parametercwlogdir allows saving control words in separate files — useful when suspecting an incorrect CW. But by default, it is disabled, and it is not needed for basic diagnostics.

Web interface (httpport) and reader status

Inoscam.conf the section[webif]:

[webif]

Open the browser athttp://device_address:8888 and see the statuses of the readers. Possible states:

• connected — there is a connection, the reader is working.
• online — the reader is online, but there has been no ECM yet.
• off / CONNECT ERROR — there is a connection problem.

A green status in the web interface is a good sign, but not a guarantee. The channel may not open even with a green reader — the reasons will be discussed below.

Reading ECM lines and response time

In the log, a successful ECM line looks something like this:

2026/06/05 14:23:11 c (ecm) icam_test: found (1 ms) by icam_test [0604/000000/1234]

Here1 ms — is the response time. A normal value for a good source is up to 100-150 ms. If you see 500+ ms — the source is slow or overloaded. With values above the ECM timeout (usually 3000-5000 ms by default), the channel will not open, even if the CW is correct.

A line withnot found orrejected — the reader responded, but the key was not found. A line withtimeout — the reader did not respond in time at all.

Frequent iCAM errors and their resolution

Most problems with icam oscam fall into four categories. Here they are in order from the most common.

Reader in CONNECT ERROR status

The most obvious reason is an incorrect host or port in thedevice line. Check three times: is there an extra space, is the comma correct (not a semicolon, not a colon).

The second reason is that the source is offline or unavailable. Check availability from the device:

telnet yourserver.example.com 15000

If telnet does not connect — the problem is on the network or source side, not in the OScam config.

The third reason is the firewall. On the OScam server itself, checkiptables -L -n. If the incoming port is blocked — this explains the CONNECT ERROR in local setup. When connecting through NAT, port forwarding is needed on the router: external port → device IP → the same port.

ECM passes, but the channel does not open

This is worse — the reader works, CW comes, but there is no picture. First, look in the log: what is the ECM time? If it is above 3000 ms — most likely, the decoder did not receive the CW in time. Solution: increaseecmtimeout inoscam.conf or find a faster source.

Another option is an incorrect CW. The log may showfound, but the CW is actually incorrect. Enablecwlogdir and check the saved keys — they should be 16 bytes (32 hex characters), non-zero.

Mismatch caid/ident

This is a silent error — the reader connects, but ECM requests are not routed to it. In the log, you will seeno matching reader or complete silence when switching channels.

The correct CAID and ident values can be obtained from the source or checked through the OScam web interface in the card information section if there is a local reader. A typical mistake: CAID is specified as1830, while the actual channel uses183000 — these are different values. OScam accepts CAID in a 4-digit hex format.

Port and firewall issues

On Enigma2 receivers, I encounter a situation: OScam works, but the port is not listening from the outside due to the built-in firewall of the image. The command to check:

netstat -tlnp | grep oscam

If the port is not in the list — OScam did not start the required listener. If the port is on0.0.0.0 — it listens on all interfaces, the problem is with the firewall above. The rule for iptables:

iptables -I INPUT -p tcp --dport 15000 -j ACCEPT

With a dynamic IP from the source, the linedevice with the hostname (not IP) periodically stops resolving — especially if the DNS record TTL is short. In this case, thereconnecttimeout parameter within reasonable limits and monitoring the log for resolving errors will help.

Criteria for choosing a source for iCAM connection

I won't name any specific services here — it doesn't make sense because the market changes and any specific advice will become outdated in a month. It's better to explain what to look for technically.

What to look for in line stability

The main indicator is the ECM time in the log. A stable line gives a response of 50-150 ms under reasonable load. If you see jumps from 80 ms to 2000 ms — the line is unstable or the source is overloaded.

The second indicator is the frequency of reconnections. Open the log for several hours and count how many times the reader reconnected. A good line has less than 2-3 reconnections per day. If reconnections occur every 20-30 minutes — this is a junk source.

The third — uptime. A normal source has an uptime of 99%+. This is only verified through practice over several days.

Parameters to request in advance

Before setting up, you need to obtain specific data from the source:

• Host (hostname or IP)
• Port
• Login and password
• CAID and ident
• Protocol (in our case — icam)

Without this minimum, configuring icam oscam is impossible. A source that cannot provide these parameters clearly is a bad source.

Signs of an unreliable source

Several red flags from practice. The source provides one port but does not specify the exact CAID — this means they are not sure if it works. The source cannot explain why they have a specific protocol — most likely, it is a resale without technical knowledge.

Another sign — ECM time is unstable from the very beginning, in the first minutes of connection. A normal source provides predictable response time from the first seconds. If I see 1500 ms from the first ECM — it won't get better.