Настройка CCcam/OScam сервера: гайд 2026

Если вы читаете это, скорее всего, у вас уже установлен Enigma2 или собранный OScam на Linux, и вы застряли где-то между «демон запустился» и «каналы открываются». Настройка CCcam и OScam сервера: конфигурация, порты и устранение ошибок — это именно та тема, где большинство мануалов дают конфиг-файлы без объяснений. Разберём по-человечески: что за что отвечает, почему ломается, и как это чинить.

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

CCcam прост до неприличия — один файл конфигурации на всё. OScam устроен иначе: каждый аспект вынесен в отдельный файл, что поначалу сбивает с толку, но на самом деле удобнее при отладке.

Где лежат файлы: /etc/CCcam.cfg и /etc/tuxbox/config/oscam/

На Enigma2-ресиверах CCcam живёт в /etc/CCcam.cfg. На некоторых образах — /var/etc/CCcam.cfg. Проверьте оба пути, если не уверены: ls -la /etc/CCcam.cfg /var/etc/CCcam.cfg 2>/dev/null.

OScam на Enigma2 обычно хранит конфиги в /etc/tuxbox/config/oscam/ или /etc/oscam/. На обычном Debian/Ubuntu — стандартный путь /etc/oscam/. Полный список файлов, которые там должны быть:

• oscam.conf — глобальные настройки демона
• oscam.server — источники (ридеры): карты и сетевые линии
• oscam.user — пользователи, которым раздаёте ключи
• oscam.dvbapi — связка с тюнером через DVBAPI

Назначение oscam.conf, oscam.server, oscam.user, oscam.dvbapi

Минимальный рабочий oscam.conf выглядит так:

[global]
logfile = /var/log/oscam/oscam.log
maxlogsize = 500
debug = 0
nice = -1
WaitForCards = 1

[cs357x]
port = 15000

[cs378x]
port = 15001

[newcamd]
key = 0102030405060708091011121314
port = 15050@0500:030B00

[webif]
httpport = 8888
httpuser = admin
httppwd = admin123

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

Секция [cs357x] — это camd35 по UDP. [cs378x] — то же самое, но TCP. [newcamd] — отдельный протокол с 14-байтным ключом шифрования. Если у вас нет клиентов на newcamd, эту секцию можно вообще не включать.

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

Права на файлы конфигурации OScam должны быть 640 или 600, владелец — тот пользователь, от которого запущен демон. Иначе OScam молча проигнорирует файл или упадёт.

Перезапуск CCcam на Enigma2: /etc/init.d/CCcam restart. Для OScam есть приятная фишка — перечитать конфиг без полного рестарта: kill -HUP $(pidof oscam). Это не перезапускает соединения, а только применяет изменения в oscam.conf и oscam.user. Для oscam.server всё равно нужен полный рестарт: systemctl restart oscam или /etc/init.d/oscam restart.

Настройка CCcam и OScam сервера: конфигурация, порты и устранение ошибок протоколов

Здесь конкретика. Не «откройте нужные порты», а именно — какие, в каком формате, и что написать в конфиге.

Протокол CCcam (порт 12000 по умолчанию) и формат C-линии

C-линия — это строка подключения к удалённому CCcam-серверу как клиент. Формат:

C: hostname 12000 username password

Если вы раздаёте другим — это F-линия (создаёт локального пользователя):

F: myuser mypassword 1 0 0

Цифры после пароля: количество хопов (1 = прямой клиент), Share Limit, Deny Emu. В большинстве случаев оставляйте 1 0 0.

Порт 12000 — это дефолт CCcam, но ничего не мешает серверу использовать 10000, 16000 или что угодно другое. Всегда уточняйте реальный порт у источника.

newcamd (port 15000, deskey 0102030405060708091011121314) в oscam.server

Newcamd в OScam настраивается в двух местах. В oscam.conf — секция [newcamd] с портом и ключом. В oscam.server — ридер, который подключается к удалённому newcamd-серверу:

[reader]
label = remote_newcamd
protocol = newcamd
device = remote.host,15000
user = mylogin
password = mypass
key = 0102030405060708091011121314
caid = 0500
group = 1
reconnecttimeout = 30

Вот где чаще всего ошибаются: deskey должен совпадать с тем, что указан на сервере источника. Если ключ не совпадает — OScam не выдаст никакой явной ошибки. Соединение установится, авторизация пройдёт, но ключи будут расшифровываться неправильно. В логах будет тишина. Это один из самых неочевидных подводных камней.

cs357x (UDP) и cs378x (TCP) для camd35

cs357x — camd35 по UDP. cs378x — тот же протокол, но TCP. Разница практическая: UDP быстрее при хорошем канале (меньше накладных расходов), но пакеты могут теряться без уведомления. TCP надёжнее при нестабильном соединении — пакет либо дойдёт, либо будет ошибка. На хорошем домашнем интернете разница незаметна. На мобильном или VPN-канале берите TCP (cs378x).

