iCam in OScam: protocol and config setup

If you've already spent a couple of hours searching for the "iCam protocol" and haven't found anything clear — that's normal. Most articles on the topic of icam oscam either describe outdated versions or confuse iCam with separate software altogether. In reality, it's simpler and at the same time a bit trickier: iCam is a client name for connecting via the newcamd protocol, and it is configured in OScam exactly like a regular newcamd reader. Below is a breakdown from the first line of the config to a working ECM.

What is iCam and its place among OScam protocols

iCam is not a separate protocol in a technical sense. It is a client implementation (and at the same time a marketing name for the line) based onnewcamd357 — one of the variants of the newcamd protocol with a 14-byte DES key for encrypting the exchange. In OScam, there is no separate optionprotocol = icam. All you need to do is specifyprotocol = newcamd in the section[reader], and it will work.

The confusion arises because line providers often refer to their product as the "iCam line" or "iCam server," which creates the impression of some special format. But under the hood, it's a standard newcamd socket with key negotiation upon connection.

iCam as a variant of newcamd (port-protocol 525/newcamd357)

Classic newcamd operates on ports in the range of 510–560, although the specific port is always set by the server side. For iCam lines, ports 525, 527, 530 are most commonly encountered — but this is not a standard, just a common practice. You receive the exact port from the provider along with the login, password, and DES key. Without this data, guessing on forums is pointless.

The format of newcamd357 differs from the old newcamd509 in key length: 14 bytes versus other variants. If the key is specified incorrectly — the connection will be established, but CW (Control Words) will not be decrypted. More on this in the section about errors.

The difference between iCam and CCcam and mgcamd in the logic of ECM/EMM exchange

CCcam uses its own binary protocol with a different handshake format and a differently organized card pool. mgcamd is another implementation with slightly different request routing logic. Newcamd (and iCam as its variant) operates on the "one reader — one server" scheme: the client connects directly to the server, the server authorizes it and starts responding to ECM requests.

In OScam, this means that each iCam line is specified as a separate[reader] inoscam.server. There is no common pool like inCCcam client — only point-to-point.

When it makes sense to use an iCam reader

If the provider gives you data specifically in the newcamd/iCam format — there is no choice, you use it. But if you have the option to choose the protocol, newcamd is good for cases where predictable latency is needed: it is not overly complicated, and the ECM time is usually lower than that of some CCcam implementations with larger card pools.

Configuring the iCam reader in oscam.server

The fileoscam.server is the main place where all readers are specified. Depending on the OScam build and the receiver image, the path to it may vary:

• /etc/tuxbox/config/oscam.server — standard path for most Enigma2 images (OpenATV, OpenPLi, DreamElite)
• /var/etc/oscam.server — found in some builds for VU+, Xtrend
• /usr/keys/oscam.server or/var/keys/oscam.server — non-standard paths in separate custom images

Before editing, be sure to check the actual location viafind / -name oscam.server 2>/dev/null. If you edit the wrong file, the changes are simply ignored, and then you spend a long time searching for where the error is.

Full section [reader] with protocol = newcamd

Here is a working template for icam oscam reader:

[reader]

This is a minimally working block. Below we will analyze each field.

Parameters key, device, user, password, and group

label — arbitrary name of the reader. Use Latin letters without spaces. This name will be visible in the web interface later.

protocol = newcamd — this is how iCam is specified in OScam. Noicam,newcamd357 and other variants are allowed in this field.

device — takes host and port separated by a comma without spaces:host,port. If the provider gave an IP address, insert the IP. But if the server has a dynamic IP, sooner or later the connection will drop and not recover. It’s better to ask the provider for a DNS name and use it — OScam will resolve the name again upon reconnection.

key — 14 bytes of DES key written consecutively in hex without spaces and separators. A total of 28 characters. Example:0102030405060708091011121314. A common mistake is to insert the key with spaces (01 02 03 04...) or to specify 16 bytes instead of 14. In such a case, OScam may accept the config without error, but there will be no decoding.

user / password — login and password provided by the provider. Case matters.

group — numeric identifier of the group. The reader and account inoscam.user must belong to the same group, otherwise ECM routing will not work. You can specify multiple groups separated by commas:group = 1,2.

Specifying CAID, ident, and onbad for filtering

caid — conditional access system identifier in hex. For example,0500 for Viaccess,1702 for Nagravision,0604 for Irdeto. If the line supports multiple CAIDs — list them separated by commas.

ident — specification to a specific provider within CAID. Format:CAID:ProviderID. For example,0500:041800. Without this, OScam will send all ECMs with the required CAID to the reader, and the server will reject some of them. Specifying ident reduces load and speeds up responses.

audisabled = 1 — disables EMM authorization updates. For most client lines, this is correct: you do not manage the card, you only read CW from it.

Linking the reader with oscam.user and issuing channels

Even with a properly configured reader, channels will not open if the account inoscam.user is not linked to the reader through group. This is the most common reason for the situation "reader CONNECTED, no decoding".

Matching group between [reader] and [account]

The fileoscam.user is located next tooscam.server — in the same directory. A minimal working account looks like this:

[account]

