CCcam reshare: настройка сервера в 2026 — гайд

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

Что такое reshare в CCcam и как он работает

Reshare — это когда твой CCcam-сервер получает карту от пира и переотдаёт её дальше своим собственным пирам. Ты выступаешь промежуточным звеном в цепочке. Звучит просто, но дьявол в деталях: кому отдавать, насколько глубоко, и как не устроить петлю.

Принцип переотдачи карт между пирами

Схема работает так: сервер-источник → твой сервер → твой пир. Источник отдаёт тебе карту с определёнными ограничениями. Ты её получаешь и — если reshare разрешён — переотдаёшь вниз по цепочке. Твой пир может переотдать её ещё дальше, если ты ему это позволишь.

Каждый такой переход от узла к узлу называется hop. Чем больше hops прошла карта, тем дальше она ушла от источника. И тем выше риск потери времени на ECM-запрос — каждый дополнительный прыжок добавляет задержку.

Параметры hops и uphops простыми словами

hops — это сколько узлов вниз карта может уйти от тебя. Ты выставляешь это значение для своего пира. Если написал reshare 1 — пир получит карту и сможет отдать её ещё одному узлу вниз, но не дальше.

uphops — это фильтр на приём. Ты говоришь своему серверу: «принимать карты только если они пришли не глубже чем N hops от источника». Если карта пришла к тебе уже с hop=3, а твой uphops=2, карта обрезается. Именно здесь чаще всего и ломается reshare — когда uphops у одного из пиров выставлен слишком жёстко.

Значение reshare = 0 означает полный запрет. Пир получает карту для личного использования и не может раздать её никуда. Это самый безопасный режим для клиентских подключений, которым не нужна переотдача.

Чем reshare отличается от прямого шаринга

При прямом шаринге карта идёт напрямую от ридера или сервера к пиру — один hop. При reshare карта уже «б/у»: она пришла откуда-то сверху, и ты её переотдаёшь. Качество ECM-ответа при этом может чуть пострадать из-за накопленной задержки в цепочке. Поэтому держать reshare глубже 2 уровней практически нет смысла.

Настройка reshare в CCcam.cfg: строки C/N и F

CCcam reshare: настройка начинается с правки файла CCcam.cfg. Структура конфига позволяет задавать reshare как глобально, так и для каждого пира отдельно — и для каждого CAID/провайдера в фигурных скобках.

Формат строки клиента C: line

Базовый синтаксис C-строки с reshare:

C: hostname 12000 username password no { 0:0:2 }

Поля по порядку: хост, порт (обычно 12000 или 13000), логин, пароль, флаг активации AU (no/yes), и в фигурных скобках — параметры шаринга в формате caid:provider:reshare. Значение 0:0:2 означает: для всех CAID и провайдеров разрешить reshare глубиной 2.

Если нужно ограничить reshare по конкретному CAID, например только для Viaccess (0D05) с нулевой переотдачей:

C: hostname 12000 username password no { 0D05:000000:0 }

Можно комбинировать несколько записей в одних скобках через запятую:

C: hostname 12000 user pass no { 0D05:000000:0, 0622:000000:1 }

Здесь Viaccess запрещён к переотдаче, а Irdeto переотдаётся на 1 hop вниз.

N-строка (N: line) — это строка сервера, описывающая, что ты разрешаешь принимать входящему пиру. Синтаксис аналогичный, только она идёт со стороны хоста, который принимает подключение:

N: 192.168.1.100 username password { 0:0:1 }

Глобальные параметры в начале CCcam.cfg

В шапке конфига живут директивы, которые влияют на reshare глобально. Несколько важных:

SHARE LIMITS: 10
CACHE EX HOPS: 2
ALLOW TIMEOUT: 3000
SERVER LISTEN PORT: 12000
WEBINFO LISTEN PORT: 16001

SHARE LIMITS — максимальное количество карт, которые один пир может получить от тебя. Если пир запрашивает больше — лишние обрезаются. Это глобальный потолок, который действует поверх индивидуальных настроек reshare.

