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

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

Что означает «CCcam server v1» и версии протокола

Здесь путаются почти все. Когда кто-то говорит «cccam server v1», он может иметь в виду две совершенно разные вещи: версию протокола обмена или версию бинарника программы. Это не одно и то же, и смешивать их — первый шаг к непонятным багам.

Версия протокола CCcam против версии программы

Бинарник CCcam существует в версиях вроде 2.1.3, 2.1.4, 2.2.1, 2.3.0 — это просто номер сборки программы. Протокол обмена — это отдельная история. Он описывает формат рукопожатия (handshake), структуру ECM-запросов и ответов, метод шифрования начального обмена.

То, что принято называть «v1», — это оригинальный протокол CCcam, который использовался в версиях бинарника примерно до 2.2.x. Он работает поверх TCP, по умолчанию порт 12000. Никакого официального документа с названием «CCcam protocol v1» не существует — это разговорное обозначение, которое прижилось в сообществе.

Как сервер и клиент согласуют версию при handshake

При установке соединения клиент передаёт серверу строку с номером версии CCcam и build number — что-то вроде CCcam 2.1.4 build 3076. Сервер смотрит на эту строку и решает, пускать клиента или нет. Старые серверы на 2.1.x нередко отказывают клиентам с более новой версией — они просто не понимают строку и сбрасывают соединение.

Именно поэтому в OScam есть параметр cccversion — им вручную задаётся, что клиент представится серверу. Укажи 2.1.4, и старый сервер тебя примет.

Где v1 ещё встречается и почему не стоит на нём останавливаться

Старые конфиги, форумные гайды 2010–2015 годов, некоторые прошивки для ресиверов на базе старых чипов STi — везде там фигурирует «v1». Многие эмуляторы (NewCS, MPCS) декларируют совместимость именно с этим форматом протокола.

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

Настройка CCcam.cfg на стороне сервера

Файл конфигурации — это всё. Одна неверная директива, и сервер молча не выдаёт карты клиентам. Начнём с того, где этот файл вообще искать.

Расположение файла: /var/etc/CCcam.cfg и /etc/CCcam.cfg

На Enigma2-ресиверах (VU+, Dreambox и клоны) файл лежит в /var/etc/CCcam.cfg. На некоторых образах — в /etc/CCcam.cfg. Конкретное место зависит от того, куда установлен плагин и какой образ залит.

Частая ловушка: правишь /etc/CCcam.cfg, а сервер читает /var/etc/CCcam.cfg. Изменения не применяются, перезапуск ничего не меняет, и ты час теряешь на отладку. Проверь симлинки командой ls -la /etc/CCcam.cfg — нередко это просто ссылка на /var/etc/CCcam.cfg.

Директива F: строка — логин, пароль, uphops, downhops

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

F: username password 1 0 0

Третье число — uphops: сколько хопов карты сервер принимает от этого клиента (входящая глубина). Четвёртое — downhops: сколько хопов клиент может раздать дальше (0 значит — только для себя). Пятое число — флаг allow_sidescanning.

Если поставить uphops = 0, клиент вообще не передаёт серверу свои карты. Если downhops = 0, клиент не может стать промежуточным сервером для следующего уровня. Вот почему у многих «карты есть, но не раздаются» — downhops стоит 0, а клиент ниже по цепочке ничего не видит.

Параметры SERVER LISTEN PORT и ALLOW TELNET

Базовый блок сервера выглядит так:

SERVER LISTEN PORT : 12000
ALLOW TELNET : YES
TELNET PORT : 16001
WEBINFO PORT : 16002

Порт 12000 — для клиентских подключений. Порты 16001 и 16002 — для управления и статистики. ALLOW TELNET открывает консольный доступ, что удобно при отладке, но опасно на публичном IP: порт 16001 не требует аутентификации по умолчанию. Если сервер смотрит в интернет — закрой его файрволом или вообще выключи.

Раздача локальных карт через SERVER ECM/EMM

Чтобы сервер раздавал карту из локального смарт-кард ридера, нужно убедиться, что CCcam видит ридер и добавляет его в share-лист автоматически. Директивами IGNORE CAID и ALLOW CAID фильтруется, какие CAID попадают в раздачу:

ALLOW CAID : 0500
IGNORE CAID : 1234

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

Подключение клиента: строка C: и проверка соединения

На стороне клиента (другого ресивера или OScam) подключение к серверу задаётся строкой C:.

Синтаксис C: hostname port username password

Минимальный формат:

C: my.server.host 12000 myuser mypassword no

Расширенный вариант с фильтром по CAID и провайдеру:

C: my.server.host 12000 myuser mypassword no { 0500:030B00 }

Фигурные скобки задают фильтр: CAID:ProviderID. Если указать неверный CAID или опечататься в provider ID — клиент подключится, карты в share-листе будут видны, но ECM-запросы к ним уходить не будут. Выглядит как рабочее соединение, а декодирования нет. Это одна из самых коварных ошибок.

Дополнительные флаги: wantemus, no/yes

Пятый параметр в строке C: — флаг no/yes, он управляет тем, хочет ли клиент получать EMM от сервера. Большинству клиентов нужно no. yes нужен только если сервер должен обновлять ключи карты клиента — редкий сценарий.

