NCam ошибка ECM 28: причины и решение в OScam/CCcam

Если в логах NCam мелькает статус 28 и канал уходит в чёрный экран — это не глюк приёмника и не повод перепрошивать железо. ECM 28 означает строго одно: запрос контрольного слова ушёл, но валидный ответ не вернулся в отведённое время. Понять это важно сразу, потому что большинство «советов» в интернете сводятся к «увеличьте таймаут» — и это худшее, что можно сделать. Здесь разберём NCam: ECM 28 решение по шагам: от чтения строки лога до правки конфигов и выбора нормального источника ключей.

Что означает ECM 28 в NCam и почему это не баг приёмника

ECM 28 — это внутренний статус NCam, обозначающий timeout при получении CW (control word, контрольного слова). NCam отправил ECM-запрос ридеру или удалённому серверу, но либо ответ пришёл позже установленного лимита, либо пришёл некорректным и не прошёл проверку. Декодирование канала не происходит, экран чёрный.

Важно: это проблема на стыке NCam и источника ключей. Сам приёмник тут вообще ни при чём — он просто не получает CW, которое некому отдать.

Расшифровка статуса 28: ECM отправлен, но валидный ответ не получен вовремя

В протоколе NCam статус ECM-запроса кодируется числом. 28 (или в hex 0x1C) означает E_NOTFOUND с признаком timeout — то есть запрос был сформирован и отправлен, ридер его принял (или должен был принять), но CW в ответе либо не пришло, либо пришло невалидным. Не путайте с ситуацией, когда ридер вообще не откликнулся на подключение.

Как читать строку лога: CAID, provider ID, PID, время ответа

Вот типичная строка лога NCam, которая сигнализирует о проблеме:

2026/03/15 21:43:07   7F2A ECM caid 0500 prov 042800 pid 0041 srvid 05A0 -- 28 (650 ms) by reader01

Разбираем поля:

• caid 0500 — идентификатор системы условного доступа (здесь Viaccess)
• prov 042800 — provider ID конкретного пакета
• pid 0041 — PID потока в транспондере
• srvid 05A0 — ID сервиса/канала
• 28 — статус: timeout/нет валидного CW
• 650 ms — реальное время ожидания до таймаута
• reader01 — какой ридер обрабатывал запрос

Время 650 мс при лимите, скажем, 5000 мс — значит ридер ответил, но CW оказалось неверным. Если видите значение, равное вашему ctimeout (например ровно 5000 мс) — ответа не было вообще.

Чем ECM 28 отличается от 'card not found' и 'no matching reader'

card not found — NCam вообще не нашёл ридер, который заявил поддержку этого CAID. Маршрутизация не состоялась даже на уровне выбора ридера.

no matching reader — ридеры есть, но ни один не подходит по CAID/ident/группе. ECM не ушёл никуда.

ECM 28 — принципиально другая ситуация: ридер был выбран, запрос отправлен, но на выходе нет рабочего CW. Это уже проблема либо самого ридера/источника, либо сети между ними, либо конфигурации таймаутов.

Основные причины ECM 28 и быстрая диагностика

Прежде чем что-то менять в конфигах — включите детальный лог. В /etc/tuxbox/config/ncam/ncam.conf выставьте:

[global]
logfile = /tmp/ncam.log
debuglevel = 64

Затем смотрите лог в реальном времени: tail -f /tmp/ncam.log | grep "ECM\|28". Уже по паттерну 28-ошибок многое становится понятно.

Симптом в логе	Вероятная причина
28 ровно каждые N мс (= ctimeout)	Ридер не отвечает совсем, сеть или сервер упал
28 со временем меньше ctimeout	CW пришло, но невалидное (рассинхрон, перегрузка)
28 только на одном CAID/provider	Несовпадение caid/ident или источник не держит этот пакет
28 периодически, остальное ок	Пиковая нагрузка на источник или нестабильная сеть
28 только вечером 19:00–23:00	Перегрузка источника в прайм-тайм
28 после смены ключей на канале	Нужен рестарт ридера, источник ещё не синхронизировался
28 только по Wi-Fi	Нестабильный ping, на кабеле исчезает
28 через VPN	Дополнительная задержка VPN превышает rtimeout

Таймаут: ответ приходит позже лимита ncam.conf

Самая частая причина. Если ваш ping до источника 80 мс, а CW обрабатывается на сервере ещё 200–300 мс — итого 380+ мс. При ctimeout=300 это гарантированный 28. Но и поднимать ctimeout до 10 000 мс — плохая идея, об этом ниже.

Несовпадение CAID/provider — ECM уходит не на тот ридер

