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

Если вы читаете это, значит уже знаете, что такое C-линия и зачем нужен шаринг. Этот материал — не введение в тему. Это разбор того, как в cccam 2026 году поднять рабочий стек, не сломать его при первом же обновлении образа и понять, когда пора переходить на OScam, а когда CCcam ещё вполне справляется.

Протокол живёт дольше, чем многие ожидали. Демон давно заброшен разработчиками, последняя стабильная ветка — 2.3.x — не получала обновлений уже несколько лет. Но порт 12000 до сих пор слушает на тысячах ресиверов по всему миру. Разберёмся, почему и что с этим делать.

Актуален ли CCcam в 2026 году

Состояние протокола CCcam сегодня

Протокол CCcam — не демон CCcam — живёт вполне неплохо. Это разные вещи, и путаница здесь дорого обходится. Сам бинарник CCcam давно не обновляется, имеет известные утечки памяти на длинных сессиях и плохо работает с новыми DVB-стеками в ядрах 5.x+. Но протокол обмена CWS (Cardsharing Words Stream), который все называют "cccam-протоколом", поддерживается в OScam, Wicardd и других демонах.

На практике в cccam 2026 большинство провайдеров держат C-линии именно через OScam с эмуляцией cccam-протокола. Клиент получает стандартную C-строку вида C: host 12000 user pass, не подозревая, что на другом конце вовсе не CCcam-демон.

Порт по умолчанию — 12000. WebInfo-интерфейс — 16001. Оба прописываются в CCcam.cfg директивами SERVER LISTEN PORT и WEBINFO PORT. Менять их имеет смысл, если на машине уже занят нужный порт или вы хотите скрыть стандартный эндпоинт.

CCcam против OScam: когда что выбирать

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

OScam — открытый проект, обновляется регулярно, поддерживает гибкую логику reader/account с приоритетами, имеет нормальный веб-интерфейс и детальное логирование. CCcam в сравнении — чёрный ящик. Вы не увидите, где именно рассыпается ECM-запрос и через сколько hops прошёл ответ.

Хороший компромисс: OScam держит физические ридеры и локальные карты, а C-линии клиентов обслуживаются через модуль [protocol] cccam внутри OScam. Так вы получаете совместимость с клиентами, которые ждут CCcam, и всю гибкость OScam внутри.

Поддержка последней версии 2.3.x на современных ресиверах

Версия 2.3.x запускается на Enigma2-образах вроде OpenPLi, OpenATV, DreamElite — при условии, что бинарник собран под нужную архитектуру (mipsel, armv7, aarch64). На образах с glibc 2.31+ возможны проблемы с зависимостями. Проверяйте через ldd /var/bin/CCcam — если видите "not found" в зависимостях, запускаться не будет.

На Raspberry Pi с LibreELEC или CoreELEC нативный CCcam-демон работает нестабильно. Там лучше сразу ставить OScam.

Установка и структура файлов CCcam

Размещение бинарника и прав доступа (/var/bin, chmod 755)

Бинарник кладётся в /var/bin/CCcam. На некоторых образах путь другой — /usr/bin/CCcam или /usr/local/bin/CCcam. Проверить, что демон нашёлся: which CCcam.

После копирования обязательно:

chmod 755 /var/bin/CCcam
chown root:root /var/bin/CCcam

Без исполняемого бита демон просто не запустится, и никакого внятного сообщения об ошибке не будет. Проверка запущенного процесса:

ps aux | grep CCcam

Если строка есть — демон жив. Если нет — смотрите лог: /tmp/cccam.log или /var/log/CCcam.log в зависимости от образа.

Основные файлы: CCcam.cfg, CCcam.channelinfo, CCcam.providers

CCcam.cfg — главный конфиг, там всё: C-линии, F-линии, серверные параметры. CCcam.channelinfo — маппинг CAID/SID на человекочитаемые названия каналов, нужен только для WebInfo. CCcam.providers — база провайдеров для отображения в интерфейсе.

Последние два файла необязательны для работы шаринга. Если их нет — CCcam запустится нормально, просто WebInfo будет показывать сырые hex-идентификаторы вместо названий.

Важный момент: на некоторых образах Enigma2, особенно на основе OE-A 4.x, папка /etc/ монтируется из tmpfs и сбрасывается при обновлении образа. Кладите конфиги в /var/etc/ — эта директория обычно сохраняется. Проверить, где ищет конфиг ваша версия CCcam: find / -name CCcam.cfg 2>/dev/null.

Автозапуск через init.d или systemd на Enigma2

На классических Enigma2-образах с System V init скрипт автозапуска кладётся в /etc/init.d/CCcam. Минимальный рабочий скрипт:

#!/bin/sh
case "$1" in
  start)
    /var/bin/CCcam &
    ;;
  stop)
    killall CCcam
    ;;
  restart)
    $0 stop
    sleep 1
    $0 start
    ;;
esac

Сделать исполняемым и добавить в автозапуск: chmod +x /etc/init.d/CCcam && update-rc.d CCcam defaults. На образах с systemd (встречается на x86-сборках) создаётся юнит в /etc/systemd/system/cccam.service с Restart=always.

