Настройка CCcam и OScam: полное руководство 2026

Если вы занялись настройкой CCcam и OScam сервера впервые, готовьтесь к тому, что документация разбросана по форумам, половина туториалов устарела, а готовые конфиги вставляют без объяснений. Эта статья — попытка дать структурированную техническую базу: синтаксис строк, пути к файлам, методику диагностики и объяснение, почему что-то не работает.

Здесь нет рекламы провайдеров и выдуманных цитат. Только то, что реально нужно знать при работе с Enigma2-приставкой и SSH-доступом.

CCcam против OScam: какой софт выбрать под вашу задачу

CCcam — закрытый бинарник с собственным протоколом. Работает по TCP, стандартный порт 12000. Конфиг один файл — /var/etc/CCcam.cfg. Всё просто, ничего не надо собирать из исходников, и на слабом железе ведёт себя стабильно.

OScam — open-source, написан на C, поддерживает одновременно несколько протоколов: cccam, newcamd, camd35, mgcamd. Конфиги хранятся в директории /etc/tuxbox/config/oscam/ или /usr/keys/ — зависит от образа. Путь передаётся демону ключом -c /путь/к/конфигам при старте.

Архитектурные различия CCcam (C-line/N-line) и OScam (модульный, reader/account)

В CCcam всё строится на строках. Клиентское подключение — это C:-строка. Пересылка карты другому клиенту — N:-строка (newcamd). Структура плоская, без уровней абстракции.

OScam устроен иначе. Есть reader — источник ключей (реальная карта или удалённый сервер). Есть account — клиент, которому раздаётся. Есть services — фильтрация по CAID. Всё это разбито по отдельным файлам: oscam.conf, oscam.server, oscam.user, oscam.services. Сложнее, но гибче.

Когда оправдан OScam: мультипротокол, чтение реальных карт, гибкая маршрутизация

Если у вас физическая смарт-карта в кардридере — только OScam. CCcam умеет читать карты тоже, но OScam даёт полный контроль: тонкую настройку таймаутов, маршрутизацию по CAID/ident, приоритеты между reader-ами. Плюс встроенный веб-интерфейс для мониторинга в реальном времени.

OScam также незаменим, если клиенты подключаются по разным протоколам — кто-то через newcamd, кто-то через cccam. Один демон обслуживает всё сразу.

Когда хватает CCcam: простая клиентская настройка и стабильность на слабом железе

Для базового сценария "одна приставка, одна линия" CCcam справляется без лишней настройки. Меньше конфигов, меньше точек отказа. На ресиверах с 64 МБ RAM OScam иногда ведёт себя нестабильно, CCcam там работает предсказуемо.

Но как только нужны мультипротокол, реальная карта или детальный мониторинг — CCcam начинает ограничивать.

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

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

CCcam.cfg: строки C: host port username password, флаги share/no

Клиентская строка выглядит так:

C: mydomain.com 12000 myuser mypassword no { 0:0:2 }

По полям: хост, порт, логин, пароль, флаг reshare (yes/no), и опционально — ограничение по CAID в фигурных скобках. Флаг no означает, что карта не пересылается дальше — для клиентской конфигурации это стандарт.

Если сервер раздаёт клиентам, добавляется строка вида:

F: clientlogin clientpassword 1 0 0 0 { 0:0:2 }

Где F: — это запись пользователя с его логином, паролем, максимальным числом хопов и разрешёнными картами. После редактирования CCcam.cfg нужен рестарт: /etc/init.d/CCcam restart или killall -HUP CCcam.

Права на файл — обязательно chmod 600 /var/etc/CCcam.cfg. Конфиг содержит пароли, и читать его должен только root.

OScam: oscam.conf, oscam.server, oscam.user, oscam.services и их связки

В oscam.conf — глобальные параметры демона: пути к логу, уровень отладки, порт веб-интерфейса. Минимальный вариант секции [global]:

[global]
logfile = /var/log/oscam.log
loghistorysize = 4096
nice = -1

В oscam.server описывается reader — источник карт или удалённый сервер:

[reader]
label = myline
protocol = cccam
device = mydomain.com,12000
user = myuser
password = mypassword
group = 1
inactivitytimeout = 30
reconnecttimeout = 30
keepalive = 1

inactivitytimeout — секунды до отключения при отсутствии активности. reconnecttimeout — пауза перед переподключением. keepalive = 1 включает ping-запросы, чтобы соединение не рвалось через NAT.

В oscam.user — аккаунты клиентов с привязкой к группам и сервисам. В oscam.services — белые/чёрные списки CAID и provider id для фильтрации.

Все конфиги OScam тоже должны иметь права 600, а директория — 700.

Параметры протокола newcamd: ключ DES, порт, CAID/ident