NCam строит маршруты ECM по CAID и ident (provider ID). Если в блоке [reader] прописан неверный ident или он вообще не прописан — запрос либо уйдёт на неподходящий ридер, либо не уйдёт никуда. Результат: 28 или no matching reader.

Сервер ответил, но CW неверное

Это случается при перегрузке источника или рассинхроне: сервер отдаёт CW, но к моменту доставки оно уже устарело. Особенно заметно на каналах с частой сменой CW (интервал 3–5 секунд вместо стандартных 10). В логе увидите 28 со временем ответа меньше ctimeout.

Сетевые потери и высокий ping

Проверьте банально: ping -c 20 [адрес_источника]. Если видите packet loss или jitter под 50 мс — это ваша причина. По Wi-Fi проблема усиливается в разы, особенно в многоквартирном доме. Кабель устраняет это мгновенно.

Неверный протокол подключения

CCcam и newcamd — разные протоколы с разными портами. Если источник ожидает подключение по newcamd на порт 15000, а вы подключаетесь как CCcam на 12000 — соединение может установиться, но ECM-запросы будут игнорироваться или возвращать мусор. Всегда уточняйте у источника: протокол, порт, формат ключа.

Пошаговое решение: правка конфигов NCam и OScam/CCcam

Конфиги NCam лежат в /etc/tuxbox/config/ncam/ или /var/tuxbox/config/ncam/ — зависит от прошивки. Ключевые файлы: ncam.conf, ncam.server, oscam.dvbapi. Если вы используете OScam на стороне клиента — аналоги: /etc/oscam/oscam.conf, /etc/oscam/oscam.server.

Увеличение таймаута: параметры ctimeout, rtimeout, lb_reopen_seconds

Разумные значения для нормального источника с пингом до 100 мс:

[global]
ctimeout = 5000
ntimeout = 5000
lb_reopen_seconds = 120

ctimeout — максимальное время ожидания CW в миллисекундах. 5000 мс — рабочий ориентир для большинства конфигураций. rtimeout в блоке [reader] можно выставить индивидуально: берёте средний ping до источника, умножаете на 3, добавляете 500 мс запаса.

lb_reopen_seconds = 120 — через сколько секунд loadbalancer снова попробует «плохой» ридер. Слишком маленькое значение создаёт лишние попытки на нерабочий источник.

Проверка и фикс блока [reader]

Пример корректного блока для newcamd-подключения в ncam.server:

[reader]
label = myserver
protocol = newcamd
device = 192.168.1.100,15000
key = 0102030405060708091011121314
user = myuser
password = mypass
caid = 0500,1802
ident = 0500:042800,042801;1802:000000
group = 1
lb_weight = 100
ctimeout = 5000
rtimeout = 3000

Критичные поля: caid — должен совпадать с тем, что транслирует ваш канал. ident — provider ID в формате CAID:PROVIDERID. Эти значения берутся из лога NCam (поле prov) или из баз данан типа dvbapi. Если ident не указан — NCam будет слать ECM на все ридеры с нужным CAID, что неэффективно.

Для CCcam-протокола блок выглядит иначе:

[reader]
label = cccam_server
protocol = cccam
device = my.server.host,12000
user = cccam_user
password = cccam_pass
caid = 0500
group = 1

Настройка ECM-маршрутизации и приоритета ридеров (lb_mode)

Для диагностики ECM 28 первым делом отключите loadbalancer:

[global]
lb_mode = 0

С выключенным LB NCam будет использовать ридеры в порядке их записи в ncam.server. Так сразу видно, какой именно ридер даёт 28 — смотрите поле by readerXX в логе. После диагностики можно вернуть lb_mode = 1 (round-robin) или lb_mode = 5 (по времени ответа).

Если несколько ридеров поддерживают один CAID — LB выберет самый быстрый. Но если «медленный» ридер стабильно попадает в ротацию при пиковой нагрузке — он будет давать 28. Используйте lb_weight для управления приоритетом.

Корректные порты и протокол

Стандарты де-факто, которые использует большинство серверов:

• newcamd: порты 15000–15010
• CCcam: 12000 (стандарт) или 12001–12010
• cs378x (Camd 3.5x): 15001 или кастомный
• radegast: 8000

Протокол cs378x иногда предпочтительнее newcamd для конкретных CAID — он меньше нагружает CPU сервера и быстрее при стабильной сети.

Проверка caid/ident в oscam.dvbapi

Файл oscam.dvbapi управляет тем, какие ECM-запросы NCam вообще будет генерировать. Если в нём прописан неверный CAID или он не содержит нужного пакета — запросы либо не формируются, либо идут не туда.

P: 0500:042800
P: 1802:000000
P: 0604:000000

