OScam no cw: причины и решение проблемы декодирования

Если вы ищете OScam: no cw решение — значит сервер запущен, клиент подключён, ECM-запрос уходит, но канал не открывается. Строчка в логе выглядит безобидно, но за ней может скрываться с десяток разных причин: от опечатки в caid до мёртвого source на другом конце. Разберём всё по порядку — от разбора лога до реальных правок в конфиге.

Что означает «no cw» в логах OScam

ECM (Entitlement Control Message) — это зашифрованный пакет от тюнера, который уходит на reader в поисках контрольного слова (CW, control word). Если reader получил ECM, отправил его на источник, но ответ пришёл пустым — в логе появляется no cw. Не «нет карты», не «отказ» — именно пустой ответ.

Это важно: no cw означает, что цепочка до источника работает, но сам источник либо не может, либо не хочет отдать слово.

Расшифровка строки лога: ECM, caid, provid, time

Типичная строка в oscam.log выглядит так:

2026/06/30 14:22:11 c (ecm) username: no cw (ecm time: 312 ms, hop: 1, caid: 0500, provid: 032830, srvid: 06A4)

Что здесь читать:

• caid: 0500 — система условного доступа (Viaccess, Irdeto, Nagra и т.д.)
• provid: 032830 — идентификатор провайдера внутри системы
• srvid: 06A4 — ID сервиса/канала
• ecm time: 312 ms — время ожидания ответа
• hop: 1 — сколько серверов прошёл запрос

Если ecm time есть и ненулевое — запрос дошёл до source и вернулся. Просто без CW. Если time равен нулю или строки ECM вообще нет — проблема локальная, на уровне фильтрации.

Чем «no cw» отличается от «rejected», «not found», «timeout»

not found или card not found — нет reader, который вообще берётся обслуживать этот caid/provid. Это другая ветка диагностики.

rejected — reader нашёлся, но отказал явно: не та подписка, блок по services, несовпадение ident. timeout — source не ответил вовремя. А no cw — ответил, но пусто. Три разных сценария, три разных исправления.

Где смотреть: oscam.log, веб-интерфейс (порт 8888), статус reader

WebIF по умолчанию висит на порту 8888 — открываем http://<ip>:8888. Вкладка Readers показывает статистику ECM по каждому reader: сколько успешных, сколько no cw, среднее время ответа. Вкладка Services — фильтрацию по каналам.

Для детального лога: в oscam.conf поднимаем loghistorysize = 4096, а для дампа самих CW добавляем cwlogdir = /var/log/oscam/cw/ в секцию [global]. После этого видно не только факт no cw, но и что именно приходит в ответе.

Пошаговая диагностика причины no cw

Алгоритм простой: сначала выясняем, уходит ли ECM вообще — и если да, на каком этапе теряется CW. Это сужает круг подозреваемых с десяти до одного-двух.

Проверка соответствия caid/provid в oscam.server и oscam.user

Открываем /etc/oscam/oscam.server и смотрим секцию [reader]. Там должен быть параметр caid с нужным значением. Потом смотрим /etc/oscam/oscam.user — у пользователя в параметре caid тоже должен быть этот caid, иначе сервер его просто не пустит к нужному reader.

Частая ошибка: в oscam.server прописан caid = 0500, а в логе ECM приходит с caid = 0D05. Это разные системы — Viaccess vs Nagra. Тюнер иногда сигнализирует один и тот же канал под разными caid (симулкрипт), и OScam может запрашивать не тот.

Проверка ident и блоков чтения (chid, services)

Параметр ident в oscam.server задаёт, какие provid обслуживает reader. Если написано ident = 0500:032830, а запрос идёт с provid = 032840 — reader молча игнорирует ECM. В логе это выглядит как no cw или отсутствие ECM-строки.

То же с services и chid: если у reader прописан блок services = !HBO,!MTV — конкретные каналы режутся на уровне фильтрации ещё до отправки на source. Проверить можно через WebIF → Readers → конкретный reader → Services.

Анализ времени ответа и hop в логах

Если в логе видим ecm time: 280 ms, hop: 2 и при этом no cw — запрос прошёл через два сервера и вернулся пустым. Проблема на стороне source или промежуточного hop. Если ecm time: 0 ms или строки ECM вообще нет для конкретного reader — OScam не отправлял туда запрос, значит мешает локальная фильтрация.