CACHE EX HOPS — глубина кэша ECM-ответов. Не путать с reshare hops — это про кэш, а не про переотдачу карт.

ALLOW TIMEOUT выставлен в миллисекундах. 3000 — стандарт, при нестабильных линиях можно поднять до 5000.

Локальный reshare для отдельной карты через F: line

F-строки описывают локальных пользователей. Если хочешь переотдавать конкретному пользователю карту с определённой глубиной:

F: username password 1 0 0 { 0:0:1 }

Поля после логина/пароля: разрешить AU (1=да), максимальный uphops (0=без ограничений), минимальный uphops (0), и в скобках — reshare для этого клиента. Если у тебя ридер раздаёт локальную карту, а глобальный SHARE LIMITS режет CAID — карта не дойдёт до пира, даже если в F-строке всё правильно. Всегда проверяй оба уровня.

Где лежит конфиг: /var/etc/CCcam.cfg и /etc/CCcam.cfg

На ресиверах с прошивкой Enigma2 (Dreambox, Vu+, GigaBlue) конфиг обычно находится по пути /var/etc/CCcam.cfg. На других платформах — /etc/CCcam.cfg. Иногда встречается и /usr/local/etc/CCcam.cfg, зависит от того, как установлен демон.

После любой правки конфига изменения не применятся сами по себе. Нужен перезапуск демона:

# На Enigma2:
/etc/init.d/CCcam restart

# Или через команду:
killall -9 CCcam && CCcam &

Это частая ошибка: поправил reshare, подождал — ничего не изменилось. А демон просто не перечитал конфиг.

Ограничение глубины: hops, uphops и защита от петель

Это та часть, которую большинство мануалов объясняют криво. Покажу, как hops и uphops работают в паре — потому что смотреть на один параметр без другого бессмысленно.

Выставление максимального hop count

Представь цепочку: Сервер A → Сервер B (ты) → Сервер C. Сервер A отдаёт тебе карту с reshare 2. Это значит, карта может уйти ещё на 2 узла вниз. Ты получил её на hop=1. Когда ты переотдаёшь её серверу C — он получит её на hop=2. Если у тебя в C-строке к серверу C написано reshare 1 — сервер C сможет переотдать её ещё одному клиенту вниз.

Рекомендую держать reshare на значении 1 в большинстве случаев. Значение 2 нужно только если у тебя трёхзвенная цепочка и ты знаешь, что делаешь. Значение 3 и выше — карта уходит куда-то в интернет бесконтрольно.

Параметр uphops для приёма карт

Теперь сторона приёма. Если ты выставил uphops 2 в N-строке или в настройках пользователя — ты говоришь: «принимать только карты, которые прошли не более 2 hops». Карта с hop=3 будет отрезана на входе.

Классическая ситуация: ты включил reshare, пир говорит «карты не вижу». Смотришь — в его конфиге uphops 1, а карта приходит к нему уже с hop=2. Обрезается. Решение: либо снизить глубину цепочки, либо увеличить uphops у пира.

Параметр EMU RESHARE отдельно стоит упомянуть. Он управляет переотдачей карт, расшифрованных через программные эмуляторы (SoftCAM). Если у тебя CCcam работает с встроенным эмулятором и ты хочешь, чтобы эти карты тоже уходили пирам — нужно явно включить:

EMU RESHARE: yes

По умолчанию эмулируемые карты к переотдаче не готовы.

Предотвращение зацикливания линий

Петля возникает, когда два сервера взаимно переотдают одну и ту же карту друг другу. Сервер A получает карту от B и переотдаёт её B. B получает карту от A (которую он же и дал) и переотдаёт её обратно A. Кэш засоряется, нагрузка растёт, ECM-ответы начинают тормозить.

CCcam пытается детектировать петли по идентификатору карты, но не всегда успешно. Лучшая защита — осознанная архитектура: если вы с пиром обмениваетесь линиями, хотя бы один из вас должен поставить reshare 0 для карт другой стороны. Или использовать разные CAID в шаринге, чтобы одна и та же карта не ходила туда-обратно.

