iCam в OScam: настройка протокола и конфигов

Если ты уже потратил пару часов на поиски «протокола iCam» и не нашёл ничего внятного — это нормально. Большинство статей по теме icam oscam либо описывают давно устаревшие версии, либо вообще путают iCam с отдельным программным обеспечением. На деле всё проще и одновременно чуть хитрее: iCam — это клиентское название для подключения по протоколу newcamd, и настраивается оно в OScam ровно так же, как обычный newcamd-ридер. Ниже — разбор от первой строчки конфига до работающего ECM.

Что такое iCam и его место среди протоколов OScam

iCam не является отдельным протоколом в техническом смысле. Это клиентская реализация (и одновременно маркетинговое название линии) на основе newcamd357 — одного из вариантов протокола newcamd с 14-байтным DES-ключом для шифрования обмена. В OScam нет отдельной опции protocol = icam. Всё, что нужно — прописать protocol = newcamd в секции [reader], и это будет работать.

Путаница возникает потому, что поставщики линий часто называют свой продукт «iCam-линией» или «iCam-сервером», что создаёт впечатление какого-то особого формата. Но под капотом — стандартный newcamd-сокет с согласованием ключа при подключении.

iCam как разновидность newcamd (порт-протокол 525/newcamd357)

Классический newcamd работает на портах из диапазона 510–560, хотя конкретный порт всегда задаёт серверная сторона. Для iCam-линий чаще всего встречаются порты 525, 527, 530 — но это не стандарт, а просто распространённая практика. Точный порт ты получаешь от поставщика вместе с логином, паролем и DES-ключом. Без этих данных гадать по форумам бессмысленно.

Формат newcamd357 отличается от старого newcamd509 длиной ключа: 14 байт против других вариантов. Если ключ указан неправильно — соединение установится, но CW (Control Words) расшифровываться не будут. Об этом подробнее в разделе про ошибки.

Отличие iCam от CCcam и mgcamd по логике обмена ECM/EMM

CCcam использует собственный бинарный протокол с другим форматом handshake и иначе организованным пулом карт. mgcamd — ещё одна реализация с немного другой логикой маршрутизации запросов. Newcamd (и iCam как его вариант) работает по схеме «один ридер — один сервер»: клиент подключается напрямую к серверу, сервер авторизует его и начинает отвечать на ECM-запросы.

В OScam это означает, что каждая iCam-линия прописывается как отдельный [reader] в oscam.server. Нет никакого общего пула как в CCcam-клиенте — только точка-точка.

Когда имеет смысл использовать именно iCam-ридер

Если поставщик выдаёт тебе данные именно в формате newcamd/iCam — выбора нет, используешь его. Но если есть возможность выбрать протокол, newcamd хорош для случаев, когда нужна предсказуемая задержка: он не переусложнён, и ECM time обычно получается ниже, чем у некоторых CCcam-реализаций с большими пулами карт.

Настройка ридера iCam в oscam.server

Файл oscam.server — основное место, где прописываются все ридеры. В зависимости от сборки OScam и образа ресивера путь к нему может быть разным:

• /etc/tuxbox/config/oscam.server — стандартный путь для большинства образов Enigma2 (OpenATV, OpenPLi, DreamElite)
• /var/etc/oscam.server — встречается в некоторых сборках для VU+, Xtrend
• /usr/keys/oscam.server или /var/keys/oscam.server — нестандартные пути в отдельных кастомных образах

Перед правкой обязательно проверь реальное расположение через find / -name oscam.server 2>/dev/null. Если редактируешь не тот файл — изменения просто игнорируются, и потом долго ищешь где ошибка.

Полная секция [reader] с protocol = newcamd

Вот рабочий шаблон для icam oscam-ридера:

[reader]
label                         = icam_line1
protocol                      = newcamd
device                        = your.server.host,525
key                           = 0102030405060708091011121314
user                          = your_login
password                      = your_password
group                         = 1
caid                          = 0500
ident                         = 0500:041800
audisabled                    = 1
reconnecttimeout              = 15
lb_weight                     = 100

Это минимально рабочий блок. Ниже разберём каждое поле.

Параметры key, device, user, password и group

label — произвольное имя ридера. Используй латиницу без пробелов. Это имя потом видно в веб-интерфейсе.

protocol = newcamd — именно так указывается iCam в OScam. Никаких icam, newcamd357 и прочих вариантов в этом поле нет.