При hop > 1 с no cw стоит временно выставить cccmaxhops = 1 в oscam.server для диагностики — если source работает только через ретрансляцию, это подтвердит гипотезу.

Проверка ECM-длины и нестандартных пакетов

Некоторые провайдеры используют нестандартные ECM-пакеты длиннее обычных ~184 байт. Часть reader-реализаций обрезает или отклоняет их без явной ошибки, возвращая пустой ответ. В cwlogdir это видно: ECM пришёл, ушёл, а CW в дампе нет.

После смены ключей провайдером могут появиться изменённые ECM-структуры — тогда source отдаёт пустой ответ, пока не обновит ключи через EMM/AU. Это один из случаев, когда проблема не в конфиге вообще.

Настройка reader и протоколов для устранения no cw

Здесь концентрируется большинство исправимых причин. Секция [reader] в oscam.server — главное место для правок.

Параметры [reader] для cccam: protocol, device, cccversion

Минимально корректная секция для CCcam-reader:

[reader]
label = my_cccam_reader
protocol = cccam
device = 192.168.1.100,12000
user = myuser
password = mypassword
caid = 0500,1830
ident = 0500:032830
group = 1
cccversion = 2.3.0
cccmaxhops = 2

Параметр cccversion — не декоративный. Если source ожидает версию 2.2.1, а вы шлёте 2.3.0, рукопожатие может пройти, но CW будет идти криво. Попробуйте 2.0.11 или 2.1.4 если стабильное no cw на конкретном source.

Параметры newcamd/cs378x и порты

Для newcamd порт указывается индивидуально в конфиге source (обычно что-то в диапазоне 10000–15000). Для cs378x/camd35 протокол работает по TCP или UDP, порт аналогично задаётся на стороне source. Секция:

[reader]
label = newcamd_reader
protocol = newcamd
device = 10.0.0.5,15050
key = 0102030405060708091011121314
user = client1
password = secret
caid = 1830
group = 2

Параметр key (newcamd DES key) должен совпадать с тем, что прописано на server-стороне. Несовпадение ключа даёт no cw или обрыв соединения без внятной ошибки.

Опции lb_weight, lb_force_fallback и distributed cache

Loadbalance в oscam.conf секция [loadbalance] влияет на то, какой reader получит ECM-запрос. При lb_mode = 1 (weight mode) OScam отдаёт предпочтение reader с лучшей статистикой. Но если статистика не накоплена или reader временно не отвечал — сервер может выбрать плохой источник.

Параметр lb_force_fallback = 1 заставляет OScam попробовать следующий reader, если первый вернул no cw. Без него при lb_mode != 0 сервер может зациклиться на мёртвом источнике. Ещё полезен lb_nbest_percaid = 0500:2 — держать минимум 2 активных reader на данный caid.

Корректные cccmaxhops и reshare для многоуровневых share

cccmaxhops = 0 означает «только локальные карты», cccmaxhops = 1 — один уровень шаринга. При глубокой цепочке серверов иногда нужно 2–3, но каждый hop добавляет задержку и риск timeout. Повышать стоит с осторожностью, проверяя ecm time в логах.

reshare = 1 в секции reader разрешает OScam раздавать полученные CW своим клиентам дальше. Если reshare = 0, CW используется только локально. При неверном значении — клиенты ниже по цепочке получают no cw.

Когда проблема на стороне источника, а не конфига

Часть случаев, где нужно OScam: no cw решение, не лечится правкой конфигов вообще. ECM уходит, time нормальное — например, 200–350 мс — но CW стабильно пустой именно на конкретном caid. Локальный конфиг тут ни при чём.

Признаки нерабочей подписки или истёкшей карты на source

Если у source истекла подписка под конкретный пакет каналов — карта физически есть, соединение установлено, ECM принимается, но decrypt невозможен. Ответ пустой. В WebIF → Readers смотрим колонку % OK: если на конкретном reader 0% успешных CW на нужном caid при нормальном времени ответа — карта на source не работает под этот пакет.

После смены ключей провайдером карта требует обновления через EMM. Если au (auto-update) не включён — au = 1 в секции [reader] — карта устаревает и перестаёт отдавать CW на обновлённых каналах.

Hop > 1 и потеря cw на промежуточных серверах

