Настройка CCcam в 2026: конфиг, порты, OScam

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

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

CCcam — это протокол карточного шаринга. Сервер читает смарт-карту, получает control word (CW) и передаёт его клиенту по сети. Клиент подставляет CW в декодер и открывает зашифрованный канал. Всё это происходит каждые несколько секунд — примерно каждые 10 секунд для большинства пакетов DVB.

Принцип работы протокола CCcam

Протокол работает по TCP. Клиент подключается к серверу на порт (по умолчанию 12000), авторизуется, и дальше идёт обмен ECM/EMM-запросами и ответами с control word. Шифрование — собственное, не TLS. Это одна из причин, почему протокол считается устаревшим с точки зрения безопасности.

Задержка между ECM-запросом и получением CW называется ECM time. Если она выше 600 мс — канал будет подвисать или открываться с паузой. При нормальном сервере и хорошем пинге ECM time держится в районе 100–300 мс.

Статус разработки: почему версия 2.3.x остаётся последней

Официальная разработка CCcam остановилась на версиях 2.3.0 и 2.3.2. Последние обновления выходили ещё несколько лет назад. Никаких новых веток нет, репозиторий не развивается. Бинарники под ARM и MIPS для Enigma2-ресиверов существуют, но это сборки от комьюнити под старую кодовую базу.

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

CCcam против OScam и mgcamd: что выбрать в 2026

Для нового сервера в 2026 году ответ однозначный: OScam. Он активно поддерживается, умеет работать с большинством современных карт, имеет нормальный веб-интерфейс и подробное логирование. При этом OScam умеет эмулировать CCcam-протокол — ваши клиенты с C-line даже не заметят разницы.

mgcamd — это клиентское ПО под Enigma2, он не заменяет серверный стек. Его можно использовать вместо CCcam на стороне ресивера, но это отдельная история. Для серверной части выбор между CCcam и OScam — и OScam выигрывает по всем параметрам.

Установка и базовая настройка CCcam-сервера

Если вы всё-таки ставите именно CCcam (например, потому что конкретный ресивер не тянет OScam или это требование провайдера), вот рабочая схема без лишних деталей.

Требования: ресивер Enigma2 или Linux-сервер

CCcam можно запустить на Enigma2-ресивере (Dreambox, Vu+, Gigablue и аналогах), на обычном Linux-сервере x86 или ARM-машине типа Raspberry Pi. Для x86 нужен бинарник под вашу архитектуру — не перепутайте ARMv7 и ARMv8, иначе получите Exec format error при запуске.

Минимальные требования по ресурсам смешные: CCcam ест меньше 10 МБ RAM и почти не грузит CPU. Проблем с производительностью на любом железе после 2015 года не будет.

Размещение бинарника и прав доступа

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

chmod 755 /usr/bin/CCcam

Без этого он просто не запустится. Проверить права: ls -la /usr/bin/CCcam — должно быть -rwxr-xr-x.

Запуск через init.d на Enigma2:

/etc/init.d/CCcam start

На обычном Linux с systemd создаётся unit-файл в /etc/systemd/system/cccam.service и делается systemctl enable cccam. Ничего сложного.

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

Основной конфиг — /etc/CCcam.cfg. На некоторых сборках Enigma2 это /var/etc/CCcam.cfg — зависит от образа. Логи по умолчанию пишутся в /tmp/CCcam.log или /var/log/CCcam.log.

Если CCcam не видит конфиг при старте — проверьте, что путь совпадает с тем, что прописан в init-скрипте. Иногда скрипт жёстко указывает на /var/etc/CCcam.cfg, а файл лежит в /etc/.

Разбор файла CCcam.cfg: ключевые директивы

Это самая важная часть. Неправильный конфиг — главная причина 90% проблем. Разберём по строкам.

Строки C: line для подключения к серверу

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

C: hostname port username password

Например:

C: share.example.com 12000 myuser mypassword

Можно добавить несколько C-line для разных серверов — CCcam будет использовать их по очереди или одновременно. Порт 12000 — стандартный для cccam 2026, но провайдер может указать другой.

Строки F: line для раздачи клиентам

F-line — это аккаунт для клиента, который подключается к вашему серверу. Формат:

F: username password uphops downhops

Например:

F: client1 pass123 1 1

Здесь uphops и downhops — это глубина шаринга. uphops определяет, насколько далеко "вверх" клиент может запрашивать карты, downhops — насколько далеко "вниз" он может их передавать дальше.

Безопасные значения для простой схемы "один сервер — один клиент": uphops 1, downhops 0. Если поставить оба в 2+ при наличии нескольких серверов, соединённых между собой, получите шаринговое кольцо — карта начнёт гулять по кругу, сервер уйдёт в петлю и нестабильность гарантирована.

Параметры SERVER LISTEN PORT и WEBINFO

В конфиге прописывается порт, на котором сервер слушает входящие подключения:

SERVER LISTEN PORT = 12000

И порт веб-интерфейса для мониторинга:

WEBINFO LISTEN PORT = 16001

По адресу http://your-server:16001 открывается страница со статусом подключений, активными картами и ECM time. Без логина она не откроется, если не указать:

WEBINFO USERNAME = admin
WEBINFO PASSWORD = yourpassword