Проверка статуса через webif (порт 16001) и telnet

Веб-интерфейс CCcam доступен по адресу http://[ip-ресивера]:16001 (или 16002, зависит от конфига). Там три важных раздела: Connected clients, Connected servers и Shares.

В Shares смотри столбцы: CAID (тип карты), hop (количество промежуточных серверов до карты), ECM time (время ответа в миллисекундах). Hop = 0 — карта локальная. Hop = 1 — карта на первом сервере в цепочке. Чем больше хопов, тем выше вероятность фриза.

Чтение лог-файла и команды CCcam -s

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

tail -f /tmp/CCcam.log

Команда CCcam -s выводит текущее состояние демона в терминал — активные соединения, share-лист, статистику ECM. Работает только если CCcam запущен и telnet включён.

Отладка типичных ошибок протокола v1

Большинство проблем с cccam server v1 укладываются в несколько сценариев. Их несложно диагностировать, если знать куда смотреть.

Connection reset / login failed

«Login failed» в логе — первым делом проверяй username и password в строках F: и C: на обоих концах. Они должны совпадать побуквенно, регистр важен. Но если логин и пароль верные, а соединение всё равно сбрасывается — смотри на node id.

Node id — уникальный идентификатор CCcam-клиента, генерируется из MAC-адреса или задаётся вручную. Если два клиента с одинаковым node id подключаются к одному серверу — сервер рвёт оба соединения без внятной ошибки в логе. Выглядит как флапающий коннект: подключился, через 10–30 секунд отвалился, снова подключился. Лечится изменением node id в CCcam.cfg одного из клиентов директивой NODEID.

Несовпадение версий: client too old / version mismatch

Старый CCcam-сервер (версии 2.1.x) может отвергать клиентов с более новой строкой версии при handshake. В логе будет что-то вроде «client version not supported» или соединение просто молча рвётся после первого обмена.

Если используешь OScam на клиентской стороне — укажи cccversion = 2.1.4 в конфиге ридера. Если CCcam-клиент — найди бинарник той же версии, что и сервер, или чуть старше. Новее — рискованно.

Проблема uphops и отсутствие карт в share-листе

Клиент подключился, соединение в webif отображается, но в Shares пусто. Первое что проверить — параметр uphops в строке F: на сервере. Если стоит 0, сервер не передаёт клиенту список карт вообще. Поставь 1 для стандартной раздачи.

Второй вариант — сервер раздаёт карты, но клиент их фильтрует CAID-фильтром в скобках. Временно убери фильтр из строки C: и проверь, появятся ли карты в share-листе.

FREEZE и долгий ECM time

Фриз картинки при нормальном соединении почти всегда указывает на высокий ECM time — больше 600–800 мс. Причины: много хопов (hop 3+), перегруженный сервер, плохой канал между клиентом и сервером, или слишком много клиентов одновременно запрашивают один CAID.

Проверь ECM time в webif. Если там 1500+ мс — проблема на стороне сервера или сети. Если ECM time нормальный (200–400 мс), а фриз есть — смотри на декодер ресивера и настройки буфера.

Связка CCcam-протокола v1 с OScam

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

Настройка [cccam] reader в oscam.server

Чтобы OScam подключался к cccam server v1 как клиент, добавляешь ридер в /etc/oscam/oscam.server (или /var/etc/oscam/oscam.server на Enigma2):

[reader]
label = cccam_upstream
protocol = cccam
device = my.server.host,12000
user = myuser
password = mypassword
cccversion = 2.1.4
cccmaxhops = 2
group = 1

Параметр protocol = cccam говорит OScam использовать CCcam-протокол для этого ридера. device — хост и порт через запятую без пробела.

Параметры cccversion и cccmaxhops

cccversion — строка версии, которую OScam представит серверу при handshake. Для совместимости со старым cccam server v1 ставь 2.1.4. Если сервер новее — можно попробовать 2.3.0.

cccmaxhops ограничивает, карты с каким максимальным числом хопов принимать от этого сервера. Ставь 1–2 для нормальной работы. Значение 0 — только локальные карты сервера (hop 0). Слишком большое значение — OScam будет тащить карты с hop 5–6 и получать большой ECM time.

Раздача через oscam.user с группами

Маршрутизация в OScam строится через группы. В oscam.server ридер принадлежит к group = 1. В oscam.user пользователю разрешаешь использовать эту группу:

[account]
user = localclient
pwd = clientpass
group = 1
au = 1

Если группы не совпадают — пользователь не видит карты ридера. Классическая ошибка при переносе конфигов.

Когда OScam предпочтительнее старого CCcam-бинарника

Честно: почти всегда. OScam активно разрабатывается, поддерживает множество протоколов, имеет нормальный веб-интерфейс с детальной статистикой и хорошо логирует ошибки. Старый CCcam-бинарник не получал обновлений с середины 2010-х.

Единственная причина оставаться на чистом CCcam — специфическое железо, где OScam по какой-то причине не работает. Таких случаев в 2026 году практически нет. Если можешь мигрировать на OScam — мигрируй.