CCcam: настройка сервера и конфиг — полное руководство 2026

Если ты читаешь это, скорее всего у тебя уже есть ресивер на Enigma2, и ты хочешь разобраться с cccam без воды и рекламы платных серверов. Разберём всё по порядку: как работает протокол, как выглядит правильный конфиг, куда смотреть когда ничего не работает.

Сразу скажу честно — cccam в 2026 году это legacy. Разработка остановлена несколько лет назад. Но протокол до сих пор работает, оборудование его поддерживает, и миллионы ресиверов его используют. Так что разобраться стоит, даже если потом мигрируешь на OScam.

Что такое CCcam и как работает протокол

По сути это клиент-серверный протокол для передачи control words (CW) по сети. На сервере стоит физическая смарт-карта с платной подпиской. Клиент отправляет зашифрованный ECM-запрос, сервер расшифровывает его через карту и возвращает CW. Ресивер использует это слово для раскодирования потока.

Весь обмен идёт по TCP. Стандартный порт — 12000. Задержка на хорошем соединении — 150–400 мс, что вполне комфортно для живого просмотра.

Принцип card sharing и роль ECM/EMM

ECM (Entitlement Control Message) — это зашифрованный пакет от вещателя, который содержит CW. Без карты расшифровать его нельзя. EMM (Entitlement Management Message) — служебные сообщения для обновления прав на карте. CCcam умеет проксировать и те, и другие, хотя с EMM у него исторически хуже, чем у OScam.

Клиент постоянно шлёт ECM-запросы — примерно каждые 10 секунд при смене CW. Если сервер отвечает медленнее 600–800 мс, картинка начинает фризить или чернеет на секунду.

Чем CCcam отличается от OScam и MgCamd

CCcam — закрытый проприетарный протокол. Исходников нет, последний известный релиз датируется 2012–2013 годами. OScam — открытый, активно разрабатывается сообществом, лучше работает с кэшем и EMM. MgCamd — ещё один клиент, более лёгкий, меньше жрёт памяти на старых железках.

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

Порт 12000 и структура обмена пакетами

Клиент подключается к серверу по TCP:12000 (если не переопределено в конфиге). Первый обмен — хэндшейк с аутентификацией по username/password. После этого сессия остаётся открытой, и по ней гоняются ECM/CW пакеты.

CCcam также поддерживает протоколы newcamd и cs357x для обратной совместимости со старыми клиентами. Это удобно если в сети смешанный зоопарк из оборудования.

Установка CCcam на Enigma2 и Linux

Нет единого пакета — обычно скачивают готовый бинарник под свою архитектуру. Самое первое что нужно выяснить: какой процессор в ресивере. Большинство современных Enigma2-приставок — arm или armv7, старые Dreambox — mipsel. Ошибка с архитектурой самая частая: бинарник не запускается и не даёт никакой ошибки в консоли — просто молчит.

Загрузка бинарника под архитектуру (mipsel, arm)

Проверить архитектуру можно командой:

uname -m
cat /proc/cpuinfo | grep -i model

Если uname -m отдаёт mips — нужен mipsel-бинарник. Если armv7l или aarch64 — соответствующий arm-вариант. Для Vu+ Zero 4K и подобных современных боксов нужен aarch64.

Копирование в /usr/bin и права chmod 755

Бинарник кладётся в /usr/bin/CCcam. После копирования обязательно:

chmod 755 /usr/bin/CCcam

Без этого он не запустится. Проверить что процесс поднялся:

ps | grep CCcam
# или
ps aux | grep -i cccam

Если в выводе есть строка с путём к бинарнику — процесс живой. Двойная строка (два процесса) — проблема, об этом ниже.

Автозапуск через init.d и проверка процесса

Пути к конфигу и скриптам автозапуска отличаются в зависимости от прошивки:

• OpenATV: конфиг в /etc/CCcam.cfg, softcam через /etc/init.d/softcam
• OpenPLi: конфиг в /etc/CCcam.cfg, управление через PLi-softcam менеджер
• Vu+ (VTi): конфиг обычно в /var/etc/CCcam.cfg, запуск через /etc/init.d/softcam.amlogic