Ридер для cs378x в oscam.server:

[reader]
label = camd35_tcp
protocol = cs378x
device = remote.host,15001
user = camduser
password = camdpass
caid = 0604
group = 2

Проброс портов на роутере и проверка через telnet/nc

Если OScam или CCcam принимают входящие подключения — порты нужно пробросить на роутере. Типичная схема: внешний TCP-порт 12000 → внутренний IP ресивера, порт 12000.

Проверить доступность порта снаружи:

nc -zv your.external.ip 12000

Или через telnet: telnet your.external.ip 12000. Если соединение зависает (не отказывает, а именно зависает) — скорее всего, firewall дропает пакеты молча. Если сразу «connection refused» — порт закрыт или демон не слушает.

Есть ещё одна неприятная ситуация: серый IP за NAT провайдера. Если ваш роутер получил адрес вида 10.x.x.x, 172.16-31.x.x или 100.64.x.x — вы за двойным NAT. Проброс портов на домашнем роутере не поможет, потому что внешний адрес принадлежит провайдеру. Решение — просить провайдера выдать белый IP (платно) или использовать VPN с публичным адресом.

Подключение reader-секций и работа с DVBAPI

Ридер в OScam — это любой источник ключей: физическая карта в кардридере, сетевой CCcam, newcamd или camd35 источник. Настраивается в oscam.server.

Секция [reader] для локальной карты и сетевого источника

Локальная смарт-карта:

[reader]
label = local_card
protocol = mouse
device = /dev/ttyUSB0
caid = 0500
detect = cd
mhz = 357
cardmhz = 357
group = 1
fallback = 0

Сетевой CCcam-источник:

[reader]
label = cccam_source
protocol = cccam
device = remote.host,12000
user = lineuser
password = linepass
caid = 0604,1830
ident = 0604:000000
group = 1
reconnecttimeout = 15
cccversion = 2.2.1
ccckeepalive = 1

Параметр group — ключевой для понимания архитектуры OScam. Ридер в группе 1 обслуживает только тех пользователей из oscam.user, у которых тоже указан group = 1. Если группы не совпадают — пользователь не получит ключ, хотя ридер работает. Это источник добрых 30% вопросов «почему не работает».

Настройка oscam.dvbapi и фильтры по caid/provid

Файл oscam.dvbapi управляет тем, какие сервисы декодируются тюнером. Минимальный рабочий вариант — пустой файл или вообще его отсутствие (OScam попробует всё). Но для точечного управления:

P: 0500:030B00
P: 0604:000000
P: 1830:000000

Формат строки: P: caid:provid. Если хотите исключить конкретный сервис — используете I:. Приоритет — сверху вниз.

Важный момент: если одновременно запущены CCcam и OScam, они оба будут пытаться захватить DVBAPI и тюнер. Это приводит к конфликту — один из них не получит доступ к PAT/PMT таблицам, и декодирование сломается. Запускайте что-то одно. Если нужен OScam с CCcam-источниками — используйте OScam с ридером типа protocol = cccam, не запускайте сам CCcam-демон.

Просмотр статуса через веб-интерфейс (httpport 8888)

Веб-морда OScam — реально полезный инструмент. Включается секцией [webif] в oscam.conf. Открывается на http://ip_ресивера:8888.

Там видно: статус каждого ридера (CONNECTED/DISCONNECTED), текущие ECM-запросы, время ответа на последний ECM, статистику по каждому CAID. Вкладка «Readers» покажет, поднялась ли линия. Вкладка «Live Log» в реальном времени — отличная замена tail -f /var/log/oscam/oscam.log.

Диагностика и устранение типичных ошибок

Методика диагностики по слоям. Сначала сеть, потом авторизация, потом CAID-совпадение, потом DVBAPI. Идти нужно именно в этом порядке — иначе будете бегать по кругу.

Линия не поднимается: connection refused и timeout

«Connection refused» — демон на той стороне не слушает этот порт, или firewall его закрыл. Проверяем: nc -zv hostname 12000. Если отказ — проблема на стороне сервера или в сети между вами.

«Timeout» (соединение зависает и рвётся через 30 секунд) — пакеты до сервера доходят, но назад не возвращаются. Классика: firewall дропает пакеты, или сервер получает запрос, но ответ уходит не туда (ассиметричный роутинг).

Динамический IP источника — отдельная боль. Если провайдер источника меняет IP, а в конфиге прописан статический адрес, соединение рвётся и не восстанавливается. Решение: использовать доменное имя с DDNS вместо IP-адреса. OScam резолвит hostname при каждом реконнекте.

Каналы не открываются: ECM time и no matching reader

Строка в логе no matching reader означает: OScam получил ECM-запрос на конкретный CAID/ProvID, но ни один ридер не может его обработать. Алгоритм проверки:

1. Посмотрите, какой CAID запрашивается — в логе будет что-то вроде ECM caid 0604 provid 000000
2. Проверьте секцию [reader] — там в поле caid этот CAID должен быть указан
3. Проверьте, что группы ридера и пользователя совпадают
4. Убедитесь, что ридер в статусе CONNECTED

Частая ситуация: линия поднялась, но отдаёт только часть каналов. Причина — в секции ридера указан фильтр services или слишком узкий ident. Уберите фильтры, проверьте, откроются ли каналы. Если да — дело в фильтрации.

Ошибки no signal, FTA и отсутствие декодирования

«No signal» в Enigma2 при запущенном OScam — скорее всего, проблема не в кардшаринге, а в том, что DVBAPI не подключился к тюнеру. Проверьте, что в oscam.conf секция [dvbapi] включена (enabled = 1) и параметр boxtype правильно указывает тип ресивера.

FTA-статус канала при том, что канал платный — OScam декодирует, но Enigma2 не применяет ключи. Проверьте, что не запущен второй softcam одновременно. Также проверьте pmt_mode в секции [dvbapi] — для большинства Enigma2-боксов подходит pmt_mode = 0.

Периодические фризы на премиум-каналах при нормальной работе стандартных — почти всегда высокое ECM time. Если время ответа на ключ превышает 2-3 секунды, картинка будет периодически замерзать. Об этом подробнее в разделе про выбор источника.

Чтение логов: oscam.log, уровень debug и параметр loghistorysize

По умолчанию OScam логирует минимум. Для диагностики поднимаем уровень. В секции [global]:

debug = 255
loghistorysize = 4096

debug = 255 — это полный лог: все ECM-запросы, все ответы, все попытки реконнекта. Логфайл раздуется быстро, поэтому после диагностики возвращайте debug = 0.

Что искать в логе при проблемах с подключением:

# Успешное подключение ридера:
reader cccam_source: CONNECTED to remote.host:12000

# Ошибка авторизации:
reader cccam_source: login failed (wrong username/password)

# ECM обработан:
caid 0604 provid 000000 ecm time 0:450ms

# Не найден ридер:
no matching reader for caid 0604 provid 000000

Строка с ECM time показывает реальную задержку обработки ключа. 450ms — нормально. 2500ms — будут фризы. 5000ms+ — источник умер или перегружен.

Параметр loghistorysize определяет, сколько строк хранится в памяти для веб-морды (вкладка Live Log). По умолчанию маленький. Ставьте 4096–8192 при диагностике.

Критерии выбора источника линий и оценка стабильности

Настройка CCcam и OScam сервера: конфигурация, порты и устранение ошибок — это половина работы. Вторая половина — понять, что источник, который вы подключили, реально работает стабильно. Красивые обещания не считаются.

На что смотреть: аптайм, пинг до сервера, время отдачи ECM

Пинг до хоста источника должен быть стабильным. Не обязательно низким — 80ms стабильных лучше, чем 20ms с джиттером 150ms. Проверяете: ping -c 100 remote.host и смотрите на разброс (min/avg/max). Если max в 5-10 раз больше avg — джиттер большой.

ECM time — главный показатель качества. Смотрится в веб-морде OScam или в логе. Норма — до 700-800ms. При значениях больше 1500ms будут видимые фризы. При 3000ms+ источник работает неприемлемо.

Аптайм оценивается за неделю-две. Единичные разрывы (раз в несколько дней) — терпимо. Ежедневные обрывы по 10-30 минут — источник перегружен или нестабилен.

Как тестировать стабильность через мониторинг логов

Практичный метод: включите debug = 64 (только ECM-транзакции, без спама) на 24 часа. Потом проанализируйте лог:

grep "ecm time" /var/log/oscam/oscam.log | awk -F: '{print $NF}' | sort -n | tail -20

Это покажет 20 самых долгих ECM-ответов за период. Если среди них есть значения больше 3000ms — были видимые фризы. Считайте их количество — поймёте, насколько часто.

Также смотрите на реконнекты ридера. Команда:

grep -c "CONNECTED\|DISCONNECTED" /var/log/oscam/oscam.log

Если реконнектов за сутки десятки — источник нестабилен. Единицы — нормально.

Признаки перегруженного или нестабильного источника

Перегруженный источник ведёт себя предсказуемо: в прайм-тайм (вечером, в выходные) ECM time резко растёт, каналы начинают фризить. Утром всё нормально. Это классика сервера, на который подключено слишком много клиентов.

Признаки именно нестабильного (а не перегруженного) источника: реконнекты в случайное время, ECM time стабильно высокий даже ночью, иногда ридер висит в CONNECTED но ключи не отдаёт (это лечится reconnecttimeout = 15 в секции ридера).

Количество пакетов/каналов в линии — последний по важности показатель. Источник с 5000 каналов и ECM time 4000ms хуже, чем источник с 500 каналами и ECM time 300ms. Смотрите на время, а не на количество.