CCcam Server v1: настройка протокола и конфига

Если вы вбили в поиск «cccam server v1» и ожидали найти отдельный дистрибутив или специальную версию программы — её не существует. Это обозначение ревизии протокола обмена, а не отдельного продукта. Разобраться в этой разнице важно до того, как начинать поднимать сервер, иначе полчаса потратите на скачивание «правильного» бинарника, которого нет.

Ниже — полный разбор: что означает v1 в контексте протокола, как устроен CCcam.cfg, как работает рукопожатие, и что делать, когда клиент подключился, но карт нет.

Что такое CCcam server v1 и чем версия протокола отличается от версии бинарника

CCcam как программа выходила в версиях 2.1.4, 2.2.1, 2.3.0 и далее. Это версии бинарника — файла, который вы кладёте в /usr/bin/ или /var/bin/. Версия протокола — другое. Она описывает формат рукопожатия (handshake) при TCP-соединении и то, как сервер и клиент договариваются об обмене. Когда говорят «cccam server v1», имеют в виду именно первую ревизию этого протокола.

Путаница возникает потому, что ни официальной документации, ни чёткой публичной спецификации у CCcam никогда не было. Протокол реверс-инженерили сторонние разработчики — в первую очередь команды OScam и mgcamd. Именно они ввели нумерацию ревизий протокола.

Версия протокола CCcam против версии программы (2.1.4, 2.2.1, 2.3.x)

Бинарник версии 2.1.4 и 2.3.0 могут оба использовать одну ревизию протокола. А могут — разные. Это не коррелирует один к одному. Ранние сборки CCcam использовали то, что сейчас принято называть v1 — упрощённое рукопожатие без части полей, которые появились позже. Более свежие сборки добавили поля в handshake, что и дало появление «v2».

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

Где в логах и в CWS_DOWN отображается версия протокола

В стандартных логах CCcam версия протокола напрямую не пишется, но видна косвенно. OScam в конфиге oscam.server для типа protocol = cccam пишет строку вида:

2026/01/15 14:32:11 s   cccam: client connected, version: 2.3.0, nodeid: A1B2C3D4E5F60718

Строка «version: 2.3.0» — это версия бинарника, которую сервер сообщает при рукопожатии, а не ревизия протокола. Ревизию протокола можно определить по набору полей, которые пришли в handshake-пакете. Если вам нужна именно эта информация — смотрите дамп через Wireshark или включайте максимальный уровень отладки в OScam (loglevel = 255).

В клиентских строках статуса CCcam (веб-интерфейс на порту 16001, путь /status.html) версия отображается в колонке рядом с nodeid подключённого сервера.

Совместимость v1-клиента с современными серверами

Старые ресиверы — Dreambox 500S, 600PVR с прошивками 2009–2011 годов — иногда несут бинарники CCcam, реализующие только раннюю ревизию протокола. С современным OScam-сервером такой клиент может не договориться: рукопожатие проходит, но CW (Control Words) не приходят или приходят с ошибками декодирования.

Решение: в oscam.server для этого клиента выставить версию протокола явно. Параметр cccversion = 2.0.11 заставит OScam имитировать старый бинарник при ответе на handshake, что часто решает проблему совместимости без замены прошивки на ресивере.

Структура файла CCcam.cfg и ключевые директивы сервера

CCcam.cfg — единственный конфигурационный файл сервера. Он текстовый, без секций, без JSON, без XML. Каждая директива — отдельная строка в формате «КЛЮЧ : значение» или «Буква : параметры». Комментарии начинаются с #.

Путь к конфигу: /var/etc/CCcam.cfg и /etc/CCcam.cfg

На прошивках Enigma2 (OpenATV, OpenPLi, OpenViX) стандартный путь — /var/etc/CCcam.cfg. На чистом Debian/Ubuntu или Raspbian — обычно /etc/CCcam.cfg. Некоторые сборки для OpenDreambox кладут его в /etc/cccam/CCcam.cfg.

