CCcam Premium: настройка сервера и cccam.cfg

Запрос cccampremium в поисковике обычно приводит к страницам с готовыми C-line и минимумом объяснений. Что делать, когда линия есть, ресивер подключён, а каналы всё равно фризят — не написано нигде. Эта статья закрывает тот пробел: реальные пути к файлам, рабочие команды, диагностика по логам и технические критерии выбора сервера без рекламной воды.

Что такое CCcam premium и из чего состоит C-line

Протокол CCcam и принцип card sharing

CCcam — это демон карт-шаринга, написанный под Linux. Он берёт физическую смарт-карту (или несколько), читает CW (Control Word) и раздаёт его клиентам по сети. Клиент — это ваш ресивер или другой сервер — запрашивает ключ шифрования канала каждые несколько секунд. Если ключ пришёл вовремя, картинка идёт. Нет — фриз.

Протокол работает по TCP, порт по умолчанию 12000. Авторизация простая: имя пользователя и пароль, которые задаются на сервере. Никакого SSL из коробки нет, трафик идёт в открытом виде, если не поднят туннель.

Разбор строки C-line по полям

Стандартная C-line выглядит так:

C: hostname 12000 username password no

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

• C: — тип строки, обозначает подключение к удалённому CCcam-серверу
• hostname — DNS-имя или IP-адрес сервера
• 12000 — порт (может быть любым, сервер задаёт через SERVER LISTEN PORT)
• username / password — учётные данные, созданные на сервере директивой F:
• no / yes — разрешение решаринга. yes означает, что вы можете передавать полученные карты дальше. Большинство серверов ставят no

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

Чем premium-линия отличается от обычной (uptime, локальные карты, hops)

Слово «premium» в контексте cccampremium — чисто маркетинговое. Технически разница между «обычной» и «премиум» линией сводится к трём параметрам: hop, ECM time и uptime сервера.

Hop 1 — это прямое подключение к физической карте. Время декодирования минимальное, обычно 200–400 мс. Hop 2 — сервер сам является клиентом другого сервера. ECM time растёт, риск фризов повышается. Hop 3 и выше — нестабильно по определению.

ECM time выше 1000–1200 мс уже ощутим на каналах с частой сменой ключа. Выше 1500 мс — фризы гарантированы. Вот и весь «премиум»: локальные карты + хороший канал до сервера + нормальный аптайм.

Установка и базовая настройка cccam.cfg

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

На приставках с Enigma2 конфиг CCcam лежит в /var/etc/CCcam.cfg. Бинарник находится в /usr/bin/CCcam. Если используется OpenPLi или OpenATV, путь тот же. На голом Debian/Ubuntu сервере конфиг чаще кладут в /etc/CCcam.cfg — зависит от того, как собран пакет.

Проверить, где именно живёт конфиг у запущенного процесса, можно так:

cat /proc/$(pidof CCcam)/cmdline | tr '\0' ' '

Ключевые директивы: C:, F:, SERVER LISTEN PORT, WEBINFO

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

# Порт, на котором слушает сервер (клиенты подключаются сюда)
SERVER LISTEN PORT : 12000

# Веб-интерфейс для мониторинга
WEBINFO LISTEN PORT : 16001

# Разрешить telnet для диагностики
ALLOW TELNET : yes

# Локальная карта (если есть ридер на сервере)
# B: имя_ридера

# Пользователи, которым раздаётся доступ
F: username password no 10 0 0 0 { 0:0:1 }

# Подключение к вышестоящему серверу
C: upstream.example.com 12000 user pass no

Директива F: создаёт пользователя на сервере. Поля после пароля — флаги: решаринг (no/yes), максимальное число хопов, количество доступных карт. Фигурные скобки ограничивают доступ по CAID/SID — оставьте { 0:0:1 } для полного доступа.

Права доступа и перезапуск демона CCcam

Конфиг должен иметь права 644, бинарник — 755. Если CCcam не стартует, первым делом проверяйте права:

chmod 644 /var/etc/CCcam.cfg
chmod 755 /usr/bin/CCcam

Перезапуск на Enigma2:

# Через init.d (зависит от дистрибутива)
/etc/init.d/softcam.cccam restart

# Или вручную
killall CCcam
sleep 2
CCcam &

После любой правки конфига нужен полный перезапуск. CCcam не умеет перечитывать конфиг на лету через SIGHUP, в отличие от OScam.

Настройка шаринга через OScam (newcamd и cccam reader)

oscam.server: добавление [reader] типа cccam

OScam умеет подключаться к CCcam-серверу как клиент. Это удобно: OScam гибче в логировании, имеет нормальный веб-интерфейс и лучше обрабатывает ошибки. Конфиг ридера в /etc/oscam/oscam.server (или /var/keys/oscam.server на Enigma2):

[reader]
label                = myserver
protocol             = cccam
device               = hostname,12000
user                 = username
password             = password
group                = 1
cccversion           = 2.3.0
ccckeepalive         = 1
reconnecttimeout     = 30

Параметр cccversion — критичный. Если сервер работает на CCcam 2.2.x, а вы указали 2.3.0 — соединение установится, но ключи могут не передаваться. Уточняйте версию у провайдера или пробуйте 2.1.4, 2.2.1, 2.3.0 поочерёдно.

Для newcamd-подключения протокол другой:

[reader]
label                = newcamd_server
protocol             = newcamd
device               = hostname,525X
user                 = username
password             = password
key                  = 0102030405060708091011121314
group                = 1

