Настройка CCcam и OScam: полный гайд 2026

Настройка CCcam и OScam сервера — задача, которая ставит в тупик даже людей с опытом работы в Linux. Конфиги разбросаны по разным путям в зависимости от прошивки, документация устарела, а большинство гайдов в сети просто дают готовые строки без объяснений. Здесь разберём всё построчно: от архитектуры протоколов до реальной диагностики по ECM-логам.

Чем CCcam отличается от OScam и что выбрать

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

Архитектура и принцип работы протокола CCcam

CCcam — закрытый бинарник. Исходников нет, баги не патчатся сообществом, поддержка новых карт появляется нерегулярно. Протокол работает по принципу "клиент-сервер": сервер держит карту и раздаёт CW (control words) клиентам. Соединение идёт по TCP, порт по умолчанию 12000.

Конфиг-файл один — CCcam.cfg. Строки C: описывают подключения к вышестоящим серверам, строки N: — подключения по протоколу newcamd, F: — локальные карты. Простота в этом есть, но она же ограничивает: нет гибкой маршрутизации, нет веб-интерфейса из коробки, логи скудные.

Преимущества OScam: модульность и поддержка протоколов

OScam — открытый проект, форк OSCAM, написан на C. Поддерживает одновременно newcamd, cccam, camd35, gbox, radegast и ещё с десяток протоколов. Каждый ридер настраивается отдельно, аккаунты управляются через отдельный файл, есть веб-интерфейс на порту 8888.

В моей практике OScam выигрывает практически всегда. Детальные ECM-логи, статусы ридеров в реальном времени, возможность ограничивать пользователей по CAID, времени суток, количеству одновременных подключений. Это не маркетинг — это реальная разница при отладке.

Когда оправдана связка OScam + CCcam

Если источник карт отдаёт только по протоколу CCcam, а вы хотите всю гибкость OScam — делаете так: OScam запускается как основной сервер, в oscam.server добавляете ридер с protocol = cccam, и OScam сам ходит к CCcam-серверу за CW. Клиенты подключаются уже к OScam.

Обратная схема тоже работает: CCcam как клиент, OScam локально держит карту и отвечает на CCcam-запросы через эмулятор CCcam-протокола в OScam. Главное — не запускать оба одновременно с доступом к одному DVB-тюнеру. Конфликт DVBAPI гарантирован: оба процесса будут пытаться открыть /dev/dvb/adapter0/ca0 и один из них умрёт с ошибкой или, что хуже, они будут мешать друг другу молча.

Структура конфигурационных файлов и пути

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

Файлы CCcam: CCcam.cfg и CCcam.channelinfo

На Enigma2 (OpenPLi, OpenATV, VTi) основной конфиг обычно лежит в /var/etc/CCcam.cfg. На чистом Debian/Ubuntu — в /etc/CCcam.cfg. Бинарник при старте ищет файл по вшитому пути, изменить его без перекомпиляции нельзя.

Пример минимального рабочего конфига:

# Подключение к серверу (C: line)
C: hostname.example.com 12000 login password

# Открыть серверный порт для клиентов (S: line)  
S: 12000

# Уровень логирования
DEBUG: 0

Файл CCcam.channelinfo — опциональный, нужен для отображения названий каналов в логах. Путь тот же, что и основной конфиг.

Файлы OScam: oscam.conf, oscam.server, oscam.user, oscam.dvbapi

OScam хранит конфиги в директории, которая передаётся параметром -c при запуске. Типичные пути:

• Enigma2 (OpenPLi, VTi): /etc/tuxbox/config/oscam/
• Debian/Ubuntu: /etc/oscam/
• Старые прошивки: /var/keys/

Минимальный набор файлов: oscam.conf (глобальные настройки), oscam.server (ридеры/источники), oscam.user (аккаунты клиентов), oscam.dvbapi (настройки декодирования для тюнера). Без oscam.dvbapi локальное декодирование не заработает — только проксирование для сетевых клиентов.

Права доступа и расположение в файловой системе

Файлы с ключами и паролями — oscam.server, oscam.user — должны иметь права 600 (только владелец читает/пишет). Конфиги без чувствительных данных — oscam.conf, oscam.dvbapi — можно оставить 644.