Протокол newcamd (N-line в CCcam, или protocol = newcamd в OScam) требует 14-байтный DES-ключ. Ключ по умолчанию:

01 02 03 04 05 06 07 08 09 10 11 12 13 14

Строка N-line в CCcam выглядит иначе, чем C-line:

N: host 15000 user password 01 02 03 04 05 06 07 08 09 10 11 12 13 14 { CAID:ident }

DES-ключ должен совпадать на обеих сторонах — это не пароль, это параметр шифрования. Несовпадение ключа выдаёт ошибку в логе сразу при рукопожатии.

Настройка веб-интерфейса OScam (httpport 8888) для мониторинга

В oscam.conf в секции [webif]:

[webif]
httpport = 8888
httpuser = admin
httppwd = strongpassword
httpallowed = 127.0.0.1,192.168.1.0/24
httprefresh = 10

После рестарта демона веб-интерфейс доступен по адресу http://192.168.1.X:8888. Там видны статус каждого reader-а, текущий ECM time, активные клиенты и лог в реальном времени. Незаменимо при диагностике.

Порт 8888 не пробрасывать в интернет — об этом подробнее в разделе про сеть.

Сеть, порты и проброс через роутер

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

Порты по умолчанию: CCcam 12000, newcamd 15000+, camd35 UDP 34000

Стандартные порты:

• CCcam: 12000 TCP
• newcamd: 15000–15010 TCP (часто каждый CAID на отдельном порту)
• camd35: 34000 UDP
• mgcamd: обычно 8000 TCP
• OScam веб-интерфейс: 8888 TCP (только локально)

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

Проброс портов (port forwarding) и статический внутренний IP

Если приставка или сервер за домашним роутером — нужен port forwarding. В настройках роутера: внешний порт 12000 TCP → внутренний IP сервера, порт 12000.

Внутренний IP сервера должен быть статическим — либо через настройки DHCP-резервирования по MAC-адресу, либо прописан вручную в сетевых настройках приставки. Если IP меняется после перезагрузки роутера, проброс работать не будет.

Отдельная засада — двойной NAT у провайдера (CGNAT). Если провайдер сам использует NAT на своей стороне, проброс портов на домашнем роутере ничего не даст. В этом случае внешний IP у вас вообще не публичный, и входящие соединения физически невозможны без туннеля (VPN, reverse proxy или запроса у провайдера реального публичного IP).

DynDNS для динамического внешнего IP

Большинство домашних провайдеров дают динамический IP. После каждой смены адреса линия отваливается, потому что клиент пытается подключиться к старому IP.

Решение — DynDNS-клиент на роутере или приставке. Сервисы вроде No-IP, DuckDNS, FreeDNS обновляют DNS-запись при смене IP. В CCcam.cfg и oscam.server указывается доменное имя вместо IP — при реконнекте резолвится актуальный адрес.

Важно: TTL DNS-записи должен быть минимальным (60–300 секунд), иначе клиент будет кешировать старый IP ещё несколько часов после смены.

Файрвол, iptables и проверка доступности через telnet/nc

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

telnet your-domain.com 12000

Или через netcat — он информативнее:

nc -zv your-domain.com 12000

Если соединение не устанавливается — либо порт не проброшен, либо файрвол блокирует. Проверить правила iptables на сервере:

iptables -L INPUT -n -v | grep 12000

Если нужного правила нет — добавить:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT

Для camd35 аналогично, но протокол UDP:

iptables -A INPUT -p udp --dport 34000 -j ACCEPT

И ещё момент: если на одной машине запущены и CCcam, и OScam одновременно, они не должны слушать один и тот же порт. Конфликт демонов — один из них просто не стартует или выдаёт ошибку bind: address already in use. Проверить, кто занял порт: ss -tlnp | grep 12000.

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

Алгоритм диагностики всегда один и тот же: проверить статус соединения → проверить лог → сверить CAID → измерить ECM time. Не угадывать, а смотреть данные.

Чтение логов: /var/log/oscam.log, уровни логирования (loghistorysize, debug)

В OScam лог пишется в файл, указанный в oscam.conf. По умолчанию — /var/log/oscam.log. Смотреть в реальном времени:

tail -f /var/log/oscam.log

Уровень детализации задаётся параметром debug в секции [global]. Значение 0 — только ошибки, 64 — всё включая ECM-запросы. Для диагностики ставить debug = 64, после решения проблемы снизить — иначе лог раздувается до гигабайтов за сутки.

loghistorysize = 4096 — размер истории в байтах, которую хранит веб-интерфейс. Увеличить при активной диагностике.

CCcam пишет лог в /tmp/CCcam.log или /var/log/CCcam.log в зависимости от сборки. Там строки вида connected to server X, card found for CAID или can't connect to server.