При hop: 2 и no cw промежуточный сервер мог получить CW, но не передать дальше — например, из-за ошибки reshare или ограничения на стороне relay. Диагностировать снаружи сложно: единственный способ — попробовать подключиться к source напрямую, минуя промежуточный узел, и сравнить результат.

Нестабильный source: интервальные no cw и idle disconnect

Интервальные no cw — например, только в прайм-тайм с 19:00 до 23:00 — классический симптом перегруженного source. В остальное время канал открывается нормально, а в пиковые часы source не успевает обрабатывать очередь ECM и возвращает пустые ответы.

Ещё один паттерн: no cw появляется после 10–15 минут простоя. Это idle disconnect — source разрывает неактивное соединение, OScam не замечает разрыва сразу, и первые ECM после паузы уходят в никуда. Лечится параметром keepalive = 1 в секции [reader] и правкой reconnecttimeout.

Как объективно оценить качество источника по логам

WebIF → Readers → конкретный reader показывает три ключевых метрики: процент успешных CW (% OK), среднее время ответа (avg time) и количество reconnect. Хороший source: % OK выше 95%, avg time стабильно в диапазоне 150–400 мс, reconnect близко к нулю за период наблюдения.

Если reconnect растёт — source нестабилен или разрывает соединение по idle. Если % OK низкий при нормальном time — карта неработоспособна под нужный caid. Это объективные данные, никакие слова о «стабильности» source не заменят эти цифры из лога.

Частые ошибки конфигурации, вызывающие no cw

Большинство случаев, где требуется OScam: no cw решение, упирается в элементарные ошибки в конфигах. Разберём самые распространённые.

Неверные права и пути: oscam.server, oscam.user, oscam.conf

OScam читает конфиги из директории, заданной при запуске ключом -c. Обычно это /etc/oscam/, на некоторых образах — /var/keys/ или /usr/keys/. Если файл oscam.server лежит не там — reader просто не загрузится, и в логе будет no reader found или тихий no cw.

Права доступа: файлы конфигов должны читаться пользователем, под которым запущен oscam. Командой ls -la /etc/oscam/ проверяем владельца и права. chmod 640 + правильный chown решают.

Конфликт group между reader и user

Это одна из самых неочевидных ошибок. В oscam.server у reader прописан group = 1, а в oscam.user у клиента group = 2. Результат: reader физически есть, соединение с source есть, но OScam не предоставляет этому клиенту доступ к reader — и возвращает no cw.

Правило: значения group у reader и у user должны пересекаться. Если у reader group = 1,2, а у user group = 1 — всё работает. Проверяем через WebIF → Users → конкретный user → Readers: там видно, какие reader доступны пользователю.

Ошибки в caid/ident, лишние пробелы и регистр

OScam чувствителен к формату. caid = 0500 и caid= 0500 с пробелом перед значением — не одно и то же в некоторых версиях. Лишний пробел в ident = 0500:032830 (после последней цифры) может сломать парсинг.

Особенно коварны hex-значения: 0D05 и 0d05 OScam обычно воспринимает одинаково, но D05 без ведущего нуля — уже другой caid. Всегда использовать четырёхзначный формат с ведущими нулями.

Проблемы фаервола и NAT для сетевых reader

Сетевой reader не поднимается молча: в логе при старте видим reader my_reader: connected или failed to connect. Но если фаервол блокирует пакеты после установки соединения — ECM уходит, а ответ не возвращается. Классика для NAT с асимметричной маршрутизацией.

Проверка: iptables -L -n | grep PORT и netstat -an | grep PORT. Для CCcam порт обычно 12000 (задаётся на source), для newcamd — индивидуальный, смотреть в конфиге source. Временно отключить фаервол и проверить — если no cw исчезает, причина в iptables/NAT правилах.

После любых правок в конфигах — перезапуск или reload через WebIF → Restart, иначе изменения не применятся. И обязательно смотреть лог при старте: если reader не загрузился — в первых строках будет ошибка.

Итого: OScam: no cw решение начинается с точного чтения строки лога — caid, provid, ecm time, hop. Эти четыре поля сразу делят проблему на «локальная фильтрация», «source не отвечает» и «source отвечает пустым». Каждый сценарий лечится по-своему, и смешивать их в одно «проверьте всё» — пустая трата времени. Используйте WebIF, смотрите % OK по reader, и проблема становится очевидной за 5–10 минут.