CCcam sharing: настройка сервера и клиента 2026

CCcam sharing — это не магия и не «просто скачал и работает». За простым интерфейсом скрывается конкретный протокол с握рукопожатием, шифрованием сессии и строгим форматом конфигов. Если хоть одно поле не то — получаешь пустой экран и гадаешь, где сломалось. Этот материал разбирает протокол по косточкам: от принципа обмена ECM/CW до реальных команд диагностики.

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

Начнём с механики. Твой ресивер получает зашифрованный поток DVB, не может его декодировать сам и отправляет запрос ECM (Entitlement Control Message) на сервер через TCP-соединение. Сервер, у которого есть физическая смарт-карта или эмулятор, расшифровывает ECM и возвращает CW (Control Word) — 8-байтный ключ, которым твой ресивер и открывает поток. Весь этот цикл должен уложиться в ~200–400 мс, иначе начинается фриз.

Принцип card sharing: ECM, CW и DCW

ECM обновляется каждые 10 секунд (crypto-period). DCW — это то же, что CW, просто термин из документации деcкрипторов. Важно понимать: сервер не «даёт доступ» в бытовом смысле — он просто быстро отвечает на каждый запрос ключом. Если ответ пришёл позже смены crypto-period — кадр чёрный.

Задержка складывается из: ping до сервера + время обработки ECM на сервере + число промежуточных хопов. Пинг 20 мс и 3 хопа уже дают другой результат, чем пинг 5 мс и 1 хоп.

Роль сервера и клиента в схеме

Сервер держит физическую карту (или несколько) в кардридере, запускает демон CCcam, слушает порт 12000 TCP и раздаёт CW подключённым клиентам. Клиент — это твой ресивер на Enigma2, VU+, Dreambox или любой другой Linux-бокс, у которого установлен CCcam или OScam в режиме клиента.

Один сервер может обслуживать десятки клиентов, но каждый параллельный запрос ECM увеличивает нагрузку. При 50+ активных F: line ECM time начинает ползти вверх — особенно если карта одна.

Версии протокола CCcam и совместимость

Текущие актуальные сборки работают на ветке 2.3.x. Ветка 2.1.x до сих пор встречается на старых ресиверах, и там есть несовместимость рукопожатия с 2.3.x-серверами. Симптом — сервер видит подключение, но сразу рвёт его. Проверяй версию: CCcam -v в терминале.

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

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

CCcam — проприетарный протокол с собственным рукопожатием и шифрованием сессии на базе SHA-1. OScam — открытый, модульный, поддерживает одновременно несколько протоколов (cccam, newcamd, camd3). MgCamd использует протокол newcamd и работает чуть иначе в части формата запросов.

На практике: CCcam проще поднять быстро, OScam гибче при тонкой настройке и лучше логирует. NewCamd/MgCamd встречается реже, в основном на старых инсталляциях.

Настройка CCcam-сервера: конфигурационные файлы и пути

Основной файл конфигурации — /var/etc/CCcam.cfg. На некоторых сборках встречается /etc/CCcam.cfg — зависит от дистрибутива. Ключи смарт-карт лежат в /usr/keys/. После правки конфига перезапуск: /etc/init.d/CCcam restart или killall CCcam && CCcam &.

Структура /var/etc/CCcam.cfg

Минимальный рабочий конфиг сервера выглядит так:

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
ALLOW TELNET : yes
ALLOW WEBINFO : yes
LOGFILE : /var/log/CCcam.log
LOGLEVEL : 1

F: username password 1 1 0

Директива SERVER LISTEN PORT : 12000 — порт, на котором сервер принимает клиентов. Если ISP блокирует 12000 (такое бывает), меняй на любой незанятый выше 1024, например 15000 или 10000. WEBINFO LISTEN PORT : 16001 открывает веб-интерфейс для мониторинга. LOGLEVEL от 0 до 3: на проде держи 1, при отладке ставь 3.

Права на файл конфига: chmod 644 /var/etc/CCcam.cfg. Если демон запущен от root — сойдёт, но лучше 640 с нужным владельцем.

Файл CCcam.prio и приоритеты CAID

Файл /var/etc/CCcam.prio управляет тем, какую карту использовать для какого канала. Формат строки: CAID:provider:srvid:uphops:downhops. Пример:

0500:032820:0:0:1
0B00:000000:0:0:2

Первая строка говорит: для CAID 0500, провайдера 032820 использовать карту с 0 uphops и максимум 1 downhop. Если этот файл пустой или отсутствует — CCcam сам выбирает карту, иногда неоптимально. При проблемах «канал есть, картинки нет» — первым делом сюда.

Типичная ошибка: CAID совпадает, но provider id не тот. Канал технически найден, но декодирование не идёт, потому что CCcam.prio указывает на другого провайдера. Сверяй provider id через WebInfo.

Файлы CCcam.channelinfo и CCcam.providers

