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

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

Что такое CCcam server v1 и при чём здесь версия протокола

CCcam — это протокол card sharing поверх TCP. Клиент подключается к серверу, они обмениваются приветствием, после чего сервер начинает отдавать ECM-ответы. И вот здесь начинается путаница с «v1».

Реальные сборки CCcam никогда не назывались «версия 1». Существующие релизы идут в ветке 2.x.x: 2.0.11, 2.1.3, 2.1.4, 2.2.1, 2.3.0, 2.3.2. Когда кто-то говорит «cccam server v1», он, как правило, имеет в виду либо протокол первого рукопожатия CCcam (в отличие от расширений, добавленных в поздних сборках), либо просто старую ветку 2.0.x.

Версия ПО CCcam против версии протокола обмена

Это два разных понятия, и путать их дорого обходится при отладке. Версия ПО — это то, что установлено на ресивере или сервере: файл CCcam бинарного формата с конкретным номером сборки. Версия протокола — это набор расширений и флагов, которые передаются при инициализации соединения.

Сборки 2.0.x и 2.1.x реализуют базовый протокол без ряда расширений, появившихся в 2.2.x и 2.3.x. Когда два пира договариваются о соединении, они сравнивают не только логин/пароль, но и флаги возможностей. Если один конец не знает, что делать с флагом другого — соединение может установиться, но работать нестабильно.

Где в логах видно номер версии

При успешном подключении в логах CCcam появляется строка примерно такого вида:

connected to server my.server.com:12000 [CCcam 2.3.2]

Или с клиентской стороны, если смотреть через веб-интерфейс Connected Servers:

peer: 2.3.0 | cards: 14 | hops: 1

Именно здесь и видно, какая версия на другом конце. Если вместо номера версии стоит прочерк или «unknown» — это уже симптом проблемы с рукопожатием.

Почему «v1» чаще относится к протоколу рукопожатия

Исторически протокол CCcam в своей первоначальной форме — это то, что умели делать ранние клиенты. Расширения вроде Extended CW Cycle Check, поддержка нескольких провайдеров в одной сессии и улучшенный формат EMM появились позже. Когда говорят «cccam server v1», часто имеют в виду именно этот базовый режим без дополнительных расширений.

Структура CCcam.cfg и ключевые строки конфигурации

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

Путь к файлу: /var/etc/CCcam.cfg

На устройствах Enigma2 (Dreambox, VU+, Vu+ Zero, Gigablue и прочие) конфиг лежит в /var/etc/CCcam.cfg. На некоторых сборках OpenPLi или OpenATV путь может быть /etc/CCcam.cfg. Проверить просто:

ls -la /var/etc/CCcam.cfg /etc/CCcam.cfg 2>/dev/null

Права на файл должны быть 644 или 600. Если CCcam запущен от root (что типично для ресиверов) — 644 достаточно. Главное, чтобы демон мог файл прочитать.

C-line (клиент): C: host port username password

Строка подключения к удалённому серверу выглядит так:

C: my.server.com 12000 myuser mypassword

Формат: C: хост порт логин пароль. Никаких лишних символов, никаких кавычек. Порт 12000 — стандартный для CCcam. Если у вас нестандартный порт, он указывается здесь явно.

Можно добавить несколько C-line для резервных серверов. CCcam будет пробовать их по порядку при недоступности основного.

N-line (newcamd-обмен) и F-line (локальные пользователи)

N-line нужна для подключения через протокол newcamd — это другой протокол card sharing, но CCcam умеет с ним работать:

N: host 15050 login pass 01 02 03 04 05 06 07 08 09 10 11 12 13 14

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

F: username password 1 0 0 { }

Цифры после логина/пароля — это параметры reshare: глубина раздачи, разрешение/запрет reshare, ограничение по количеству карт. Подробнее — в секции про согласование версий.

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

В CCcam.cfg явно задаются оба порта:

SERVER LISTEN PORT: 12000
WEBINFO LISTEN PORT: 16001
WEBINFO USERNAME: admin
WEBINFO PASSWORD: adminpass

Порт 12000 слушает входящие подключения от клиентов. Порт 16001 — веб-интерфейс, где видно состояние карт, подключённых клиентов, статистику ECM. Если веб-интерфейс не отвечает — сначала проверяйте именно эти параметры и не забывайте про фаервол.

После любых изменений в CCcam.cfg нужен перезапуск демона:

killall -9 CCcam && sleep 2 && /etc/init.d/CCcam start

Или через init-скрипт, если он настроен: /etc/init.d/CCcam restart. Без перезапуска изменения не применяются — это базовое, но про это регулярно забывают.

Согласование версий между сервером и клиентом

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

Что происходит при несовпадении версий протокола

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

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

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

Практическое правило: держите версии в пределах одной ветки или соседних. Клиент 2.1.4 и сервер 2.2.1 обычно работают нормально. Клиент 2.0.11 и сервер 2.3.x — лотерея.

Проверить версию подключённого пира можно через веб-интерфейс на 16001, страница «Connected clients» или «Connected servers». Там же видно количество карт, hops и время последнего обращения.

Если возможности выбирать нет и клиент вынужден работать со старой версией — попробуйте на серверной стороне ограничить reshare до минимума и отключить расширенные функции. Иногда это стабилизирует соединение.

Параметр EXTENDED CW CYCLE CHECK и его влияние

В CCcam.cfg есть параметр:

EXTENDED CW CYCLE CHECK: yes