Если сервер не стартует и в логах нет ошибок конфига — первым делом проверьте, откуда он вообще читает конфиг. Запустите:

strings /usr/bin/CCcam | grep cfg

Это покажет захардкоженный путь в конкретном бинарнике.

Директивы SERVER LISTEN PORT и WEBINFO LISTEN PORT

Два основных порта:

• SERVER LISTEN PORT : 12000 — порт, на котором CCcam принимает входящие клиентские подключения (C-линии с клиентской стороны)
• WEBINFO LISTEN PORT : 16001 — порт веб-интерфейса, где можно посмотреть статус карт и подключений

Менять оба стоит сразу, особенно 12000 — его сканируют. Об этом подробнее в разделе про порты.

Строки F: (friend) для входящих клиентов

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

F: username password uphops downhops {0,0,0,0,0,0,0,0}

Разбор полей:

• username / password — учётные данные клиента
• uphops — сколько хопов вверх клиент может запросить (обычно 0 или 1)
• downhops — сколько хопов вниз сервер отдаст клиенту (0 = только прямые карты, 1 = карты первого уровня)
• {0,0,0,0,0,0,0,0} — восьмибайтная маска флагов; нулевая маска означает «без ограничений по CAID»

Пример минимального рабочего конфига:

# Основной порт раздачи
SERVER LISTEN PORT : 12500

# Веб-интерфейс
WEBINFO LISTEN PORT : 16001

# Логирование
LOG FILE : /var/log/cccam.log
LOG LEVEL : 1

# Отдавать EMM клиентам
ALLOW EMM : yes

# Клиент 1
F: client01 secretpass1 0 1 {0,0,0,0,0,0,0,0}

# Клиент 2 — только прямые карты, без downhops
F: client02 secretpass2 0 0 {0,0,0,0,0,0,0,0}

Риск с downhops: если выставить большое значение (3–5), карта может зациклиться — пройти через несколько серверов и вернуться к источнику. CCcam пытается это детектировать через nodeid, но не всегда успешно. Держите downhops не больше 1 для внешних клиентов.

Параметры ALLOW EMM, DISABLE EMM, GLOBAL LISTEN PORT

ALLOW EMM : yes — разрешает прокидывать EMM (Entitlement Management Messages) от клиента к карте. Нужно, если клиент обновляет подписку через шаринг. Если не нужно — отключайте, снижает нагрузку.

DISABLE EMM : yes — противоположная директива, явно блокирует EMM. Используйте одно из двух.

GLOBAL LISTEN PORT — альтернативная директива для порта, иногда встречается в старых конфигах. Если присутствуют оба — SERVER LISTEN PORT имеет приоритет в большинстве сборок, но лучше оставить что-то одно.

Порты, протокол обмена и сетевое рукопожатие

CCcam работает по TCP. Клиент устанавливает соединение, после чего происходит зашифрованный handshake: обмен nodeid (уникальным идентификатором узла), версией и параметрами сессии. Всё это без TLS — шифрование собственное, симметричное, на основе SHA1 и XOR-трансформаций. Не идеально с точки зрения безопасности, но так работает протокол.

TCP-порт 12000 и его смена для безопасности

Порт 12000 — дефолтный и широко известный. Сканеры типа Shodan и различные скрипты перебора находят серверы на нём за часы. Смените на что-нибудь в диапазоне 20000–50000 — это не защита, но резко снижает автоматизированный шум.

Конфликт с другим сервисом на том же ресивере — частая проблема. На некоторых прошивках Enigma2 порт 12000 занят другим демоном. Проверьте:

netstat -tlnp | grep 12000
# или
ss -tlnp sport = :12000

Если порт занят — меняйте в CCcam.cfg и перезапускайте.

Шифрование рукопожатия и ключи nodeid

При первом старте CCcam генерирует уникальный nodeid — 8-байтный идентификатор узла. Он хранится в файле (обычно /var/etc/.nodeid или /tmp/.cccam_nodeid). Этот ID используется при handshake для идентификации и предотвращения петель в сети раздачи.