CCcam.channelinfo содержит маппинг SID → название канала. Без него WebInfo показывает числа вместо имён — не критично, но неудобно. CCcam.providers маппит CAID:providerid → читаемое название провайдера. Оба файла опциональны, но значительно упрощают диагностику.

Параметры F: line для локальных пользователей

Строка F: — это описание пользователя, которому разрешён доступ к серверу. Полный формат:

F: username password uphops downhops ident

Конкретный пример: F: john secretpass 1 1 0

• username — логин клиента
• password — пароль (регистрозависимый)
• uphops — сколько хопов вверх клиент может «видеть» (1 = только локальные карты)
• downhops — сколько хопов вниз разрешено пробрасывать (0 = нельзя)
• ident — ограничение по CAID:provider (0 = без ограничений)

При большом числе F: line сервер начинает тормозить под нагрузкой. Каждая активная линия — это отдельный поток с памятью и обработкой ECM. Если держишь 100+ пользователей на одной карте — ECM time растёт нелинейно.

Настройка клиента: C: line и подключение к серверу

На стороне клиента (твой ресивер) нужна строка C: в том же файле CCcam.cfg. Формат:

C: server.host 12000 username password no { 0:0:2 }

Формат строки C: hostname port username password

Разбираем каждое поле:

• server.host — IP или hostname сервера. Если у сервера динамический IP — нужен DDNS (например, DynDNS или собственный ddclient)
• 12000 — порт (должен совпадать с SERVER LISTEN PORT на сервере)
• username / password — точно как в F: line на сервере, с учётом регистра
• no — флаг wantemu: no означает «не запрашивать эмуляцию», yes — разрешить
• { 0:0:2 } — nodeid и параметры; 0:0:2 — стандартное значение

Минимальная рабочая строка без лишних параметров: C: 192.168.1.100 12000 john secretpass. Остальное CCcam заполнит дефолтами.

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

Флаг wantemu (третий параметр после пароля) влияет на то, запрашивает ли клиент эмулированные карты с сервера. Для большинства случаев — no. NodeID — уникальный идентификатор клиента в сети; если не задан явно, CCcam генерирует автоматически на основе MAC-адреса. Конфликт nodeid двух клиентов с одним логином может приводить к периодическим отвалам.

Подключение нескольких линий и резервирование

Несколько C: строк в конфиге — это параллельные соединения. CCcam попробует все и выберет ту, которая ответила первой. Это и есть резервирование: если основная линия упала, вторая подхватывает.

Но осторожно: если две линии раздают одинаковый CAID с разных серверов, CCcam может чередовать их непредсказуемо. Управляй приоритетом через CCcam.prio, а не надейся на автовыбор.

Проверка статуса через WebInfo и telnet

WebInfo доступен по адресу http://<ip-ресивера>:16001. Там видно: активные C: и F: линии, статус карт, ECM time по каждому каналу, число хопов. Это первое место, куда идти при проблемах.

Telnet: telnet <ip-ресивера> 23, потом команда log — живой лог декодирования. Команда info показывает статус сервера. Если telnet не отвечает — проверь ALLOW TELNET : yes в конфиге.

OScam как альтернатива: миграция конфигов

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

Структура oscam.conf, oscam.server, oscam.user

Основные пути: /etc/tuxbox/config/oscam/ или /var/etc/oscam/ — зависит от сборки. Три ключевых файла:

• oscam.conf — глобальные параметры (логирование, webif, порты)
• oscam.server — описание ридеров (физические карты или внешние CCcam-серверы)
• oscam.user — описание клиентов (аналог F: line)

Минимальный oscam.conf:

[global]
logfile = /var/log/oscam.log
loglevel = 4

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

Протокол cccam в OScam (reader type)

Чтобы OScam подключился к CCcam-серверу как клиент, в oscam.server добавляешь reader:

[reader]
label = myserver
protocol = cccam
device = server.host,12000
user = username
password = password
caid = 0500,0B00
group = 1
cccversion = 2.3.0
ccchop = 1

Параметр cccversion критичен — он должен совпадать с версией сервера. ccchop ограничивает число хопов, которые OScam запрашивает.

Перенос F: и C: line в формат OScam

F: line из CCcam становится записью в oscam.user:

[account]
user = john
pwd = secretpass
group = 1
caid = 0500
au = 1

C: line — это reader в oscam.server с protocol = cccam, как показано выше. Принципиально другой синтаксис, но логика та же.

Преимущества OScam при высокой нагрузке

OScam лучше справляется с очередями ECM при многих одновременных клиентах. Логирование детальнее: можно видеть каждый ECM-запрос с временем ответа, источником и причиной отказа. Webif на порту 8888 показывает больше деталей, чем CCcam WebInfo.

Но: OScam сложнее в первоначальной настройке. Если тебе нужно просто поднять один клиент с двумя линиями — CCcam быстрее. Если строишь сервер под нагрузкой с несколькими картами и десятками клиентов — OScam оправдывает время на конфигурацию.

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

