OScam constcw: настройка фиктивной карты (2026)

Если вы уже возились с OScam и внезапно столкнулись с каналом, у которого фиксированный ключ — добро пожаловать в мир constcw. OScam constcw настройка на первый взгляд выглядит проще некуда: один блок в oscam.server, файл с ключом, готово. На практике большинство проблем возникает из-за одного неправильного байта, несовпадения группы или банального непонимания, что такое even и odd CW. Разберём всё по порядку.

Что такое constcw и когда он нужен

Принцип фиксированного контрольного слова (CW)

В DVB-шифровании контрольное слово (Control Word, CW) — это 8-байтный ключ, которым декодер расшифровывает видеопоток. Стандарт предусматривает смену CW примерно каждые 10 секунд, чередуя два ключа: even (чётный) и odd (нечётный). Один активен сейчас, другой уже передаётся в следующем ECM-пакете — чтобы переход был плавным.

Но некоторые вещатели — особенно мелкие региональные каналы или тестовые потоки — годами не меняют свой CW. Для них constcw и создан: OScam просто отдаёт заранее прописанный ключ, не обращаясь ни к карте, ни к серверу.

Отличие constcw от других типов ридеров

Ридеры типа newcamd и cccam — это сетевые протоколы, они соединяются с удалённым сервером и запрашивают свежий CW при каждом ECM. Ридер internal работает с физической смарт-картой в слоте ресивера. constcw не делает ничего из этого — он просто читает ключ из текстового файла и отдаёт его dvbapi. Никакой сети, никакой карты.

Это делает его идеальным инструментом для отладки. Хотите проверить, правильно ли работает ваш декодер, dvbapi и вся цепочка — пропишите тестовый ключ через constcw и смотрите, открывается ли канал. Если нет — проблема не в источнике CW, а где-то в конфигурации.

Типичные сценарии использования

Реально constcw используют в трёх случаях. Первый — канал действительно работает с постоянным ключом (BISS-шифрование на спортивных трансляциях, некоторые каналы PowerVu с неменяющимся ключом). Второй — локальная отладка: проверить, что dvbapi правильно передаёт CW декодеру. Третий — тестовые потоки в лабораторной среде, где вы сами контролируете шифрование.

Для платных коммерческих каналов с реальной системой условного доступа constcw не работает принципиально. CW там меняется каждые 10 секунд — никакой статичный ключ не поможет.

Формат строки constcw и структура файлов

Создание ридера в oscam.server

Все ридеры OScam живут в файле oscam.server. На Enigma2-боксах с OpenATV, OpenPLi или аналогами путь обычно такой: /etc/tuxbox/config/oscam/oscam.server или /etc/oscam/oscam.server — зависит от того, какой пакет установлен. Проверьте командой find /etc -name oscam.server 2>/dev/null.

Блок ридера для constcw выглядит так:

[reader]
label         = myconstcw
protocol      = constcw
device        = /etc/tuxbox/config/oscam/constant.cw
group         = 1
caid          = 0500

Параметр protocol в некоторых сборках OScam указывается как type = constcw — они эквивалентны, но protocol предпочтительнее в версиях после svn r11000. Параметр caid здесь опционален, но помогает OScam быстрее маршрутизировать запросы.

Путь к файлу с ключами и формат device

В параметре device указывается полный путь к файлу с ключами. Файл может называться как угодно — constant.cw, constcw.cfg, keys.txt — главное, чтобы путь существовал и OScam имел права на чтение. На большинстве Enigma2-боксов процесс oscam работает под root, так что с правами проблем обычно нет.

На ресиверах с Vix или Merlin конфиги иногда складывают в /var/keys/. Это нормально — просто укажите нужный путь в device.

Структура строки CW

Это самое важное место, где большинство и ошибается. Формат каждой строки в файле ключей:

CAID:PROVID:SID:CW_even_8байт_CW_odd_8байт

Реальный пример:

0500:000000:1234:000102030405060708090A0B0C0D0E0F

Здесь после SID идут 32 hex-символа подряд, без пробелов и без разделителя между even и odd. Первые 16 символов (8 байт) — это even CW, вторые 16 символов (8 байт) — odd CW. Если канал использует один статичный ключ, even и odd совпадают, и обе половины строки одинаковы.