Ошибка ECM timeout и increasing ECM time

ECM time — время от отправки запроса контрольного слова до получения ответа. Измеряется в миллисекундах. Норма — до 300–400 мс. При 700 мс и выше начинаются фризы. При 1500+ мс изображение просто замирает каждые несколько секунд.

Причины высокого ECM time: много хопов (каждый добавляет задержку), географически далёкий сервер, перегруженный сервер или нестабильный канал. Смотреть в веб-интерфейсе OScam: вкладка readers → столбец LastECM.

Timeout в логе выглядит как ECM timeout for CAID 0x0000 — это значит, ответ не пришёл вообще за отведённое время. В CCcam.cfg можно подкрутить ECMTIMEOUT, но это не лечит причину, только маскирует симптом.

Каналы открываются с задержкой или фризят (freeze)

Freeze при зеппинге (переключении каналов) — почти всегда ECM time. Но freeze на работающем канале — это другое. Проверить:

• Реконнекты reader-а — если в логе частые disconnect/reconnect, соединение нестабильно
• Рассинхрон времени — если системное время на приставке расходится с сервером больше чем на 30–60 секунд, шифрованное соединение может рваться. Приставки без RTC (часов реального времени) после перезагрузки имеют время 01.01.2000. Настроить NTP: ntpdate -u pool.ntp.org и добавить в автозагрузку
• Конфликт нескольких демонов на одном порту

Сообщение 'card not found' / отсутствие хопов (hops)

Это самая частая ситуация: линия online, но канал не открывается, в логе card not found. Причины:

1. Несовпадение CAID или ident. CAID канала — это шестнадцатеричный идентификатор системы условного доступа (например, 0x0500 для Viaccess, 0x1800 для Nagravision). Ident — идентификатор провайдера внутри CAID. Бывает, что визуально список провайдеров одинаковый, но ident отличается на единицу — и карта не матчится. Смотреть в логе OScam, какой CAID:ident запрашивает клиент, и что отдаёт reader.

2. Канал не в reshare. Если сервер раздаёт карту с reshare = no или hops = 0 для данного CAID — клиент не получит ключ. В логе CCcam это no card for this request.

3. Образ с нестандартным путём конфигов. Если демон запустился с ключом -c /usr/keys/, а файлы лежат в /etc/tuxbox/config/oscam/ — он просто прочитает пустую директорию и запустится без reader-ов. Проверить командой ps aux | grep oscam, с каким -c реально запущен процесс.

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

Когда настройка CCcam и OScam сервера завершена и демон запущен, встаёт вопрос: а что вообще считать нормальным качеством линии? Вот конкретный чек-лист для оценки тестового подключения.

На что смотреть: стабильность аптайма, скорость ECM, число хопов

Смотреть в веб-интерфейсе OScam или в логе CCcam в течение 30–60 минут активного просмотра:

• ECM time: постоянно ниже 400 мс — хорошо. Скачет от 200 до 800 — нестабильно. Выше 700 стабильно — неприемлемо
• Число хопов: 1–2 — норма. 3–4 — уже риск задержек. 5+ — признак длинной цепочки решары, высокая вероятность фризов
• Реконнекты: нормальная линия реконнектится не чаще 1–2 раз за несколько часов. Если в логе десятки реконнектов за час — сервер нестабилен
• Аптайм: тестировать в прайм-тайм (вечер, спортивные трансляции) — именно тогда нагрузка максимальная и сервер с ограниченными ресурсами начнёт сыпаться

Локальные карты против решары: риски длинных цепочек

Локальная карта (hops = 0 или 1 в веб-интерфейсе) — идеально. Ключи генерируются прямо на сервере, задержка минимальна.

Решара — это когда сервер сам является клиентом другого сервера и перепродаёт чужие карты. Каждый дополнительный хоп добавляет RTT и точку отказа. При цепочке в 4–5 хопов карта может упасть в любом месте, и вы об этом не узнаете сразу.

В OScam хопы видны в веб-интерфейсе — столбец Hops в списке доступных карт. В CCcam — в логе при подключении, строка card available at hop X.

Признаки ненадёжного источника (общие критерии, без названий)

Несколько признаков, которые я бы расценил как стоп-сигнал:

• Тестовая линия выдаётся с очень коротким TTL (6–12 часов) и без возможности проверить стабильность в длительной перспективе
• ECM time нормальный в первый день, но деградирует через неделю — признак перегрузки сервера при росте клиентской базы
• Поддержка отвечает только на подключение, но игнорирует сообщения о проблемах с качеством
• Набор поддерживаемых CAID не соответствует заявленному при проверке через веб-интерфейс OScam
• Нет информации о числе хопов — её скрывают намеренно, потому что значение плохое