Ручной рестарт процесса:

killall -9 CCcam
sleep 2
/usr/bin/CCcam &

Важный момент: если CCcam завершился некорректно, он иногда оставляет занятый порт 12000. Перед запуском лучше убедиться что порт свободен: netstat -tlnp | grep 12000.

Структура файла CCcam.cfg: F-линии и параметры

Конфиг читается построчно, каждый тип строки начинается с буквенного идентификатора. Регистр имеет значение — c: и C: это разные вещи. После двоеточия обязателен пробел — без него строка игнорируется молча, и ты час будешь искать проблему.

Синтаксис F-линии: F: user pass uphops downhops

F-линия создаёт пользователя которому разрешено подключаться к твоему серверу:

F: myuser mypassword 1 0 0

Расшифровка по позициям:

• myuser — логин клиента
• mypassword — пароль
• первая цифра — uphops: сколько хопов «вверх» разрешено видеть клиенту
• вторая — downhops: глубина решары, которую клиент может раздавать дальше
• третья — дополнительный флаг (обычно 0)

Если у тебя два клиента с одинаковым username в двух разных F-линиях — будут конфликты авторизации. Второй подключившийся выбьет первого или оба получат ошибку. Каждый username должен быть уникальным.

Параметры C-линии для подключения как клиент

C-линия описывает удалённый сервер к которому ты подключаешься как клиент:

C: server.example.com 12000 mylogin mypass

Можно добавить несколько C-линий — CCcam попробует все по порядку. Но не злоупотребляй: длинные цепочки решары увеличивают ECM time и добавляют нестабильность.

Опции SERVER LISTEN PORT и WEBINFO LISTEN PORT

В верхней части конфига задаются глобальные параметры:

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
ALLOW TELNETINFO : yes
ALLOW WEBINFO : yes
NETD : no
DEBUG : 0

Если ALLOW WEBINFO : no — веб-интерфейс на порту 16001 будет недоступен. Многие забывают об этом и потом не могут понять почему браузер не открывает страницу статуса.

Управление hops через CCcam.providers

Файл /etc/CCcam.providers позволяет задать поведение для конкретных CAID и провайдер ID. Например, разрешить решару только для определённых пакетов или ограничить uphops по конкретному спутниковому пакету. Синтаксис там простой: строки вида CAID:ProviderID.

Кольцевание решары — реальная проблема. Если uphops выставлен слишком высоко, запрос может вернуться обратно через цепочку серверов к источнику. Картинка начинает фризить каждые несколько секунд. Лечится понижением uphops до 1 или 2.

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

Первое место куда смотреть при проблемах — веб-интерфейс по адресу http://IP_ресивера:16001. Там видно состояние каждой C-линии цветом: зелёный — активна и работает, жёлтый — подключено но нет активности, красный — ошибка подключения.

Проверка статуса через веб-интерфейс :16001

На странице статуса видно ECM time для каждой карты — это миллисекунды от запроса до ответа. Нормальное значение — до 400 мс. Если постоянно 800+ — либо сервер перегружен, либо большие задержки в сети. Также видно количество декодированных каналов и активных клиентов.

Через telnet тоже можно смотреть статус:

telnet localhost 16001

Чтение лога и значения FREEZE / NO CARD

Лог CCcam обычно пишется в /tmp/CCcam.log или /var/log/CCcam.log. Просмотр в реальном времени:

tail -f /tmp/CCcam.log

NO CARD в логе — сервер не нашёл карту для этого CAID. FREEZE — CW не обновился вовремя, картинка застыла. Оба симптома часто указывают на несовпадение CAID или превышение времени ответа.

Ошибки firewall и проброс портов NAT

Если сервер за NAT-роутером — порт 12000 нужно пробросить. Проверить доступность снаружи:

nc -zv your.server.address 12000

