CCcam server: настройка, конфиг и порты в 2026

Если ты уже разобрался с железом и ресивер смотрит на тебя мигающим курсором — самое время погрузиться в реальную настройку. CCcam server info, которую ты найдёшь в большинстве туториалов, ограничивается парой строк «вставь C: и радуйся». Здесь разберём всё глубже: структуру конфигов, порты, диагностику freeze и полноценный OScam-эквивалент рядом с каждым шагом.

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

Card sharing — это схема, при которой один ресивер с физической смарт-картой раздаёт control words другим клиентам по TCP. Сервер декодирует ECM-запрос, получает от карты control word и отправляет его клиенту. Клиент расшифровывает поток. Всё это происходит за сотые доли секунды — если цепочка короткая и канал стабильный.

Архитектура CCcam: сервер, клиент, peer-обмен

Классическая топология: один сервер с картой, несколько клиентов с F-аккаунтами. Но CCcam поддерживает и peer-обмен — два сервера обмениваются картами через строки N: (newcamd peer) или через прямой C:/F: в обе стороны. Peer-обмен добавляет hop к цепочке, что прямо влияет на ECM time.

Клиент — это тот же CCcam или OScam, настроенный на подключение к удалённому серверу. С точки зрения протокола разницы нет: тот же TCP-порт, то же рукопожатие.

Протокол CCcam и порт по умолчанию 12000

Стандартный порт — 12000, задаётся параметром SERVER LISTEN PORT : 12000 в CCcam.cfg. После TCP-соединения клиент и сервер обмениваются случайными байтами для инициализации SHA-1-сессии, затем идёт логин. Весь дальнейший трафик зашифрован сессионным ключом.

Протокол проприетарный, изначально разработан командой CCcam. Публичной спецификации нет — OScam реализовал совместимость через реверс-инжиниринг. Это важно: некоторые edge-case'ы в поведении CCcam 2.3.x и OScam могут не совпадать.

Чем CCcam отличается от OScam и newcamd

OScam — это опенсорс-альтернатива с поддержкой нескольких протоколов одновременно: cccam, newcamd 5.25x, camd35, gbox. CCcam умеет только свой протокол плюс базовый newcamd через отдельную секцию. OScam гибче, активно поддерживается, имеет веб-интерфейс на порту 8888 из коробки.

Newcamd — это отдельный протокол (порт по умолчанию 525x, обычно 5257), он старше и проще. Если провайдер даёт N-строку вместо C-строки — это newcamd, не CCcam.

Структура конфигурационных файлов CCcam

Конфиги CCcam — это один файл CCcam.cfg плюс несколько вспомогательных. Никаких XML, никакого JSON — просто строки с ключевыми словами. Синтаксис жёсткий: пробелы, регистр, порядок параметров имеют значение.

CCcam.cfg: основные параметры и путь /var/etc/CCcam.cfg

На большинстве Enigma2-сборок файл лежит по пути /var/etc/CCcam.cfg. На OpenATV 7.x и VTi путь тот же, но некоторые кастомные сборки кладут его в /etc/CCcam.cfg. Можно явно указать путь при запуске: CCcam -C /var/etc/CCcam.cfg.

Основные глобальные параметры:

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
ALLOW TELNET : yes
DEBUG : no
CACHE SYNC : no
NEWCAMD LISTEN PORT : 5257

Если DEBUG включить в боевом режиме — лог разрастётся за ночь до сотен мегабайт. Включай только для диагностики, потом сразу выключай.

Строки F: (клиенты) и C: (подключение к серверу)

Строка F: создаёт аккаунт для клиента, которому твой сервер будет раздавать:

F: myuser mypassword 1 1

Формат: F: username password uphops downhops. uphops — сколько хопов вверх клиент может запросить через тебя. downhops — сколько хопов вниз ты отдашь клиенту. Ставить больше 1-2 не стоит — это прямой путь к freeze у конечного пользователя.

Строка C: подключает твой бокс как клиента к удалённому серверу:

C: server.example.com 12000 mylogin mypassword

Формат: C: hostname port username password. Всё строго: пробелы как разделители, лишних символов нет. Если сервер ждёт на нестандартном порту — просто меняй число.

CCcam.channelinfo, CCcam.prio и CCcam.providers

Файл CCcam.prio управляет приоритетом карт для конкретных каналов. Синтаксис строки:

caid:provid:sid

Например, если у тебя несколько карт с одним caid, можно задать приоритет по provid. Если канал не декодируется, хотя карта есть — первым делом проверь, не заблокирован ли этот sid в CCcam.prio с неверным provid.

CCcam.channelinfo — просто маппинг sid на имена каналов для отображения в webinfo. На работу декодирования не влияет. CCcam.providers расшифровывает имена провайдеров по caid/provid — тоже чисто косметика.

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

CCcam.cfg должен принадлежать пользователю, от которого запускается демон. Права 640 или 600. Если файл readable для всех — это дыра безопасности: любой процесс в системе прочитает логины и пароли.

Перезапуск после правки конфига:

killall -9 CCcam && CCcam -C /var/etc/CCcam.cfg

Или через init.d, если сборка это поддерживает:

/etc/init.d/CCcam restart

Просто kill без -9 иногда не срабатывает — демон игнорирует SIGTERM. Используй -9.

Настройка сервера и клиента: пошагово

Минимальный рабочий CCcam.cfg для сервера

Вот минимальный конфиг сервера с одной локальной картой и одним клиентом:

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
ALLOW TELNET : yes
DEBUG : no

# Локальная карта в слоте 0 (определяется автоматически)
# Аккаунт для клиента
F: testclient password123 1 1