Это частая причина "WEBINFO недоступен" — люди забывают про эти две строки.

Настройки шаринга: SHARE LIMITS и кэш

Кэш CW позволяет отдавать одинаковые запросы без повторного обращения к карте:

CACHEEX = 1

Директивы SHARE LIMITS ограничивают, какие карты и провайдеры доступны конкретному клиенту. Если не задать явно — клиент получит доступ ко всему. Для production-сервера это нужно настроить.

И отдельно про кодировку. Файл CCcam.cfg должен быть в Unix-кодировке с переводами строк LF. Если редактировали файл в Notepad на Windows — он сохранит CRLF, и CCcam просто не прочитает конфиг корректно. Проверить и исправить: dos2unix /etc/CCcam.cfg. Это не баг сборки — это фича парсера, которую никто не фиксил годами.

Переход с CCcam на OScam с сохранением протокола

Хорошая новость: переход на OScam не ломает существующих клиентов. Они продолжают подключаться по той же C-line к тому же порту — OScam просто отвечает на CCcam-протокол.

Зачем мигрировать: стабильность и поддержка картоприёмников

OScam поддерживает современные карты, обновляется регулярно и имеет нормальную документацию. Логи читаемые — вы видите конкретную причину проблемы, а не "connected/disconnected" без деталей. Веб-интерфейс на порту 8888 (по умолчанию) показывает всё: ECM time, активные сессии, статус ридеров. CCcam рядом с этим выглядит как отладка вслепую.

Эмуляция cccam в oscam.server и oscam.conf

Чтобы OScam подключился к вышестоящему CCcam-серверу, в файле /etc/oscam/oscam.server создаётся reader:

[reader]
label = my_cccam_reader
protocol = cccam
device = share.example.com,12000
user = myuser
password = mypassword
group = 1

Чтобы OScam принимал входящие подключения от CCcam-клиентов, в /etc/oscam/oscam.conf добавляется секция:

[cccam]
port = 12000

И аккаунт клиента в /etc/oscam/oscam.user:

[account]
user = client1
pwd = pass123
group = 1
cccmaxhops = 1

Параметр cccmaxhops — это аналог downhops в F-line CCcam. Значение 1 — безопасно.

Веб-интерфейс OScam поднимается настройкой в oscam.conf:

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

Сопоставление C-line CCcam и reader в OScam

Прямое соответствие выглядит так:

CCcam (CCcam.cfg)	OScam (oscam.server)
C: host port user pass	protocol = cccam, device = host,port, user = user, password = pass
SERVER LISTEN PORT = 12000	[cccam] port = 12000
F: user pass uphops downhops	[account] user/pwd + cccmaxhops
WEBINFO LISTEN PORT = 16001	[webif] httpport = 8888

Если у вас старый клиент на базе CCcam 2.3.x, а сервер переехал на OScam — несовпадение версий протокола иногда вызывает проблемы рукопожатия. В логах OScam это видно как CCcam: handshake failed. Решение: убедиться, что в oscam.conf нет ограничений по версии CCcam-протокола, или обновить клиентский CCcam до 2.3.2.

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

Большинство проблем укладываются в четыре категории. Разберём каждую.

Статус линии: offline, connecting, no card

offline / connecting — сетевая проблема. Порт недоступен. Проверяется просто:

telnet your-server 12000

Если соединение не устанавливается — либо сервер не запущен, либо firewall на сервере, либо порт заблокирован на стороне провайдера. Некоторые ISP блокируют нестандартные порты. Решение — смена порта на 443 или 80 (их почти никто не блокирует).

no card — сервер доступен, но карты нет. Либо сервер сам не имеет активной карты, либо ваш аккаунт не имеет доступа к нужной группе карт.

Каналы фризят или картинка появляется через паузу

Это почти всегда высокий ECM time или нестабильная линия. Проверить ECM time можно через WEBINFO CCcam или веб-интерфейс OScam. Норма — до 300–600 мс. Если постоянно 800+ мс — сервер перегружен или пинг до него плохой.

Другая причина — провайдер канала перешёл на частую смену ключей (CWPI — Control Word Period Interval менее 10 секунд). В этом случае протокол физически не успевает доставить новый CW до истечения старого. Это проблема не настройки, а самого провайдера вещания, и шаринг здесь просто не справится.

Проблемы ECM time и высокий пинг

ECM time = время обработки запроса на сервере + сетевая задержка в обе стороны. Если пинг до сервера 150 мс, ECM time не может быть ниже 300 мс физически. Выбирайте сервер с пингом до 50 мс для нормальной работы.

В OScam ECM time виден в реальном времени в веб-интерфейсе (http://server:8888). В CCcam — только через WEBINFO на порту 16001, и то данные там менее подробные.

Закрытые порты и блокировки со стороны сети

Порт 12000 — нестандартный, его блокируют чаще, чем 80/443. Если вы настраиваете сервер для клиентов за NAT или в корпоративных сетях — предусмотрите возможность работы на порту 443. В CCcam.cfg это меняется одной строкой SERVER LISTEN PORT = 443, в OScam — соответственно в секции [cccam].

Также проверьте firewall на самом сервере. На Debian/Ubuntu:

ufw allow 12000/tcp

Или через iptables:

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