device — принимает хост и порт через запятую без пробелов: host,port. Если поставщик дал IP-адрес — вставляй IP. Но если у сервера динамический IP, рано или поздно соединение упадёт и не восстановится. Лучше просить DNS-имя у поставщика и использовать его — OScam переразрешит имя при переподключении.

key — 14 байт DES-ключа, записанных подряд в hex без пробелов и разделителей. Итого 28 символов. Пример: 0102030405060708091011121314. Частая ошибка — вставить ключ с пробелами (01 02 03 04...) или указать 16 байт вместо 14. OScam в таком случае может принять конфиг без ошибки, но декодирования не будет.

user / password — логин и пароль, которые выдаёт поставщик. Регистр имеет значение.

group — числовой идентификатор группы. Ридер и аккаунт в oscam.user должны принадлежать одной группе, иначе маршрутизация ECM не заработает. Можно указать несколько через запятую: group = 1,2.

Указание CAID, ident и onbad для фильтрации

caid — идентификатор системы условного доступа в hex. Например, 0500 для Viaccess, 1702 для Nagravision, 0604 для Irdeto. Если линия поддерживает несколько CAID — перечисли через запятую.

ident — уточнение до конкретного провайдера внутри CAID. Формат: CAID:ProviderID. Например, 0500:041800. Без этого OScam будет слать на ридер все ECM с нужным CAID, а сервер будет часть из них отклонять. Указание ident снижает нагрузку и ускоряет ответы.

audisabled = 1 — отключает EMM-обновления авторизации. Для большинства клиентских линий это правильно: ты не управляешь картой, только читаешь с неё CW.

Связка ридера с oscam.user и выдача каналов

Даже при правильно настроенном ридере каналы не откроются, если аккаунт в oscam.user не связан с ридером через group. Это самая частая причина ситуации «ридер CONNECTED, декодирования нет».

Совпадение group между [reader] и [account]

Файл oscam.user лежит рядом с oscam.server — в том же каталоге. Минимальный рабочий аккаунт выглядит так:

[account]
user                          = local_user
pwd                           = local_pass
group                         = 1
au                            = 1
uniq                          = 0

Значение group = 1 в [account] должно совпадать с group = 1 в [reader]. OScam использует группы как механизм маршрутизации: ECM от аккаунта идёт только в ридеры той же группы. Если группы не совпадают — ридер просто не получает запросы.

Параметры au, services и chid

au = 1 — разрешает авторизационные обновления для этого аккаунта. Для локального использования обычно нужно.

services — опциональный фильтр по списку сервисов из oscam.services. Если не заполнен — аккаунт получает доступ ко всему, что отдаёт ридер.

chid — фильтр по конкретным channel ID. Редко нужен на клиентской стороне, но иногда поставщик ограничивает набор каналов на серверной стороне по CHID — тогда прописывать его здесь бессмысленно.

Проверка через веб-интерфейс OScam (порт 8888/16002)

Включить веб-интерфейс можно в oscam.conf (путь тот же каталог, что и остальные конфиги):

[webif]
httpport                      = 8888
httpuser                      = admin
httppwd                       = admin
httprefresh                   = 10

После перезапуска OScam открывай http://IP_ресивера:8888 в браузере. В разделе Readers ищи свой ридер по label. Зелёный статус CONNECTED с указанием карты — хорошо. Жёлтый TRYING — соединение не установлено. Красный — ошибка аутентификации или недоступный хост.

ECM time (время ответа на запрос декодирования) в норме — от 50 до 500 мс. Если видишь тысячи миллисекунд или таймауты — проблема либо в сети, либо на стороне сервера.

Отладка подключения iCam: чтение логов и статусов

Веб-интерфейс показывает агрегированный статус. Для реальной диагностики нужен лог. По умолчанию он или пишется в файл, или вообще отключён — зависит от конфига.

Включение debug-уровня в oscam.conf (loglevel, cwlogdir)

В секции [global] файла oscam.conf:

[global]
logfile                       = /tmp/oscam.log
loglevel                      = 64
maxlogsize                    = 500
cwlogdir                      = /tmp/cw

Для диагностики подними loglevel до 255 временно — это включает всё, включая debug newcamd-соединений. После решения проблемы верни на 64 или 0, иначе лог забьёт диск за пару часов на активном сервере.