Большинство проблем с cccam sharing делятся на три категории: не подключается вообще, подключается но нет картинки, подключается и картинка есть, но с фризами. Каждый случай лечится по-своему.

Connection refused и закрытые порты

Первая проверка — порт действительно открыт:

telnet server.host 12000

Если «Connection refused» — либо демон не запущен, либо порт закрыт файрволом. На сервере:

netstat -tlnp | grep 12000

Если строки нет — CCcam не запущен или слушает другой порт. Если строка есть, но telnet снаружи не проходит — проблема в файрволе или NAT. За NAT нужен проброс порта: на роутере пробросить TCP 12000 на IP сервера.

При динамическом IP сервера клиент потеряет соединение после смены адреса. Решение: DDNS-сервис + ddclient на сервере, который обновляет запись. Тогда в C: line используешь hostname, а не IP.

Ошибка FOUND but no decode / нет картинки

Канал есть в списке, ECM-запрос уходит, но картинки нет. Это самый неприятный случай — соединение работает, но что-то не так с декодированием. Алгоритм:

1. Проверь CAID канала (через WebInfo или лог) и сравни с тем, что есть на сервере
2. Проверь provider id — CAID совпадает, а provider нет → картинки не будет
3. Посмотри CCcam.prio — возможно, для этого CAID задан неправильный приоритет
4. ECM time в WebInfo — если >800 мс, CW приходит позже смены ключа

Второй конфликт на одном ресивере: если одновременно запущены два softcam (например, CCcam и MgCamd), они конфликтуют за один и тот же дескриптор. Оставляй только один активный softcam.

Частые обрывы и freeze на HD-каналах

HD и UHD каналы требуют больше полосы пропускания и чаще обновляют crypto-period на некоторых пакетах. Freeze при нормальном пинге — признак нехватки пропускной способности между ресивером и сервером, либо перегруженного сервера.

Дополнительная проверка: tcpdump -i eth0 port 12000 покажет, есть ли TCP-ретрансмиты или паузы в потоке. Большое число ретрансмитов → проблема с сетью, а не с конфигом. Если сервер отвечает, но с задержкой >500 мс — скорее всего, перегружен или линия многоуровневого реселлинга с 4+ хопами.

Анализ логов CCcam и tcpdump

Лог CCcam: cat /var/log/CCcam.log | tail -100 или в реальном времени: tail -f /var/log/CCcam.log. Искать строки с ECM, TIMEOUT, CONNECT, DISCONNECT.

tcpdump для захвата трафика шаринга: tcpdump -i eth0 -w /tmp/cccam.pcap port 12000. Потом открывай в Wireshark на десктопе — видно рукопожатие, паузы, сбросы соединения. Если видишь TCP RST от сервера сразу после handshake — неверный логин/пароль или несовместимость версий.

Как выбрать провайдера линии: объективные критерии

Здесь не будет списка сервисов. Только метрики, которые ты можешь проверить сам во время тестового периода.

Метрики качества: ECM time, uptime, hops

ECM time — главный показатель. Меньше 200 мс — отлично. 200–400 мс — приемлемо. Больше 400 мс — начнутся проблемы на некоторых каналах, больше 600 мс — freeze гарантированы. Смотреть через WebInfo в столбце ECM или в логе OScam.

Uptime сервера за период — не верь цифрам на сайте провайдера. Тестируй сам: поставь линию на неделю, смотри логи на число разрывов и их длительность. Один разрыв раз в день на 30 секунд — терпимо. Пять разрывов за ночь — не годится.

Поддержка нужных CAID и пакетов

Перед тем как брать линию, выясни точный CAID и provider id нужных тебе каналов. Узнать CAID можно через WebInfo на работающей линии или через ресурсы с базами данных CAID. Потом спрашивай провайдера напрямую — поддерживается ли конкретный CAID:providerid. Расплывчатое «поддерживаем всё» — красный флаг.

Локальная карта против реселлерской линии

Локальная карта = 1 hop. Реселлер перепродаёт чужую линию — это уже 2–4 хопа. Каждый хоп добавляет задержку и точку отказа. В WebInfo смотри значение uphops для карты: 1 — локальная, 2+ — реселлинг.

Реселлерские линии дешевле, но нестабильнее. При прочих равных локальная карта с 1 хопом переигрывает реселлера с 3 хопами даже при одинаковом пинге. Параметр uphops в F: line на сервере ограничивает глубину цепочки — не позволяй клиентам видеть больше 2 хопов.

Тестовый период и стабильность

Нормальный провайдер даёт тестовую линию на 24–48 часов. Этого достаточно, чтобы прогнать её через реальные условия: включи запись ECM time в лог, посмотри на поведение в пиковые часы (вечер, выходные). Если в тестовый период линия работает отлично, а после оплаты деградирует — это признак перегруженного сервера, где тестовые аккаунты приоритизированы.