Порты newcamd обычно в диапазоне 5250–5260. Конкретный порт зависит от настройки сервера.

oscam.user и oscam.conf: webif и протоколы

Файл /etc/oscam/oscam.conf управляет глобальными настройками. Для работы веб-интерфейса нужна секция:

[webif]
httpport             = 8888
httpuser             = admin
httppwd              = yourpassword
httprefresh          = 15
httpallowed          = 127.0.0.1,192.168.0.0-192.168.255.255

В oscam.user создаются пользователи для клиентов, которым OScam раздаёт карты локально. Если OScam используется только как клиент к CCcam — этот файл минимальный или пустой.

Связка OScam как клиент к CCcam-серверу

Схема работает так: ресивер (или приложение) подключается к локальному OScam, OScam забирает CW с удалённого CCcam-сервера и отдаёт его клиенту. Преимущество — один OScam может работать с несколькими серверами одновременно, переключаясь при недоступности одного из них.

Важный момент: нельзя одновременно запускать CCcam и OScam на одном ресивере как два softcam. Они будут конфликтовать за доступ к смарт-карт ридеру и за порты. Выбирайте один. OScam предпочтительнее — он активно поддерживается и гибче.

Если на ресивере есть локальная карта, а также подключение к удалённому серверу через OScam, настройте приоритеты через параметр group и fallback в oscam.server. Локальная карта должна быть в приоритетной группе, удалённый сервер — фолбэком.

Диагностика: фриз, чёрный экран и ошибки ECM

Чтение OScam log и веб-интерфейса (порт 8888)

Веб-интерфейс OScam на порту 8888 — первая точка диагностики. Раздел «Readers» показывает статус каждого ридера: Connected/Disconnected, число успешных и неуспешных декодирований, среднее время ECM.

Лог в реальном времени:

tail -f /var/log/oscam/oscam.log

Нужно смотреть на строки вида:

2026/06/28 14:23:01   66A2EB reader myserver (cccam): found (550 ms) by myserver

Число в скобках — ECM time в миллисекундах. 550 мс — нормально. 1800 мс — плохо.

ECM time, статусы (found/not found), причины фризов

Статус not found в логе означает, что сервер не смог найти ключ для этого канала. Причины разные: канал не входит в подписку на сервере, CAID/SID не поддерживается, сервер перегружен.

Если статус found, но фриз всё равно есть — смотрим на время. ECM time выше 1500 мс критичен для каналов, которые меняют CW каждые 10 секунд. Тяжёлые HD-пакеты с частой сменой ключа (каждые 5–7 секунд) требуют ECM time не выше 800–1000 мс.

Распространённые причины высокого ECM time:

• Большое число хопов (hop 3+)
• Перегрузка сервера — одновременно много клиентов на одну карту
• Нестабильный интернет-канал между клиентом и сервером
• Двойной NAT или фильтрация трафика провайдером

Проверка через telnet и tcpdump

Базовая проверка доступности сервера:

telnet hostname 12000

Если соединение устанавливается — порт открыт и сервер слушает. Если отказано — либо сервер недоступен, либо порт 12000 заблокирован провайдером на вашей стороне.

Для контроля трафика:

tcpdump -i eth0 host hostname and port 12000 -n

Это покажет, идёт ли обмен пакетами. Если пакеты уходят (SYN), но ответа нет (нет SYN-ACK) — проблема на пути к серверу или на стороне сервера. Если пакеты вообще не уходят — проблема локально (неверный хост, блокировка файрволлом).

Ещё один частый случай: реконнект каждые 2–3 минуты. Это обычно означает, что сервер ограничивает количество одновременных подключений с одной C-line и отрубает вас, если вы подключились с нескольких устройств. Проверьте, нет ли второго ресивера или клиента, использующего те же учётные данные.

Как выбрать качественный сервер (по техническим критериям)

Локальные карты против решаринга (hop 1 vs hop 2+)

При поиске cccampremium решения главный вопрос — насколько близко физическая карта к серверу, который вы используете. Hop 1 — сервер читает карту напрямую. Это быстро, стабильно, предсказуемо. Hop 2 — сервер сам является клиентом другого сервера. Зависимостей больше, точек отказа больше.

Спрашивайте напрямую: это локальные карты или решаринг? Хороший провайдер ответит. Уклончивый ответ — уже ответ.

Uptime, стабильность ECM и отсутствие фризов на тяжёлых пакетах

Синтетический uptime 99% ничего не значит, если сервер стабильно работает 29 дней и 20 часов, а потом падает на 3 часа в прайм-тайм. Тестируйте в разное время суток — вечером нагрузка выше.

Попросите тестовую линию на 24–48 часов и гоняйте именно те пакеты и спутниковые позиции, которые вам нужны. Не смотрите только на стандартные FTA-каналы — они открываются всем. Тестируйте на тяжёлых HD-пакетах с частой сменой ECM.

Тестовый доступ и поддержка протоколов

Нормальный сервер дает тестовый доступ без предоплаты или с минимальной. Если тест невозможен — риск высокий.

Проверяйте поддержку нужных протоколов: если ваш ресивер работает через OScam с newcamd, сервер должен поддерживать newcamd, а не только cccam. Уточняйте поддерживаемые CAID, спутниковые позиции и пакеты — это должно быть конкретно, а не «поддерживаем всё».

И последнее: проверьте, как сервер обрабатывает реконнект. Если после разрыва соединения клиент не может переподключиться несколько минут — это проблема на стороне сервера. Корректный сервер принимает реконнект немедленно.