chmod 600 /etc/oscam/oscam.server
chmod 600 /etc/oscam/oscam.user
chmod 644 /etc/oscam/oscam.conf
chown oscam:oscam /etc/oscam/*

После обновления прошивки на Enigma2 права часто сбрасываются до 777 или вообще переписываются дефолтными файлами. Первое, что проверяю после апдейта — именно права на файлы ключей.

Сетевые настройки: порты и протоколы

Здесь ошибки стоят дорого — либо ничего не работает, либо, что хуже, сервер открыт для всего интернета.

Стандартные порты CCcam и newcamd

CCcam по умолчанию слушает на порту 12000 (TCP). Протокол newcamd — обычно 15000 или выше, часто встречаются 15000–15010 для разных спутников/пакетов. Camd35 работает на 34000 (UDP и TCP). Gbox использует 4101 и 4102.

В oscam.conf порты для каждого протокола прописываются в отдельных секциях:

[newcamd]
port = 15000@0500:000000

[cccam]
port = 12001

[camd35]
port = 34000

Запись 15000@0500:000000 означает: порт 15000 обслуживает CAID 0500 с provider ID 000000. Если провайдер ID не важен — можно указать просто 15000@0500.

Настройка веб-интерфейса OScam (httpport)

Веб-интерфейс — одна из главных причин выбирать OScam. Настраивается в секции [webif] файла oscam.conf:

[webif]
httpport = 8888
httpuser = admin
httppwd = yourpassword
httpallowed = 127.0.0.1,192.168.1.0-192.168.1.255
httprefresh = 10

Параметр httpallowed — не опциональный, это требование. Открытый 8888 порт наружу без ограничения по IP — это приглашение посмотреть на ваши ридеры для всех желающих. Ограничиваем локальной сетью и конкретными IP.

Проброс портов на роутере и фаервол

Для доступа клиентов извне нужен проброс портов на роутере (port forwarding). Пробрасываем только те порты, которые реально нужны: например, 12001/TCP для CCcam-клиентов и 15000/TCP для newcamd.

Правила iptables для ограничения доступа по IP:

# Разрешить конкретный IP на порт CCcam
iptables -A INPUT -p tcp --dport 12001 -s 1.2.3.4 -j ACCEPT
iptables -A INPUT -p tcp --dport 12001 -j DROP

# Веб-интерфейс — только локалка
iptables -A INPUT -p tcp --dport 8888 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8888 -j DROP

Отдельная история — двойной NAT. Если сервер за роутером, а роутер за роутером провайдера (CGNAT), пробросить порты снаружи невозможно без белого IP. В таком случае единственный вариант — VPN-туннель (WireGuard, OpenVPN) или VPS как посредник.

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

Настройка CCcam и OScam сервера в связке начинается с правильной последовательности. Не наоборот — сначала глобальный конфиг, потом ридеры, потом пользователи.

Базовый oscam.conf и включение DVBAPI

Минимальный рабочий oscam.conf:

[global]
logfile = /var/log/oscam/oscam.log
maxlogsize = 500
logduplicatelines = 0
waitforcards = 60
nice = -1
serialreadertimeout = 1500

[dvbapi]
enabled = 1
user = dvbapi_user
boxtype = dreambox
au = 1
pmt_mode = 0
request_mode = 0

Параметр boxtype важен: для Dreambox/Enigma2 — dreambox, для VU+ — dreambox тоже работает, для обычного Linux с libdvbcsa — pc. Неправильный boxtype — канал не откроется, хотя декодирование логически проходит.

Добавление ридера в oscam.server

Ридер — это источник CW. Может быть физическая карта или удалённый сервер. Пример ридера для подключения к серверу по протоколу CCcam:

[reader]
label = my_cccam_reader
protocol = cccam
device = hostname.example.com,12000
user = mylogin
password = mypassword
caid = 0500,1830
group = 1
reconnecttimeout = 30
inactivitytimeout = 60
lb_weight = 100

Для newcamd-ридера структура немного другая:

[reader]
label = newcamd_reader
protocol = newcamd
device = hostname.example.com,15000
key = 0102030405060708091011121314
user = clientlogin
password = clientpass
caid = 0500
group = 2

Параметр group — это группа маршрутизации. Ридер отвечает только на запросы от аккаунтов с совпадающей группой. Забыть его — типичная ошибка, после которой ридер подключён, но каналы не декодируются.

Создание пользователей в oscam.user

[account]
user = client1
pwd = password123
group = 1,2
au = 1
caid = 0500,1830
maxconnections = 2
uniq = 0

Параметр maxconnections ограничивает одновременные сессии. uniq = 1 запрещает одновременный вход с одним логином — полезно против шаринга аккаунтов. Отдельный аккаунт нужен для DVBAPI-декодирования — тот самый dvbapi_user из oscam.conf.

Первый запуск и проверка логов

Запуск OScam в фоновом режиме:

oscam -b -c /etc/tuxbox/config/oscam/

На Debian с конфигами в /etc/oscam/:

oscam -b -c /etc/oscam/

Сразу смотрим лог:

tail -f /var/log/oscam/oscam.log

Ридер должен показать статус CONNECTED или CARDOK в течение 10–30 секунд. В веб-интерфейсе на http://192.168.1.x:8888 раздел Readers покажет статус онлайн и время ответа в мс.

Диагностика и устранение ошибок

Самая частая жалоба: "всё настроено, ридер онлайн, но канал не открывается". Разбираем по шагам.

Канал не открывается: проверка ECM и SID

Первое — смотрим ECM-лог. В нормальной ситуации видим:

ECM decode time: 245ms, CAID: 0500, provider: 000000, SID: 1234 - decoded

Если там not decoded или вообще нет ECM-запросов — проблема в другом месте. Отсутствие ECM-запросов означает, что DVBAPI не перехватывает сигнал: проверить pmt_mode и request_mode в секции [dvbapi].

Если ECM-запросы есть, но not decoded — смотрим CAID и provider ID. Ридер должен обслуживать именно этот CAID. В oscam.server параметр caid должен включать нужное значение, и группы ридера и аккаунта должны совпадать.

Ошибка no matching reader в логе однозначно говорит: OScam не нашёл ридер, который взялся бы за этот CAID. Проверяем: CAID в ридере, группы, статус ридера (онлайн?), ограничения по SID или провайдеру.

Ридер не подключается: timeout и группы

Статус offline у ридера — алгоритм проверки такой:

1. Пингуем хост: ping hostname.example.com. Нет ответа — проблема на уровне сети или DNS.
2. Проверяем порт: nc -zv hostname.example.com 12000. Connection refused — сервер не слушает или фаервол блокирует.
3. Проверяем логин/пароль — опечатки случаются чаще, чем хочется признавать.
4. Смотрим на протокол: если сервер ждёт newcamd, а ридер настроен на cccam — не подключится никогда.

Параметр inactivitytimeout — время в секундах, после которого OScam считает ридер неактивным и переподключается. Значение 60–120 секунд обычно нормальное. Слишком маленькое значение вызывает постоянные переподключения и timeout в логах даже при рабочем сервере.

Высокое время ECM-ответа — например, 800–1200 мс — часто не проблема конфига. Это сетевая задержка до сервера или перегрузка на стороне источника. Проверяем ping до хоста: если RTT 300+ мс, конфиг тут ни при чём.

Чтение логов и уровни отладки

По умолчанию OScam логирует на уровне нормального вывода. Для диагностики поднимаем уровень через веб-интерфейс (раздел Config → Log) или параметром в конфиге:

[global]
logfile = /var/log/oscam/oscam.log
debuglevel = 255

Уровень 255 — максимальный, покажет все ECM-запросы, ответы, статусы ридеров. После диагностики возвращаем на 0 или 64 — иначе лог-файл вырастет до гигабайтов за сутки.

Ключевые строки, которые ищем в логе при отладке:

• rejected — аккаунт не авторизован или превышен maxconnections
• cw not found — ридер запрос принял, но ответить не смог
• cwc timeout — ридер не ответил вовремя, OScam переключился на следующий
• CAID/provider mismatch — несовпадение параметров карты и запроса

Настройка CCcam и OScam сервера требует системного подхода: сначала добиваемся статуса CONNECTED у ридеров, потом проверяем прохождение ECM-запросов, потом — время ответа. По-другому не работает.