Он включает проверку цикличности контрольных слов (CW). Старые клиенты и некоторые реализации этого не поддерживают — соединение с таким клиентом будет постоянно рваться. Если подключаете устаревший клиент, попробуйте выставить в no. На стабильность с современными клиентами это влияет минимально.

Проверка работы сервера: порты, логи и веб-интерфейс

Диагностика CCcam — это последовательность от сети к конфигу. Не наоборот. Начинать с правки конфига, когда порт просто закрыт фаерволом — пустая трата времени.

Проверка открытого порта: telnet host 12000

Самая простая проверка с клиентской стороны:

telnet my.server.com 12000

Если порт открыт, вы получите несколько байт бинарного приветствия CCcam — соединение установилось. Если «Connection refused» — порт закрыт или демон не запущен. Если таймаут — между вами и сервером фаервол или двойной NAT.

На серверной стороне:

netstat -an | grep 12000

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

Проблема двойного NAT особенно распространена у провайдеров, которые раздают серые IP. Порт 12000 может быть открыт локально, но входящие подключения снаружи всё равно не проходят. Тут помогает либо VPN, либо прямой IP от провайдера.

Чтение логов CCcam и расшифровка статусов пиров

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

tail -f /tmp/CCcam.log

Что искать: строки ECM с временем ответа в миллисекундах, статус CARD OK или NO CARD, ошибки DENIED или TIMEOUT. Строка RECONNECT в цикле — признак нестабильного соединения или неверных учётных данных.

Параметр hops показывает, через сколько узлов прошла карта: hops=0 — локальная карта, hops=1 — прямое подключение, hops=2 и выше — reshare через посредника. Чем больше hops, тем выше задержка.

Веб-интерфейс на порту 16001 и страница Entitlements

Веб-интерфейс CCcam по адресу http://server_ip:16001 — самый удобный способ диагностики. На странице «Info» видно общий статус, на «Entitlements» — список карт с их CAID (идентификатор системы условного доступа), провайдером и сроком действия.

Если страница не открывается — проверьте параметры WEBINFO USERNAME и WEBINFO PASSWORD в CCcam.cfg. Пустой логин/пароль тоже не работают. И убедитесь, что порт 16001 не закрыт iptables на уровне ресивера.

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

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

Соединение есть, но нет карт (no cards)

Первым делом смотрите веб-интерфейс: есть ли карты в разделе Entitlements? Если нет — сервер либо не отдаёт reshare, либо у вашего пользователя нет прав на карты.

Проверьте F-line для вашего пользователя на серверной стороне. Параметр reshare должен быть не 0. Если сервер чужой — это вопрос к администратору сервера.

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

Постоянные reconnect и таймауты

Цикличный reconnect в логах — это либо сетевая нестабильность, либо неверные учётные данные, либо сервер отклоняет подключение по версии. Алгоритм проверки:

1. Проверьте пинг до сервера: ping -c 20 my.server.com. Потери пакетов больше 5% — проблема на уровне сети.
2. Проверьте правильность логина/пароля в C-line — опечатки здесь не редкость.
3. Убедитесь, что ваш IP не заблокирован на сервере (попросите администратора проверить).
4. Попробуйте подключиться с другой версии CCcam.

Долгий отклик ECM и фризы изображения

ECM time выше 700 мс — это уже ощутимые фризы. Выше 1000–1500 мс — картинка замерзает регулярно. Причины:

Перегруженный канал между клиентом и сервером — проверьте speedtest и пинг. Высокая нагрузка на сам сервер — если к нему подключено 500 клиентов, ваш ECM будет в очереди. Большое значение hops — каждый дополнительный узел добавляет задержку.

Идеальный ECM time — до 300–400 мс. При таком значении переключение каналов происходит мгновенно и фризов нет.

Как выбрать качественный сервер: критерии без привязки к брендам

Этот раздел — про то, на что смотреть при выборе, а не про то, у кого покупать. Хороший сервер одинаково легко отличить от плохого по нескольким объективным показателям.

Стабильность аптайма и время отклика ECM

Попросите тестовый период на 24–48 часов — любой нормальный провайдер его даёт. За это время смотрите в логах CCcam реальный ECM time. Не рекламируемый, а тот, что в строках got ECM answer в файле лога. Ориентир: до 300–400 мс — хорошо, до 600 мс — приемлемо, выше — плохо.

Аптайм проверяйте не по словам, а по реальному поведению: запустите мониторинг tail -f /tmp/CCcam.log | grep RECONNECT на ночь. Если reconnect-ов больше 2–3 за 8 часов — сервер нестабилен.

Глубина reshare и количество локальных карт

Локальная карта на сервере (hops=1) всегда лучше перепродажи через 3–4 узла (hops=3–4). Спрашивайте у провайдера прямо: какие карты локальные, какие — reshare? Если уклоняется от ответа — это уже сигнал.

Глубина reshare выше 3 — риск нестабильности. Если один из узлов в цепочке перегружен или уходит в даун, ваш ECM time скачет непредсказуемо.

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

Перед покупкой уточните CAID пакетов, которые вам нужны. Это не маркетинговые названия, а реальные идентификаторы вида 0x0500, 0x1810 и т.п. Проверить, что сервер реально отдаёт эти CAID, можно через страницу Entitlements в веб-интерфейсе после подключения тестового аккаунта.

Провайдеры вещания периодически меняют ключи и условия доступа. Хороший сервер обновляется оперативно — в течение часов, а не суток. Это тоже проверяется на тестовом периоде при смене ключей.