Карту CCcam находит сам — отдельно прописывать ридер не нужно, в отличие от OScam. Если карта в слоте, она автоматически появится в webinfo через несколько секунд после запуска.

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

На клиентском боксе в CCcam.cfg:

SERVER LISTEN PORT : 12000
C: 192.168.1.100 12000 testclient password123

Если сервер за NAT — используй внешний IP или DDNS-хостнейм вместо 192.168.1.100. Локальный IP работает только в той же сети.

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

TCP-порт 12000 должен быть проброшен с внешнего IP роутера на внутренний IP сервера. В iptables на самом сервере:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j ACCEPT

Порт 16001 (webinfo) лучше закрыть для внешних IP или ограничить по источнику:

iptables -A INPUT -p tcp --dport 16001 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j DROP

Важный момент: если провайдер интернета использует CG-NAT (двойной NAT), проброс порта физически невозможен. В этом случае нужен VPN-туннель или аренда VPS с белым IP для ретрансляции. Проверить наличие CG-NAT просто: внешний IP на роутере должен совпадать с тем, что показывает whatismyip — если нет, ты за CG-NAT.

Эквивалент настройки на OScam (oscam.server, протокол cccam)

Подключение к CCcam-серверу через OScam — файл /etc/oscam/oscam.server:

[reader]
label     = myserver
protocol  = cccam
device    = server.example.com,12000
user      = testclient
password  = password123
caid      = 0500,1800

Раздача клиентам через OScam — файл /etc/oscam/oscam.user:

[account]
user      = oscamclient
pwd       = pass456
caid      = 0500
group     = 1

OScam webif поднимается на порту 8888 по умолчанию. Там же можно в реальном времени смотреть ECM time, статус ридеров и активные сессии — это гораздо удобнее, чем разбирать логи вручную.

Диагностика и устранение проблем

Большинство проблем с card sharing — это либо неправильный конфиг, либо плохой апстрим. Научиться отличать одно от другого помогает правильное чтение логов и понимание cccam server info в webinfo.

Чтение логов: CCcam.log и oscam debug level

Включи DEBUG в CCcam.cfg:

DEBUG : yes

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

tail -f /tmp/CCcam.log

В OScam уровень дебага задаётся через webif (раздел Log) или флагом -d 64 при запуске. Для диагностики подключений достаточно уровня 4 или 8 — полный дебаг (255) забьёт лог мусором.

Freeze, чёрный экран и долгий запрос ECM

Freeze — это когда изображение застывает на 2-5 секунд, потом восстанавливается. Чёрный экран — то же самое, но дольше. Причина почти всегда одна: ECM time превысил порог, при котором ресивер теряет синхронизацию с потоком.

Нормальное ECM time — до 300 мс. Заметный дискомфорт начинается от 500 мс. Freeze начинается стабильно при 700+ мс. Если видишь цифры выше 1000 мс — проблема либо в апстриме, либо в длинной цепочке reshare.

HD-каналы особенно чувствительны: у них короткий crypto period (время жизни control word), поэтому опоздание с ECM-ответом бьёт по изображению быстрее, чем на SD.

Проблемы handshake: connected vs no card

В логе CCcam есть несколько ключевых строк:

• login ok — соединение установлено, логин принят
• login failed — неверный логин/пароль или IP-блок на сервере
• card connected — сервер передал информацию о картах
• no cards — соединение есть, но сервер не отдал ни одной карты

«no cards» при успешном логине — это обычно несовпадение caid/provid. Сервер просто не видит у тебя подходящих запросов, или фильтр на его стороне блокирует передачу карт этому аккаунту.

Высокое время ответа ECM и hops

Каждый hop добавляет задержку. Одна перепередача — плюс 50-150 мс. Три hop'а — и ты уже на грани. В webinfo (порт 16001) колонка ecm time показывает реальное время последнего запроса для каждого caid/provid.

Ограничь hops в F-строке до 1:

F: myuser mypassword 1 1

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

Как выбрать провайдера card sharing: критерии

Здесь не будет названий конкретных сервисов — это принципиальная позиция. Но критерии оценки разобрать стоит, потому что они напрямую связаны с тем, как работает cccam server info на практике.

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

Хороший провайдер держит ECM time ниже 200-250 мс в часы пик. Запрашивай тестовый аккаунт и смотри в webinfo реальные цифры, не слова на сайте. Uptime легко проверить утилитой наподобие ping плюс скрипт мониторинга подключения на несколько дней.

Важно: смотри на стабильность, а не на среднее. Провайдер с ECM 150 мс но спайками до 800 мс хуже, чем тот, у кого стабильные 300 мс без выбросов.

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

Убедись, что провайдер поддерживает именно твои caid. Список caid и provid должен быть виден в webinfo после подключения — если карт нет или caid не совпадает с тем, что ты смотришь, никакая настройка не поможет.

Проверь через webinfo: раздел Cards, колонка CAID. Если там пусто — либо нет карт, либо фильтрация на стороне сервера.

Локальные карты против решары (reshare)

Это главный критерий. Локальная карта (local card) — это физическая карта непосредственно в ридере сервера. Решара — это когда сервер сам подключён к другому серверу и передаёт его карты дальше.

Цепочка из трёх решар даёт суммарно 300-500 мс только на передачу — и это без учёта нагрузки на серверах. Freeze на HD почти гарантирован. Спрашивай напрямую: есть ли у них local cards для нужных caid, или они сами клиенты чужих серверов.

Тестовый период и техническая поддержка

Нормальный провайдер даёт 24-48 часов тестового доступа без оплаты. За это время проверяй не только, «работает ли», а именно ECM time в вечернее время (когда нагрузка максимальная), поведение при переключении каналов и стабильность соединения при многочасовом просмотре.

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