Если вы клонируете ресивер или восстанавливаете из бэкапа — удалите файл nodeid и дайте CCcam сгенерировать новый. Два узла с одинаковым nodeid создадут проблемы при шаринге через общий сервер.

Отличие протокола CCcam от newcamd (порт 15000) и mgcamd

Три протокола, которые чаще всего путают:

Протокол	Порт по умолчанию	Шифрование	Особенности
CCcam	12000 (TCP)	Собственное (SHA1+XOR)	Поддержка сети хопов, nodeid
newcamd	15000 (TCP)	DES	Один CAID на соединение, проще
mgcamd	—	—	Клиент, не протокол; использует newcamd/cccam

mgcamd — это клиентская программа, а не отдельный протокол. Он умеет подключаться через newcamd или CCcam. Newcamd проще: одно TCP-соединение — один CAID, шифрование на DES. CCcam мощнее для построения сетей раздачи: поддерживает хопы, может агрегировать карты с нескольких источников.

Смешанные связки типа «CCcam-клиент → OScam-сервер» работают нормально, если OScam настроен на приём CCcam-протокола. Обратная связка — OScam в роли клиента к CCcam-серверу — тоже поддерживается через тип reader = cccam в oscam.server.

Проброс портов на роутере и работа за NAT

Стандартная схема: в настройках роутера создаёте правило Port Forwarding — внешний TCP-порт (например, 12500) → внутренний IP ресивера, порт 12500. После этого клиент с интернета может подключиться по вашему внешнему IP.

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

# С другой машины в интернете:
nc -zv your.external.ip 12500
# или
telnet your.external.ip 12500

Если соединение есть, но CCcam не отвечает — проблема в файрволе на самом ресивере. Проверьте iptables:

iptables -L INPUT -n | grep 12500

Двойной NAT и CGNAT — отдельная головная боль. Если провайдер выдаёт вам серый IP (а это сейчас нормально для мобильного интернета и части кабельных операторов), проброс порта не поможет — внешний IP принадлежит не вашему роутеру. В этом случае единственный рабочий вариант — VPN-туннель (WireGuard или OpenVPN) до VPS с белым IP, где поднят CCcam или обратный прокси.

Настройка раздачи карт: C-линии, шаринг и CAID/provider

Логика простая: сервер описывает клиентов через F-линии, клиент описывает сервер через C-линию. Это два конца одного соединения.

Формат C-линии у клиента: C: host port user password

На стороне клиента в его CCcam.cfg:

C: 192.168.1.100 12500 client01 secretpass1

Или через интернет:

C: 203.0.113.45 12500 client01 secretpass1

Параметры: хост (IP или доменное имя), порт, логин, пароль. Логин и пароль должны точно совпасть с тем, что прописано в F-линии на сервере. Регистр имеет значение.

Если клиент — OScam, то C-линия не используется. Вместо этого в /etc/oscam/oscam.server создаётся ридер:

[reader]
label = my_cccam_server
protocol = cccam
device = 203.0.113.45,12500
user = client01
password = secretpass1
cccversion = 2.3.0
reconnecttimeout = 30

Ограничение раздаваемых CAID и provider ID

По умолчанию CCcam-сервер отдаёт клиенту все карты, до которых он имеет доступ. Если нужно ограничить — используется маска в F-линии или директива CAID-фильтрации.

Пример: разрешить клиенту только CAID 0x0500 (Viaccess):

F: client01 secretpass1 0 1 {0,0,0,0,0,0,0,0} # без ограничений

Для тонкой фильтрации по CAID лучше использовать OScam в роли сервера — там фильтры настраиваются гибко через параметры ident и caid в профилях. Нативный CCcam-сервер с фильтрацией CAID работает менее удобно.

Контроль числа подключений и downhops

Одна F-линия = один клиент. Если хотите, чтобы один пользователь мог подключиться с двух устройств — создайте две F-линии с разными логинами. CCcam не имеет встроенного параметра «максимум N соединений на одну F-линию» — это ограничение реализуется на уровне логинов.