Проверьте: CAID и provider ID в dvbapi должны совпадать с тем, что видите в логе NCam в строках 28. Рестарт после изменения: systemctl restart ncam или /etc/init.d/ncam restart, затем tail -f /tmp/ncam.log.

Что не помогает при ECM 28 (типичные ошибки)

Хочется сразу сказать прямо: большинство вещей, которые люди делают первым делом — бесполезны. Или даже делают хуже.

Бесконечное увеличение таймаута вместо поиска причины

ctimeout = 30000 — это не решение, это маскировка. Да, каналы перестанут «пропадать» сразу. Но вместо этого вы получите фризы по 10–15 секунд, потому что декодер ждёт CW, которое всё равно не придёт. Пользователи жалуются на «зависание» картинки — это и есть ваш огромный таймаут в действии.

Нормальный рабочий ctimeout для источника с пингом до 50 мс — 3000–5000 мс. Для источников через VPN или с пингом 150+ мс — до 7000 мс. Больше не нужно.

Слепое копирование чужих ncam.server

В интернете полно «рабочих конфигов». Проблема в том, что device, user, password, key — это учётные данные конкретного пользователя конкретного источника. Даже если взять конфиг человека с таким же приёмником — у вас другой аккаунт, другой IP, возможно другой список CAID.

Кроме того, caid и ident зависят от того, какие каналы вы смотрите. В чужом конфиге прописаны ЧУЖИЕ каналы.

Смена прошивки приёмника

Видел это много раз: человек пробует Enigma2, потом OpenPLi, потом OpenATV — ECM 28 остаётся везде. Разумеется. Прошивка приёмника не влияет на то, как удалённый сервер обрабатывает ECM-запросы. NCam везде один и тот же, источник ключей тот же, сеть та же.

Перезагрузка ресивера как универсальное решение

Помогает ровно в одном случае: если завис сам процесс NCam или утёкла память. В остальных случаях вы перезагружаетесь, NCam поднимается, коннектится к тому же нерабочему источнику — и получаете те же 28. Единственное, что иногда имеет смысл — рестарт самого NCam командой /etc/init.d/ncam restart, не всего приёмника.

Отдельный случай — 28 после смены ключей на канале (key change). Тут рестарт ридера действительно помогает: ncam -r readerlabel или через веб-интерфейс NCam. Источник ключей мог ещё не раздать новые CW всем клиентам.

Как выбрать стабильный источник ключей, чтобы ECM 28 не повторялся

NCam: ECM 28 решение на уровне конфигов работает только если у вас нормальный источник. Если источник перегружен или нестабилен — никакие таймауты не помогут. Так что выбор источника — это половина дела.

Критерии: низкий ping, стабильное время ответа ECM

Посмотрите в логах NCam на среднее время ответа по вашему ридеру. Строки с успешными ECM (статус found) содержат время в мс. Нормальный источник даёт 100–350 мс стабильно. Если видите разброс от 80 до 2000 мс — источник нестабилен или перегружен.

Ping — необходимое, но недостаточное условие. Ping 20 мс, а ECM 800 мс — значит проблема на стороне сервера (слабое железо, много клиентов). Ping 80 мс и ECM 250 мс — это нормально.

Поддержка нужного CAID/provider без переподключений

Перед тем как привязываться к источнику — проверьте, что он реально держит ваш CAID и конкретные provider ID. Смотрите в логах NCam: при успешном подключении NCam пишет список поддерживаемых CAID от ридера. Если вашего нет — источник вам не подходит, сколько бы он ни стоил.

Частые reconnect в логе (connection lost, reconnecting) — красный флаг. Нормальный источник держит соединение часами без разрывов.

Прозрачные лимиты на количество ECM и каналов

У каждого источника есть ограничения: сколько ECM в секунду, сколько одновременных соединений, сколько каналов параллельно. Если эти лимиты не раскрываются — вы не узнаете, почему периодически получаете 28 в прайм-тайм (ответ: вас режет rate limiter).

Тестовый период для проверки на ваших каналах

Единственный честный способ проверить источник — гонять его на своих реальных каналах минимум 48–72 часа. Включая прайм-тайм (19:00–23:00), когда нагрузка максимальна. Смотрите в логах NCam процент 28 от общего числа ECM-запросов. Приемлемый уровень — менее 1–2%. Всё выше — источник не справляется.

Для самостоятельного подсчёта: grep "reader01" /tmp/ncam.log | grep -c " 28 " и grep "reader01" /tmp/ncam.log | grep -c "found". Разделите первое на сумму — получите долю неудачных ECM.

Вот и полная картина NCam: ECM 28 решение — от диагностики лога до выбора источника.