Смотреть лог в реальном времени: tail -f /tmp/oscam.log. При подключении нового ридера icam oscam ты увидишь последовательность: попытка соединения → handshake → статус карты.

Расшифровка статусов: CONNECTED, CARD INSERTED, NO CARD

CONNECTED — TCP-соединение установлено, ключ согласован. Это ещё не означает, что карта есть и работает.

CARD INSERTED — сервер сообщил о наличии карты. Хороший знак.

NO CARD — соединение есть, но сервер не сообщает о карте. Либо карта физически не вставлена на сервере, либо для твоего аккаунта она не открыта.

В логе при корректном подключении увидишь строки типа:

reader icam_line1 [newcamd] connecting to your.server.host (port 525)
reader icam_line1 [newcamd] connection established
reader icam_line1 [newcamd] card system: Viaccess, CAID: 0500

Анализ ECM time и кодов ответа (rc) в логе

Каждый ECM-запрос в логе сопровождается кодом rc (reason code). Основные значения:

• rc=0 (FOUND) — CW получен успешно, канал должен открыться
• rc=1 (CACHE1) — ответ взят из кэша
• rc=2 (CACHE2) — ответ из второго уровня кэша
• rc=3 (READER) — ответ пришёл от ридера
• rc=4 (NOT FOUND) — ридер не смог расшифровать ECM
• rc=7 (TIMEOUT) — ридер не ответил вовремя
• rc=E (ERR) — ошибка на стороне ридера

Если видишь постоянные rc=4 — скорее всего CAID/ident не совпадает с тем, что реально отдаёт сервер. Rc=7 — проблема с задержкой или фаерволом.

Типичные ошибки и что НЕ работает

Пройдёмся по граблям, на которые наступает большинство при первой настройке icam oscam.

Неверный DES-ключ: connect есть, decode нет

Это самая коварная ситуация. Newcamd-протокол устроен так, что handshake проходит успешно даже с неверным ключом — соединение устанавливается, статус CONNECTED появляется. Но все CW будут зашифрованы неверно, и OScam просто не сможет их расшифровать. В логе при этом никакой явной ошибки нет — просто нет успешных ECM.

Проверяй ключ тщательно. Распространённые форматы, которые НЕ работают в поле key:

• 01 02 03 04 05 06 07 08 09 10 11 12 13 14 (с пробелами)
• 01:02:03:04:05:06:07:08:09:10:11:12:13:14 (с двоеточиями)
• 16 байт вместо 14 (32 символа в hex вместо 28)

Правильно: 01020304050607080910111213 — 28 символов, без разделителей. Буквы в hex могут быть в любом регистре.

Конфликт CAID/ident и фильтрация на стороне сервера

Бывает, что поставщик линии предоставляет доступ только к части CAID или только к определённым провайдерам внутри CAID. Если в oscam.server прописать caid = 0500, а сервер реально отдаёт только 0500:041800, то запросы для других провайдеров в рамках Viaccess будут уходить на ридер и возвращаться с rc=4.

Решение — уточнять ident до реального набора от поставщика. Это и снизит нагрузку, и уберёт мусорные ответы из лога.

Ещё один кейс — несколько iCam-ридеров с одинаковым CAID. OScam будет балансировать между ними, и если один из них медленнее или нестабильнее, будут фризы. Настрой lb_weight: для более быстрого ридера поставь выше (например 200 против 100), и OScam будет отправлять на него больше запросов.

Проблемы с фаерволом и NAT на нестандартном порту

Если ридер застрял в статусе TRYING и никуда не двигается — первым делом проверяй исходящий порт. На многих домашних роутерах и у некоторых провайдеров нестандартные порты (525, 527 и подобные) могут быть заблокированы.

Быстрая проверка с Linux-сервера или ресивера: telnet your.server.host 525 или nc -zv your.server.host 525. Если соединение не устанавливается — проблема на уровне сети, OScam здесь ни при чём.

На ресиверах за NAT иногда нужно явно разрешить исходящий трафик в iptables. Проверь: iptables -L OUTPUT -n. Если там есть жёсткие политики DROP для исходящего — добавь правило для нужного порта.

И отдельно про динамический IP сервера: если поставщик выдал тебе IP-адрес напрямую, а не DNS-имя — при смене IP у поставщика соединение упадёт и не восстановится, пока ты вручную не обновишь device в конфиге. Проси DNS-имя или договаривайся о статическом IP.