Проверка и диагностика reshare

Настроить — полдела. Надо ещё убедиться, что reshare реально работает. CCcam даёт несколько инструментов для этого.

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

По умолчанию веб-морда CCcam доступна на порту 16001. Открываешь в браузере http://192.168.1.X:16001 и видишь статус сервера. Порт меняется через директиву в конфиге:

WEBINFO LISTEN PORT: 16001

Если порт занят или веб-интерфейс не отвечает — проверь, запущен ли демон и не заблокирован ли порт файрволом.

Чтение раздела Active clients и Shares

В веб-интерфейсе два раздела интересуют при отладке reshare: Shares и Active clients.

В разделе Shares видно все карты, которые знает сервер: их CAID, provider, и — что важно — с каким hop они пришли. Если карта пришла с hop=1, это значит ты получил её напрямую от источника. Hop=2 — через один промежуточный узел. Также видно значение reshare для каждой карты — то, с каким параметром ты её получил и с каким отдаёшь.

В Active clients видно подключённых пиров и какие карты они у тебя запрашивают. Если пир подключён, но карта не уходит к нему — смотри на колонку hop и reshare value для этой карты. Если reshare=0, карта не переотдаётся. Если hop у карты больше, чем uphops у пира — та же история.

Telnet и лог-файлы для отладки

CCcam умеет в telnet. Подключаешься на порт 16000 (или другой, указанный в конфиге) и можешь смотреть статус в реальном времени:

telnet 192.168.1.X 16000

Лог-файл CCcam обычно лежит в /tmp/CCcam.log или /var/log/CCcam.log. В нём видны события подключения/отключения пиров и, что важнее, отказы в переотдаче карт с причиной. Ищи строки с RESHARE и HOP — они подскажут, где обрыв цепочки.

Если карта приходит в лог, но пир её не видит — проблема на стороне пира (его uphops или его конфиг). Если карта не появляется в логе вообще — проблема на входе, у источника.

Reshare в OScam: эквивалент настройки

OScam всё чаще используется как замена CCcam — он стабильнее, гибче и активно поддерживается. Но логика reshare там другая, и при переходе с CCcam люди теряются. Вот как это работает в OScam, если ты общаешься с CCcam-пирами по протоколу CCcam.

Параметр cccreshare в oscam.server

Файл /etc/oscam/oscam.server описывает ридеры и подключения к пирам. Для каждого CCcam-пира можно задать глубину reshare прямо в секции ридера:

[reader]
label                 = peer_name
protocol              = cccam
device                = hostname,12000
user                  = username
password              = password
cccreshare            = 1
ccchop                = 2

cccreshare здесь — это аналог reshare в C-строке CCcam. Значение 1 означает, что карты от этого ридера переотдаются на 1 hop вниз. ccchop — ограничение на глубину принимаемых карт (аналог uphops).

Глобальный cccreshare в oscam.conf

В файле /etc/oscam/oscam.conf есть секция [cccam], где задаётся глобальное значение по умолчанию:

[cccam]
port                  = 12000
reshare               = 1
reshare_mode          = 0
cccmaxhops            = 10

Параметр reshare здесь — глобальный дефолт для всех CCcam-соединений. Значение в секции [reader] (через cccreshare) имеет приоритет над глобальным. Так что если хочешь разное поведение для разных пиров — задавай в каждом ридере отдельно.

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

reshare_mode — режим переотдачи. Значение 0 означает, что переотдаются только карты из ридеров с явно заданным cccreshare. Значение 1 — переотдаётся всё что есть. Лучше держать 0 и управлять явно.

Связка OScam-сервер с CCcam-пирами

Смешанная цепочка CCcam → OScam → CCcam работает, потому что OScam реализует протокол CCcam. Но есть нюанс: когда OScam получает карту от CCcam-источника и отдаёт её CCcam-пиру, hop счётчик продолжает расти. Если источник отдал карту с reshare 2, а OScam-узел прибавляет +1 hop, до конечного CCcam-клиента карта придёт с hop=2 — и если у него uphops 1, она будет обрезана.

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