The valuegroup = 1 in[account] must matchgroup = 1 in[reader]. OScam uses groups as a routing mechanism: ECM from the account goes only to readers of the same group. If the groups do not match — the reader simply does not receive requests.

Parameters au, services and chid

au = 1 — allows authorization updates for this account. Usually needed for local use.

services — optional filter by the list of services fromoscam.services. If not filled — the account gets access to everything that the reader provides.

chid — filter by specific channel ID. Rarely needed on the client side, but sometimes the provider limits the set of channels on the server side by CHID — then specifying it here is pointless.

Check via the OScam web interface (port 8888/16002)

You can enable the web interface inoscam.conf (the path is the same directory as the other configs):

[webif]

After restarting OScam, openhttp://IP_receiver:8888 in the browser. In the sectionReaders look for your reader by label. A green status CONNECTED with card indication — good. Yellow TRYING — connection not established. Red — authentication error or unreachable host.

ECM time (response time to the decoding request) is normal — from 50 to 500 ms. If you see thousands of milliseconds or timeouts — the problem is either in the network or on the server side.

Debugging iCam connection: reading logs and statuses

The web interface shows an aggregated status. For real diagnostics, a log is needed. By default, it is either written to a file or completely disabled — depends on the config.

Enabling debug level in oscam.conf (loglevel, cwlogdir)

In the section[global] of the fileoscam.conf:

[global]

For diagnostics, raiseloglevel to255 temporarily — this enables everything, including debug newcamd connections. After resolving the issue, revert to64 or0, otherwise the log will fill the disk in a couple of hours on an active server.

View the log in real time:tail -f /tmp/oscam.log. When connecting a new reader icam oscam, you will see the sequence: connection attempt → handshake → card status.

Decoding statuses: CONNECTED, CARD INSERTED, NO CARD

CONNECTED — TCP connection established, key agreed. This does not yet mean that the card is present and working.

CARD INSERTED — the server reported the presence of a card. A good sign.

NO CARD — there is a connection, but the server does not report a card. Either the card is not physically inserted on the server, or it is not available for your account.

In the log, with a correct connection, you will see lines like:

reader icam_line1 [newcamd] connecting to your.server.host (port 525)

Analyzing ECM time and response codes (rc) in the log

Each ECM request in the log is accompanied by a coderc (reason code). Main values:

• rc=0 (FOUND) — CW received successfully, the channel should open
• rc=1 (CACHE1) — response taken from cache
• rc=2 (CACHE2) — response from the second level of cache
• rc=3 (READER) — response came from the reader
• rc=4 (NOT FOUND) — the reader could not decrypt the ECM
• rc=7 (TIMEOUT) — the reader did not respond in time
• rc=E (ERR) — error on the reader's side

If you see constant rc=4 — most likely the CAID/ident does not match what the server actually provides. Rc=7 — problem with delay or firewall.

Typical errors and what DOES NOT work

Let's go through the pitfalls that most people encounter during the initial setup of icam oscam.

Invalid DES key: connect is present, decode is not

This is the most insidious situation. The Newcamd protocol is designed so that the handshake is successful even with an incorrect key — the connection is established, the CONNECTED status appears. But all CW will be encrypted incorrectly, and OScam simply will not be able to decrypt them. There is no explicit error in the log — just no successful ECM.

Check the key carefully. Common formats that DO NOT work in the fieldkey:

• 01 02 03 04 05 06 07 08 09 10 11 12 13 14 (with spaces)
• 01:02:03:04:05:06:07:08:09:10:11:12:13:14 (with colons)
• 16 bytes instead of 14 (32 characters in hex instead of 28)

Correct:01020304050607080910111213 — 28 characters, without separators. Letters in hex can be in any case.

Conflict CAID/ident and filtering on the server side

Sometimes, the line provider only grants access to part of the CAID or only to certain providers within the CAID. If inoscam.server you writecaid = 0500, but the server actually only provides0500:041800, then requests for other providers within Viaccess will go to the reader and return with rc=4.

The solution is to clarifyident to the actual set from the provider. This will reduce the load and eliminate junk responses from the log.

Another case is several iCam readers with the same CAID. OScam will balance between them, and if one of them is slower or less stable, there will be freezes. Setlb_weight: for the faster reader, set it higher (for example, 200 against 100), and OScam will send more requests to it.

Problems with firewall and NAT on a non-standard port

If the reader is stuck in TRYING status and is not moving anywhere — first check the outgoing port. On many home routers and with some providers, non-standard ports (525, 527, and similar) may be blocked.

Quick check from a Linux server or receiver:telnet your.server.host 525 ornc -zv your.server.host 525. If the connection cannot be established — the problem is at the network level, OScam is not to blame here.

On receivers behind NAT, it may sometimes be necessary to explicitly allow outgoing traffic in iptables. Check:iptables -L OUTPUT -n. If there are strict DROP policies for outgoing — add a rule for the required port.

And separately about the dynamic IP of the server: if the provider gave you the IP address directly, not a DNS name — when the IP changes at the provider, the connection will drop and will not recover until you manually updatedevice in the config. Ask for a DNS name or negotiate a static IP.