downhops в F-линии контролирует глубину: 0 означает «отдаю только карты, которые физически воткнуты в мой ресивер», 1 — «отдаю и карты, которые сам получил с одного хопа выше». Держите это значение минимальным.

Логи /var/log и режим отладки -d

Стандартный лог пишется по пути, указанному в директиве LOG FILE. Если не указан — часть сборок пишет в /var/log/cccam.log, часть — в stdout.

Для диагностики запустите CCcam вручную с флагом отладки:

# Остановите демон
/etc/init.d/CCcam stop

# Запустите в режиме отладки в терминале
CCcam -d

В этом режиме в консоль пойдёт детальный вывод: попытки подключения, handshake, ECM-запросы, ответы источника. Это самый быстрый способ понять, почему карты не приходят. Смотрите строки ECM, CW и ERROR — они скажут всё.

Устранение типовых ошибок подключения CCcam server

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

Статус 'CWS_CONNECT failed' и причины

CWS_CONNECT failed означает, что TCP-соединение не установлено вообще. Причины по убыванию частоты:

1. Неправильный IP или порт в C-линии — опечатка
2. Порт закрыт на файрволе сервера или не проброшен на роутере
3. Сервер не запущен или упал
4. Провайдер блокирует нестандартные TCP-порты (редко, но бывает)
5. Двойной NAT / CGNAT без VPN-туннеля

Диагностика: telnet с клиентской машины на адрес и порт сервера. Если соединение не открывается — это сетевая проблема, не проблема CCcam. Разбирайте маршрут до того, как лезть в конфиг.

Клиент онлайн, но нет карт (no cards / 0 cards)

Соединение есть, handshake прошёл, но в статусе клиента — 0 cards. Это одна из самых распространённых ситуаций при работе с cccam server v1 совместимыми клиентами. Проверяйте по порядку:

1. uphops на клиенте — если клиент запрашивает uphops = 0, а сервер может отдать только карты с хопа выше — ничего не придёт
2. downhops на сервере в F-линии — выставлено 0, а карта пришла с хопа? Она не пробросится клиенту
3. Маска CAID в F-линии — если маска ненулевая и не включает нужный CAID
4. Источник сам не имеет активных карт — проверьте статус самого сервера, не только клиента
5. Истёкший доступ — если сервер подключён к платному источнику с ограниченным сроком

FREEZE и долгое время отклика ECM

Картинка freezes — ECM-запрос уходит к источнику, но CW возвращается слишком поздно. DVB-декодер не успевает раздекодировать пакет до смены ключа.

Нормальное время ответа ECM — до 500 мс. Если видите в логах значения 1500–3000 мс — источник перегружен или пинг слишком высокий. Ping до сервера больше 100–150 мс уже даёт риски freeze, особенно на каналах с частой сменой CW (каждые 10 секунд).

Высокий пинг — системная проблема, конфигом не лечится. Меняйте источник или поднимайте промежуточный кеширующий узел OScam ближе к клиентам.

Другая причина freeze: несовпадение системного времени между сервером и клиентом. Расхождение больше 5–10 секунд ломает некоторые реализации протокола. Проверьте NTP на обоих.

Ошибки прав доступа к CCcam.cfg и автозапуск

CCcam.cfg должен быть читаем для пользователя, от которого запускается демон:

chmod 644 /var/etc/CCcam.cfg
chown root:root /var/etc/CCcam.cfg

После обновления прошивки Enigma2 права на файлы в /var/etc/ иногда сбрасываются. Если сервер не стартует после прошивки — первым делом проверьте права.

Автозапуск на Enigma2 обычно через скрипт в /etc/rc3.d/ или через плагин-обёртку. На чистом Debian создайте systemd unit:

[Unit]
Description=CCcam Card Sharing Daemon
After=network.target

[Service]
ExecStart=/usr/bin/CCcam
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Сохраните в /etc/systemd/system/cccam.service, затем:

systemctl daemon-reload
systemctl enable cccam
systemctl start cccam

После этого демон поднимется автоматически при перезагрузке и перезапустится при падении.