OScam тест: проверка конфигурации и подключения

Если вы только что подняли OScam и не знаете, работает он на самом деле или просто делает вид — этот текст для вас. Правильный oscam test — это не одна команда и не одна кнопка «проверить». Это последовательность из нескольких шагов: процесс запущен, конфиги распарсились без ошибок, ридеры подключились, а карта реально отвечает на ECM-запросы. Я пройдусь по каждому шагу так, как делаю это сам при настройке нового сервера — с конкретными путями, командами и логами.

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

Что означает «тест OScam» и с чего начинать проверку

Люди часто путают «сервер запустился» и «сервер работает». Это разные вещи. Демон может стартовать, слушать порты и при этом ни один канал не расшифровывать — потому что карта просрочена, провайдер отвалился или конфиг с ошибкой в отступах. Полноценный oscam test всегда идёт по цепочке: процесс → конфиги → ридеры → реальная расшифровка. Пропускать шаги нет смысла, потому что проблема почти всегда находится не там, где кажется на первый взгляд.

Проверка запуска демона и версии сборки

Первое, что я делаю на новом сервере — смотрю, жив ли процесс вообще:

ps aux | grep oscam

Если строка с oscam есть в выводе и это не сам grep — процесс запущен. Дальше проверяю версию сборки, потому что от неё зависит поддержка протоколов и наличие багов, которые уже пофиксили в свежих ревизиях:

oscam -V

Команда выводит номер версии, дату сборки, список включённых модулей (CCCAM, NEWCAMD, CONSTCW, WEBIF и так далее) и путь к конфиг-директории. Если модуль WEBIF не скомпилирован — веб-интерфейс работать не будет вообще, сколько бы вы ни правили конфиги.

Ключевые файлы конфигурации и их расположение

На разных сборках пути отличаются. Классическое расположение — /etc/tuxbox/config/oscam/ или /var/tuxbox/config/, на некоторых ресиверах и Linux-дистрибутивах — просто /etc/oscam/. Три файла, с которыми вы будете работать постоянно:

• oscam.conf — глобальные настройки: webif, логирование, кэш, таймауты
• oscam.server — список ридеров: сетевых источников и локальных карт
• oscam.user — учётные записи клиентов и их права/группы

Стоит запомнить эти пути наизусть — при диагностике вы будете открывать их десятками раз за один вечер.

Включение веб-интерфейса (webif) для мониторинга

Без webif тест OScam превращается в чтение сырых логов вслепую, а это неудобно. В oscam.conf ищем или добавляем секцию:

[webif]
httpport = 8888
httpuser = admin
httppwd = ваш_пароль
httprefresh = 5

После перезапуска демона открываем в браузере http://IP_сервера:8888. Если страница открылась и просит логин — половина дела сделана: демон жив, конфиг распарсился, webif слушает порт. Дальше начинается собственно проверка содержимого.

Тест конфигурации и статуса ридеров

Веб-интерфейс на порту 8888 — это ваш главный инструмент. В разделе Readers видно список всех подключений: и локальные карты, и сетевые источники по cccam, newcamd или camd35. Тут и происходит основной oscam test — вы буквально видите, кто онлайн, а кто нет.

Проверка синтаксиса oscam.server и oscam.conf

OScam очень требователен к формату файлов. Табуляция вместо пробела, BOM-маркер в начале файла (частая проблема, если конфиг редактировали в Windows через Notepad), лишний пробел перед ключом — и парсер либо тихо игнорирует блок, либо ридер вообще не появляется в списке. Проверить синтаксис можно двумя способами: посмотреть, появился ли ридер в webif, и почитать лог при старте — там OScam обычно явно пишет, какую секцию не смог разобрать.

Пример корректного блока ридера для сетевого источника:

[reader]
label = source1
protocol = cccam
device = 195.xx.xx.xx,12000
user = login
password = pass
group = 1
caid = 0100,0500
inactivitytimeout = 30

Порт 12000 — стандартный для протокола cccam, но провайдер может использовать любой другой, это всегда указывается отдельно.

Статусы ридера: connected, unavailable, error

В колонке статуса webif обычно три состояния, которые важно различать:

Статус	Что значит
connected / ONLINE	Соединение установлено, авторизация прошла
unavailable / OFFLINE	Сервер недоступен: порт закрыт, сеть, неверный хост
error	Соединение есть, но авторизация или протокол не сходятся

ONLINE ещё не гарантирует расшифровку — это только про сетевое соединение. А вот error почти всегда указывает на неверный логин/пароль или несовместимый протокол.

Проверка локальной карты через oscam.dvbapi и PID

Если карта физически стоит в картоприёмнике ресивера, ридер описывается иначе — без сетевого device, а с указанием физического слота:

[reader]
label = local1
protocol = dvbapi
device = /dev/dvb/adapter0/ca0
caid = 0100

В разделе webif Card infos для такого ридера видно CAID карты, provider ID и, что особенно важно, entitlements — список открытых пакетов с датами окончания подписки. Если карта читается, но entitlements просрочены — это не ошибка сервера, это состояние самой карты, и никакой oscam test это не исправит.

Тест расшифровки: чтение логов ECM и таймингов

Статус ONLINE в списке ридеров — это только полдела. Настоящий oscam test заканчивается там, где вы видите реальные строки ECM в логе с результатом found. Всё остальное — подготовка.

Как читать строку ECM в логе (found, not found, timeout)

Запускаем демон в режиме foreground для живого наблюдения:

oscam -b
tail -f /tmp/.oscam/oscam.log

Путь к логу задаётся параметром logfile в oscam.conf, по умолчанию часто именно /tmp/.oscam/oscam.log. Типичная строка выглядит примерно так:

2026-07-20 21:14:03 client (10) source1 cluster: ECM 0100/0021/0100 found (190 ms)

Разбираем по полям: CAID системы (0100), provider ident (0021), дальше сама карта (0100), результат found и время ответа в миллисекундах. Если вместо found видим not found — источник получил запрос, но не смог его расшифровать. Timeout означает, что ответ вообще не пришёл за отведённое время.

Нормальное время ответа и что считать медленным

По моему опыту, ответ в пределах 300-400 мс — это комфортная зона, картинка открывается без задержки. Значения выше 600 мс уже дают заметные фризы при переключении каналов и иногда рассыпание картинки на несколько секунд. Если время скачет от 150 до 900 мс в течение одного вечера — смотрите в сторону загрузки источника или качества сети между вами и сервером.

Для детальной отладки поднимайте loglevel в oscam.conf:

[log]
logfile = /tmp/.oscam/oscam.log
loglevel = 4

При loglevel = 4 в лог попадают и debug-сообщения по каждому ридеру отдельно, что сильно упрощает поиск конкретной проблемы.

Проверка через dvbapi на самом ресивере

Секция dvbapi отвечает за передачу CW (control word) с сервера на ресивер:

[dvbapi]
enabled = 1
boxtype = pc
user = local_user
listenport = 9000

Если ресивер работает как отдельное устройство, а OScam стоит на нём же или на связанном сервере, boxtype нужно указать точно по модели (например, dreambox, dm7025 или coolapi для некоторых Android-приставок) — неверный boxtype часто ломает передачу CW даже при полностью рабочем ридере. Открываем на ресивере любой канал и смотрим в лог: если строки ECM появляются одновременно с открытием картинки — dvbapi настроена верно.

Диагностика проблем при неудачном тесте

Когда oscam test не проходит с первого раза — это нормально, так бывает почти всегда при первой настройке. Ниже — таблица типовых симптомов и что с ними делать.

Симптом	Вероятная причина	Как проверить
Ридер OFFLINE	Порт закрыт, firewall, неверный хост	telnet host port
ECM not found	Несовпадение CAID/provider или группы	Сверить caid и group у ридера и клиента
Постоянный timeout	Перегрузка источника, сетевые задержки	ping, traceroute до сервера

Ридер OFFLINE: сеть, порт, firewall

Первым делом проверяю доступность порта напрямую, без OScam:

telnet host 12000

Если соединение не устанавливается — проблема на уровне сети или firewall, а не в конфигурации OScam. Проверьте iptables на своей стороне (iptables -L) — часто цепочка INPUT блокирует исходящие соединения на нестандартные порты по умолчанию. Также перепроверьте сам device в oscam.server — опечатка в IP-адресе встречается чаще, чем кажется.

ECM not found: неверный CAID/ident или группа

Ридер онлайн, соединение установлено, но каждый запрос возвращает not found — классика несовпадения параметров. У сервера-источника есть определённый набор CAID и provider ident, которые он реально обслуживает. Если в вашем oscam.server указан caid, которого у источника нет, или неверная group (клиент из группы 2, а ридер настроен только на группу 1) — ответа не будет никогда, вне зависимости от статуса подключения.

Постоянные timeout и фризы картинки

Если ECM стабильно приходят с задержкой или обрываются по таймауту именно в вечернее время — чаще всего дело в перегрузке источника, когда одновременно расшифровку запрашивает много клиентов. Проверьте параметры в oscam.conf:

[global]
fallbacktimeout = 1500
cccmaxhops = 3
cachedelay = 500

Параметр fallbacktimeout определяет, сколько ждать ответа от основного ридера, прежде чем переключиться на резервный. cccmaxhops ограничивает число промежуточных серверов в цепочке reshare — чем их больше, тем выше суммарная задержка. Если у вас настроен только один источник без fallback, при его перегрузке переключаться попросту не на что.

Как выбрать источник карт для теста (общие критерии)

На этапе теста многие подключают первый попавшийся публичный источник, чтобы просто проверить, что конфиги написаны правильно. Это рабочий подход для диагностики самого OScam, но не стоит путать временную тестовую линию с постоянным решением.

На что смотреть: стабильность, uptime, локальность карт

Если вы всё же выбираете постоянный источник, важны несколько объективных параметров, а не громкие обещания. Uptime сервера — насколько редко он падает и как быстро восстанавливается после сбоев. Пинг до сервера — чем он ниже, тем стабильнее тайминги ECM и меньше шанс timeout. Совпадение CAID и provider ident с теми каналами, которые вы реально смотрите — источник может быть отличным, но просто не обслуживать нужный вам пакет. И разумное значение reshare — слишком длинная цепочка серверов между вами и картой почти гарантированно добавляет задержку.

Опасность публичных и нестабильных источников

Публичные бесплатные линии удобны для быстрой проверки, что OScam в принципе способен расшифровывать сигнал, но полагаться на них для постоянной работы не стоит. Они перегружены, обрываются без предупреждения и часто отдают ECM с таймингом далеко за 600 мс — картинка будет фризить даже при идеально настроенном сервере. Для полноценного oscam test это допустимый временный вариант, но не решение на постоянку.

Юридический контекст использования

Card sharing затрагивает вопросы авторских прав на трансляцию контента, и правила здесь различаются в зависимости от страны и конкретного оператора вещания. Используйте OScam и подобные инструменты только в рамках действующего в вашей юрисдикции законодательства и только для контента, на который у вас есть законное право доступа. Ответственность за соблюдение местных норм лежит на пользователе.