Настройка CCcam.cfg: разбор ключевых параметров

C-линии (C: host port user pass) и параметры { 0:0:2 }

Синтаксис C-линии:

C: hostname 12000 username password { 0:0:2 }

Фигурные скобки в конце — необязательный блок CWS-флагов. Формат { reshare:reshare_distance:number_of_retries }. Значение 0:0:2 означает: не ретранслировать карты этого сервера дальше (reshare=0), дистанция 0, два повтора при ошибке.

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

Несколько C-линий — несколько строк подряд. CCcam будет использовать их по очереди при недоступности основной. Порядок имеет значение: первая строка — приоритетный сервер.

F-линии для раздачи: F: user pass uphops downhops

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

F: clientuser clientpass 1 0 { 0:0:0 }

Здесь 1 — uphops (сколько хопов вверх клиент может "видеть"), 0 — downhops (сколько хопов вниз от клиента разрешено ретранслировать). Ставить uphops больше 1 без понимания последствий — плохая идея: это открывает клиенту карты из вышестоящих звеньев цепочки, что обычно нежелательно.

downhops=0 означает, что клиент не может дальше раздавать карты. Если вы строите цепочку шаринга — увеличивайте аккуратно, каждый дополнительный хоп добавляет задержку и снижает стабильность.

Серверные директивы: SERVER LISTEN PORT, ALLOW TELNET, WEBINFO

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

SERVER LISTEN PORT : 12000
ALLOW TELNET : no
WEBINFO LISTEN PORT : 16001
WEBINFO ALLOW EXTERNAL ACCESS : no

ALLOW TELNET : no — выключить обязательно. Telnet CCcam не шифрует трафик, и открытый telnet-порт наружу — это прямая дыра. Аналогично с WebInfo: WEBINFO ALLOW EXTERNAL ACCESS : no ограничивает доступ к интерфейсу только с localhost. Если нужен удалённый доступ к WebInfo — проксируйте через SSH-туннель, не открывайте порт 16001 напрямую в интернет.

Порт 12000 тоже лучше прикрыть на уровне firewall для всего, кроме известных IP клиентов. iptables-правило: iptables -A INPUT -p tcp --dport 12000 -s CLIENT_IP -j ACCEPT && iptables -A INPUT -p tcp --dport 12000 -j DROP.

Параметры стабильности: DISABLE EMM, KEEPALIVE, RECV TIMEOUT

Три параметра, которые чаще всего влияют на стабильность в длительных сессиях:

DISABLE EMM : yes
KEEPALIVE TIMEOUT : 30
RECV TIMEOUT : 5000

DISABLE EMM : yes — отключить обработку EMM-сообщений (Entitlement Management Messages). На клиентских установках это почти всегда нужно: EMM генерирует лишний трафик и нагрузку, а нужны они только при обновлении ключей на физической карте. KEEPALIVE TIMEOUT : 30 — интервал keepalive в секундах; слишком большое значение приводит к тому, что упавшее соединение обнаруживается поздно. RECV TIMEOUT : 5000 — таймаут ожидания ответа в миллисекундах; при пинге до сервера больше 200ms стоит увеличить до 8000.

Как выбрать поставщика C-линий: критерии без названий

На что смотреть: аптайм, локальные карты, пинг до сервера

Первое — пинг. Telnet до хоста на порт 12000 — быстрее 80ms это хорошо, до 150ms терпимо, выше 200ms начнутся подфризы на HD-каналах. ECM-запрос должен укладываться в 300-500ms суммарно, иначе декодер просто не успевает.

Второе — локальные карты против reshare. Сервер с физической картой в ридере даёт ECM-time 100-300ms. Reshare от другого сервера добавляет как минимум ещё один round-trip и чужой процессинг. Спрашивайте у провайдера прямо: карты локальные или ретранслируются. Если уходят от ответа — скорее всего reshare.

Третье — аптайм и подтверждённая история. Сервис, работающий меньше полугода, — лотерея. Нормальный аптайм для шаринг-сервера — 99%+ по месяцу.

Признаки нестабильного шаринга (reshare, высокий uphops)

В WebInfo (порт 16001) смотрите на колонку "hops" у подключённых ридеров. Значение 1 — карта локальная или в первом звене. Значение 3+ — глубокий reshare, и каждый хоп может стать узким местом или точкой отказа.

Ещё один признак: ECM-time скачет в широких пределах — то 200ms, то 1500ms. Это признак нестабильного промежуточного звена в цепочке. На локальной карте ECM-time стабилен с дисперсией ±50ms.

Высокий uphops в F-линии у клиента тоже сигнал: честный сервер не нуждается в том, чтобы клиент видел несколько вышестоящих уровней. Если вам дают C-линию с рекомендацией поставить { 2:2:2 } — это стоит изучить внимательнее.

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