Если соединение отваливается сразу — порт закрыт. Смотри правила iptables на сервере:

iptables -L -n | grep 12000

И проброс на роутере: порт 12000 TCP должен форвардиться на локальный IP ресивера.

Проблема несовпадения CAID и provider ID

Это самая хитрая ошибка — линия зелёная, подключение есть, но канал не открывается. Причина: клиент просит CAID которого нет на карте сервера, или provider ID не совпадает. В логе будет что-то вроде no matching reader или просто тишина по этому CAID.

Решение: сверить CAID нужного канала (смотреть в info на ресивере при просмотре канала) с тем что видно в веб-интерфейсе CCcam. Также убедиться что NTP настроен — рассинхронизация времени больше чем на несколько минут ломает шифрование ECM-обмена.

Как выбрать сервер card sharing: технические критерии

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

Аптайм и пинг до сервера ECM

Географическая близость сервера напрямую влияет на ECM time. Сервер в твоей стране даст 20–50 мс пинга, сервер на другом конце Европы — 80–150 мс. Само по себе не критично, но в сумме с задержками обработки это может выходить за 400 мс.

Аптайм лучше проверять не по заявлениям провайдера, а по своему логу за 24–48 часов. Считай количество reconnect-событий в CCcam.log. Больше 2–3 в сутки — сервер нестабильный.

Локальные карты против решары (reshare)

Локальная карта — физическая смарт-карта вридере сервера. Решара — когда сервер сам является клиентом другого сервера и перепродаёт доступ дальше. Цепочка решары из 3+ звеньев добавляет 100–300 мс к ECM time на каждом звене.

В веб-интерфейсе CCcam это видно: локальная карта показывается как local, решара — как share с указанием хопов. Хороший сервер имеет минимум 0–1 хоп для большинства пакетов.

Время отклика ECM и параметр uphops

Нормальный ECM time до 300 мс — всё летает. 300–500 мс — приемлемо. 500–800 мс — начинаются эпизодические фризы при быстрой смене каналов. Больше 800 мс постоянно — такой сервер лучше не использовать.

Измерить можно прямо через веб-интерфейс :16001 — там есть колонка с временем последнего ECM-ответа для каждой карты.

Миграция с CCcam на OScam

OScam — это то куда стоит переходить. Активная разработка, открытый код, лучше работает с EMM (обновление прав на картах), поддерживает кэширование CW между несколькими клиентами. На практике это означает меньше фризов и стабильнее работу при нескольких одновременных просмотрах.

Конвертация C-линий в [reader] секции oscam.server

C-линия в формате cccam:

C: server.example.com 12000 mylogin mypass

Превращается в секцию в /etc/oscam/oscam.server:

[reader]
label         = my_cccam_server
protocol      = cccam
device        = server.example.com,12000
user          = mylogin
password      = mypass
caid          = 0604,1830
reconnecttimeout = 30

Параметр caid опциональный, но лучше указать явно — ограничивает какие запросы идут через этот ридер.

Настройка cccam-протокола в oscam.conf

Базовый /etc/oscam/oscam.conf:

[global]
logfile       = /tmp/oscam.log
maxlogsize    = 100
usrfile       = /tmp/oscam.user

[cs357x]
port          = 0

[camd35]
port          = 0

[newcamd]
port          = 0

[cccam]
port          = 12000

Если хочешь принимать подключения от CCcam-клиентов — секция [cccam] обязательна. Пользователи для входящих подключений описываются в /etc/oscam/oscam.user.

Преимущества кэширования и DCW

OScam умеет кэшировать CW — если два клиента смотрят один канал, второй запрос не идёт на сервер, а берётся из кэша. Это снижает нагрузку и уменьшает ECM time для второго клиента до единиц миллисекунд. CCcam такого не умеет.

Ещё один плюс — preferlocalcards = 1 в oscam.conf заставляет OScam сначала использовать локальные карты и только потом обращаться к удалённым ридерам. Логика приоритизации в cccam значительно примитивнее.