Неверная длина — и OScam просто молча игнорирует строку. 30 символов вместо 32, лишний пробел в середине, табуляция после CAID — всё это приведёт к тому, что ридер будет "работать", но CW не отдаст. Проверяйте длину отдельно: echo -n "000102030405060708090A0B0C0D0E0F" | wc -c должно вернуть 32.

Регистр hex-символов не важен — 0a0b0c и 0A0B0C парсятся одинаково. Но смешивать не стоит — читать неудобно и легко ошибиться.

Где взять CAID и SID канала

CAID (CA System ID) и SID (Service ID) для нужного канала проще всего найти через веб-интерфейс OScam. По умолчанию он висит на порту 8888 — открываете http://IP-ресивера:8888 и идёте в раздел "Services" или смотрите входящие ECM-запросы в логе.

Ещё один способ — файл oscam.srvid (или oscam.srvid2), который лежит рядом с остальными конфигами. Там CAID и SID уже привязаны к именам каналов, если файл заполнен. В логе входящий ECM выглядит примерно так: ECM ch=My Channel (0500&000000/1234/AB12) — здесь 0500 это CAID, 000000 — провайдер, 1234 — SID.

Пошаговая настройка constcw в OScam

Шаг 1: добавление ридера в oscam.server

Открываем oscam.server любым редактором. На боксе удобно через nano /etc/tuxbox/config/oscam/oscam.server. Добавляем блок ридера в конец файла:

[reader]
label         = constcw_test
protocol      = constcw
device        = /etc/tuxbox/config/oscam/mychannels.cw
group         = 2

Создаём файл mychannels.cw и вписываем строку с нашим CAID, провайдером, SID и ключом. Один канал — одна строка. Несколько каналов — несколько строк, каждая в своём формате CAID:PROVID:SID:32hex.

Шаг 2: привязка группы к пользователю в oscam.user

Это место, где чаще всего застревают. Группа ридера и группа пользователя должны пересекаться — иначе OScam не будет использовать этот ридер для данного пользователя вообще.

В oscam.user у пользователя (или у аккаунта dvbapi) должна быть прописана та же группа:

[account]
user          = dvbapi
pwd           = 
group         = 1,2
au            = 1

Если у ридера group = 2, а у пользователя только group = 1 — constcw не отдаст ключ, и в логе появится no matching reader. Проверяйте это в первую очередь.

Шаг 3: проверка oscam.dvbapi

Для локального декодирования на Enigma2 нужен файл oscam.dvbapi. Минимальная рабочая конфигурация:

P: 0500:000000

Если у вас несколько CAID и несколько ридеров, порядок строк в oscam.dvbapi определяет приоритет. Если два ридера отдают CW для одного CAID, OScam пойдёт к тому, кто указан первым в oscam.server (или с меньшим приоритетом, если параметр priority задан явно).

Конфликт двух ридеров для одного CAID решается через параметр priority в блоке ридера: меньшее значение = выше приоритет. Для constcw обычно ставят priority = 0 чтобы он шёл первым.

Шаг 4: рестарт OScam и веб-интерфейс

На Enigma2: /etc/init.d/softcam restart или через меню плагина Softcam Manager. Если хотите запустить вручную с явным путём к конфигам: oscam -b -c /etc/tuxbox/config/oscam (флаг -b — фоновый режим).

После рестарта идите в веб-интерфейс на порт 8888 (или 83, если так настроено в oscam.conf в параметре httpport). В разделе "Readers" должен появиться ваш constcw_test со статусом OK. Если статус показывает ошибку или ридер вообще не виден — проверяйте синтаксис блока в oscam.server.

Отладка и решение проблем

Чтение лога: уровень debug

По умолчанию OScam пишет лог в /tmp/oscam.log (настраивается параметром logfile в секции [global] файла oscam.conf). Уровень детализации задаётся параметром debuglevel там же, или флагом -d при запуске.

Для полного дебага: oscam -b -c /etc/tuxbox/config/oscam -d 255. Это очень много текста, но зато видно всё — каждый ECM-запрос, какой ридер ответил, что за ключ вернул. Для обычной диагностики достаточно -d 64.

Параметр loghistorysize в [global] определяет, сколько строк хранится в памяти для веб-интерфейса. Поставьте 2000-5000 — так удобнее смотреть историю без ssh.

Анализ ecm.info

Файл /tmp/ecm.info — ваш лучший друг при отладке. Он обновляется каждый раз, когда OScam отдаёт CW, и показывает: какой ридер сработал, за сколько миллисекунд, сколько хопов. Выглядит примерно так:

Reader: constcw_test
CAID: 0500
Provider: 000000
Service: 1234
ECM time: 0 ms
Hops: 0

Если поле Reader пустое или показывает другой ридер — constcw не задействован. Если ECM time подозрительно большое (скажем, 800 мс) — возможно, сработал не constcw, а какой-то сетевой ридер с высоким пингом.

Ошибка "no matching reader" и несовпадение CAID/SID

Три самые частые причины этой ошибки в логе. Первая: CAID в строке файла ключей не совпадает с тем, что приходит в ECM. Смотрите лог: строка вида ECM (0650&... говорит, что канал использует CAID 0650, а не 0500 — исправьте строку в файле ключей.

Вторая причина: SID не совпадает. Канал переехал на другой транспондер и сменил SID — бывает. Третья — несовпадение group между ридером и пользователем, о чём уже говорили выше.

Ещё одна нестандартная проблема: порядок байтов. Если вы скопировали ключ из стороннего источника, где байты шли в обратном порядке (big-endian вместо little-endian или наоборот), картинка не появится. Попробуйте перевернуть каждую пару байт местами — это лечит примерно треть случаев "ключ правильный, но не работает".

Чёрный экран при правильном CW: проблема ротации

Картинка появляется на 1-2 секунды и пропадает — это классический признак ротации CW. Канал поменял ключ, OScam снова отдал старый статичный ключ из constcw, декодер получил неверный CW и потерял картинку до следующей попытки.

Некоторые провайдеры меняют "фиксированный" ключ раз в несколько дней или недель. Никаких предупреждений — просто перестаёт работать в один момент. Если вы видите, что constcw работал месяц нормально, а потом внезапно перестал — скорее всего, именно это и произошло. Обновите ключ в файле или переходите на динамический источник.

Ещё один интересный случай: есть картинка, но нет звука. Это почти всегда означает, что even CW правильный, а odd CW — нет (или наоборот). Видео и аудио могут шифроваться разными пакетами с разными ключами. Проверьте обе половины вашей 32-символьной строки.

Как выбрать рабочий источник CW, если constcw не подходит

Признаки того, что канал использует ротацию ключа

Смотрите на частоту ECM-запросов в логе. Если OScam запрашивает новый CW каждые 8-12 секунд — канал ротирует ключи. Для constcw такой канал не подходит категорически. Другой признак — в ecm.info поле ECM time постоянно обновляется, даже когда у вас нет сетевых ридеров.

BISS-шифрование с фиксированным ключом — один из немногих случаев, где constcw действительно рабочий вариант на долгий срок. Там ключ прошит на уровне оборудования вещателя и меняется редко (хотя и меняется — держите это в голове).

Критерии выбора внешнего сервера для динамических CW

Когда constcw не подходит, нужен динамический источник CW. Оценивать его стоит по конкретным метрикам, которые видны прямо в логах OScam.

ECM time — время ответа на запрос контрольного слова. Всё что ниже 300 мс — хорошо, 300-600 мс — приемлемо, выше 600 мс — будут фризы на большинстве каналов. Смотреть в ecm.info или в статистике ридера в веб-интерфейсе. Параметр hops показывает, через сколько серверов прошёл запрос: 0 — локальная карта, 1 — один сервер, больше 2 — цепочка, и latency будет расти.

Аптайм важнее, чем кажется. Сервер с ECM time 150 мс, но который падает на час каждые три дня — хуже, чем стабильный сервер с 400 мс. Смотрите статистику за несколько дней, не за час.

Протоколы newcamd и cccam как альтернатива

Для каналов с ротацией CW нужны протоколы с динамической раздачей ключей. newcamd — более старый, но надёжный протокол, работает на порту 14000 по умолчанию (хотя это настраивается). cccam — более распространённый, порт по умолчанию 12000. Оба поддерживаются OScam как тип ридера.

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

[reader]
label         = remote_newcamd
protocol      = newcamd
device        = server.example.com,14000
user          = myuser
password      = mypass
key           = 0102030405060708091011121314
caid          = 0500
group         = 1

Принципиальное отличие от constcw: при каждом ECM-запросе ридер идёт на удалённый сервер, получает свежий CW и отдаёт его декодеру. Никакого статичного файла — ключи всегда актуальные.

Частые вопросы