Шаринг карты, на которую у вас оформлена подписка, для личного просмотра на нескольких устройствах в доме — правовая ситуация, которую каждый оценивает самостоятельно. Передача доступа третьим лицам, особенно коммерческая, — это другая история и другая ответственность. Здесь не место для юридических советов, но игнорировать этот контекст тоже глупо.

Диагностика частых проблем CCcam

FreezeOnBlack и фриз каналов: причины и таймауты

FreezeOnBlack — канал замерзает и уходит в чёрный экран — почти всегда означает, что ECM-запрос не вернулся вовремя. Декодер не получил свежий Control Word и остановил декриптование.

Нормальный ECM-time: 100-500ms. Если в WebInfo видите 800ms+, начинаются артефакты. Выше 1500ms — устойчивые фризы. Выше 3000ms — канал уходит в чёрный экран или показывает мозаику.

Первое, что проверяем: пинг до сервера (ping hostname) и ECM-time в WebInfo одновременно. Если пинг хороший, а ECM большой — проблема на стороне сервера или в цепочке reshare. Если пинг плохой — смотрим маршрут (traceroute hostname) и сетевую конфигурацию локально.

Увеличение RECV TIMEOUT в CCcam.cfg помогает избежать чёрного экрана, но не решает причину — просто даёт демону больше времени ждать ответ. Реальное решение — более быстрый сервер или другая C-линия.

Нет ECM / долгий ECM time: чтение лога CCcam

Лог CCcam по умолчанию пишется в /tmp/cccam.log. Уровень детализации задаётся директивой DEBUG LEVEL : 1 (значения 0-12, чем больше — тем подробнее, но тем быстрее растёт файл).

Ищем в логе строки вида:

ECM: CAID=0500 SID=1234 - answered in 245ms
ECM: CAID=0500 SID=1234 - no answer after 5000ms

"No answer after" — конкретный ридер не отвечает. Смотрите, какой именно ридер (C-линия) это генерирует. Если это единственная C-линия — проблема с сервером. Если несколько — возможно, CAID не поддерживается вашими C-линиями вообще.

Проверка через telnet: telnet hostname 12000. Если подключение не устанавливается — порт закрыт или хост недоступен. Если подключается и сразу рвётся — неверные учётные данные или аккаунт заблокирован.

C-линия не подключается (статус OFF): порты и firewall

В WebInfo статус "OFF" напротив C-линии означает: CCcam не может установить TCP-соединение с сервером или аутентификация провалилась.

Чек-лист по порядку:

1. Проверить доступность хоста: ping hostname
2. Проверить порт: telnet hostname 12000 или nc -zv hostname 12000
3. Проверить firewall на ресивере: iptables -L -n | grep 12000
4. Если ресивер за роутером — убедиться, что исходящий TCP 12000 не блокируется
5. Проверить время на ресивере: date — рассинхрон больше 5 минут ломает handshake CCcam

Про время — отдельно. CCcam использует timestamp в handshake-протоколе. Если часы ресивера уехали на 10+ минут от реального времени, сервер отклонит соединение, и лог даст невнятную ошибку. Синхронизация: ntpdate pool.ntp.org или настройка NTP-демона через образ.

Отдельная история — ресиверы за CGNAT. Если провайдер использует Carrier-Grade NAT, у вас нет реального публичного IP, и проброс порта 12000 для приёма входящих соединений невозможен без VPN-туннеля (WireGuard или OpenVPN на VPS). Для исходящих C-линий CGNAT обычно не проблема — TCP-сессия инициируется с вашей стороны.

Перегрузка процессора и утечки на старых образах

CCcam 2.3.x имеет известную проблему с утечкой памяти при длительной работе и большом количестве активных C-линий. На ресивере с 256MB RAM через 3-7 дней непрерывной работы процесс может занимать 80%+ памяти.

Мониторинг: top или cat /proc/$(pidof CCcam)/status | grep VmRSS. Если RSS растёт линейно день за днём — утечка есть. Решение на уровне образа — добавить cron-перезапуск раз в сутки: 0 4 * * * /etc/init.d/CCcam restart.

Высокий CPU (постоянно выше 30% на простаивающем демоне) — часто результат включённого DEBUG LEVEL с высоким значением или включённых EMM при большом числе каналов. Устанавливайте DEBUG LEVEL : 0 в продакшен-конфиге и DISABLE EMM : yes.

Конфликт за DVB-адаптер при одновременном запуске CCcam и OScam — реальная ситуация на одночиповых ресиверах. Два демона не могут одновременно держать /dev/dvb/adapter0/ca0. Правильная схема: OScam владеет физическим ридером, CCcam работает только как протокольный прокси без доступа к железу — директива USE NEWCAMD : no и отсутствие локальных ридеров в CCcam.cfg.

Итог по cccam 2026

Протокол жив, демон — устарел. Для новых установок в cccam 2026 рациональнее OScam с поддержкой cccam-протокола: лучше диагностика, нет утечек памяти, активная разработка. CCcam как бинарник оправдан только там, где OScam физически не запускается или того требует конкретный образ. Конфиг CCcam.cfg с правильными таймаутами, закрытым WebInfo и отключённым EMM — вполне рабочее решение на годы вперёд.