CCcam reshare: настройка C/F-строк и протокола

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

Что такое reshare в CCcam и как работает hop/depth

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

Принцип решаринга: от карты к клиенту через пиры

Схема выглядит так: у провайдера стоит физический ридер с картой → ваш сервер подключается к его CCcam-серверу → ваши клиенты подключаются к вам. Карта физически находится у источника, а дальше по цепочке идут только ECM-запросы и CW-ответы (Control Words). Reshare — это и есть передача этих CW от вашего сервера клиентам, которые сами к источнику не подключены.

Параметр hop: что означают значения 0, 1, 2

Hop — это счётчик «прыжков» карты от источника до текущего узла. Карта, вставленная в физический ридер на сервере, имеет hop 0 (local). Когда вы получаете её через C-строку от пира — у вас она приходит как hop 1. Если вы раздаёте её своему клиенту, у него это уже hop 2. Каждый прыжок добавляет задержку ECM — обычно от 50 до 150 мс на узел, в зависимости от железа и нагрузки.

Depth (глубина) и почему она ограничивает цепочку

Depth — это максимально допустимое значение hop, при котором карта ещё раздаётся дальше. Если depth равен 2, карта с hop 2 уже не уйдёт следующему клиенту. Параметр задаётся через downhops в F-строке. Именно он отвечает за то, насколько глубоко карта может «провалиться» по цепочке раздачи от вашего сервера.

Чем reshare отличается от прямого доступа к карте (local)

Local-карта (hop 0) — это то, что у вас в ридере прямо на сервере. Она самая быстрая, ECM time минимальный. Решарная карта всегда идёт через сеть, и каждый узел добавляет время. Провайдеры часто ставят ограничение на максимальный hop — например, не принимают карты с hop выше 3. Это не каприз, а защита от деградации сигнала ECM в длинных цепочках.

Настройка reshare в файле CCcam.cfg: F-строки и значения

Весь CCcam reshare: настройка сводится к двум типам строк в конфиге: C-строки (client) принимают карты от пира, F-строки (friend) раздают карты своим клиентам. Перепутать их нельзя — это принципиально разные направления потока.

Расположение конфига: /var/etc/CCcam.cfg

Основной конфиг лежит по пути /var/etc/CCcam.cfg. На некоторых дистрибутивах под Linux можно встретить /etc/CCcam.cfg или /usr/local/etc/CCcam.cfg — зависит от того, как собран пакет. Всегда проверяйте реальный путь через ps aux | grep CCcam — там будет ключ -c с указанием файла.

Структура F-строки: F: { username password downhops uphops }

Формат такой:

F: username password downhops uphops

username и password — учётные данные клиента, который подключается к вашему серверу. downhops — на сколько уровней клиент может раздавать вашу карту дальше своим клиентам. uphops — сколько уровней карт от клиента вы принимаете в обмен (при взаимном обмене). Значение 1 для downhops означает, что клиент получит карту и может отдать её ещё одному уровню вниз. Значение 0 — карту получает, но дальше не раздаёт.

Глобальная директива RESHARE и локальная per-user

Глобально включить reshare можно директивой в начале конфига:

RESHARE: 1

Это разрешает раздачу по умолчанию всем F-строкам. Но можно переопределить на уровне конкретного пользователя, добавив перед его F-строкой:

RESHARE: 0
F: restricteduser pass123 0 0

Тогда именно этот пользователь карты не получит для дальнейшей раздачи, даже если глобально RESHARE включён. Per-user настройка перекрывает глобальную — это удобно, когда у вас смешанная база клиентов.

Параметр 'F: user pass 1 0' — раздать только свои карты без приёма

Строка F: clientuser pass123 1 0 означает: клиент получает карты и может раздать их ещё на один уровень вниз (downhops=1), но вы от него ничего не принимаете (uphops=0). Это типичная схема для одностороннего решаринга — когда у вас есть карты, вы их раздаёте, но в обмен ничего не хотите.

Пример блока для решаринга конкретной карты

Рабочий пример минимального конфига с C-строкой получения и F-строкой раздачи:

# Получаем карту от пира
C: peer.example 12000 peerlogin peerpass01

# Глобальный решар включён
RESHARE: 1

# Клиент получает карты, может раздать ещё 1 уровень вниз
F: myclient securepass 1 0

# Этому клиенту запрещаем дальнейшую раздачу
RESHARE: 0
F: viewonly viewpass 0 0

После любых правок в конфиге — обязательно перезапустить демон. Через init.d: /etc/init.d/CCcam restart. Или жёстко: kill -9 $(pidof CCcam) && CCcam. Без перезапуска изменения не применяются — это не nginx с reload.

Ограничение и фильтрация решара по картам и провайдерам

Раздавать вообще все карты всем подряд — плохая идея. Особенно если у вас есть локальные карты, которые не должны уходить в reshare, или если вы хотите ограничить раздачу по конкретным CAID.

Раздача только нужных CAID/provid через F: { caid:provid }

CCcam поддерживает фильтрацию по CAID и провайдеру прямо в F-строке. Синтаксис:

F: username password 1 0 { caid:provid }

Например, раздать только карты Viasat (CAID 0x0500) от провайдера 0x040E00:

F: viaclient viapass 1 0 { 0500:040E00 }

Можно перечислить несколько через запятую. Всё, что не попадёт под фильтр, клиент не увидит — даже если у вас на сервере есть другие карты.

Запрет решара отдельных карт (sid/ident фильтры)

Фильтрация по SID (Service ID) работает аналогично — через расширенный синтаксис блоков. Но честно: в чистом CCcam это реализовано слабее, чем в OScam. Если нужна тонкая фильтрация по SID — лучше рассмотреть OScam-конвертацию (об этом ниже).

Параметр 'RESHARE: 0' для запрета дальнейшей раздачи

Если нужно, чтобы клиент вообще не мог раздавать карты — ставьте RESHARE: 0 перед его F-строкой и оба значения hop в 0:

RESHARE: 0
F: enduser pass 0 0

Это работает как «тупик» в цепочке. Карта туда доходит и там остаётся.

Файл oscam.server при работе через OScam-конвертацию

Если часть вашей сети работает через OScam, настройка решаринга идёт через /etc/oscam/oscam.server и /etc/oscam/oscam.user. В oscam.server для cccam-ридера добавляется параметр:

[reader]
label = mypeer
protocol = cccam
device = peer.example,12000
user = peerlogin
password = peerpass01
cccreshare = 2

Значение cccreshare = 2 означает, что OScam будет раздавать полученные карты до hop 2. В oscam.user для каждого пользователя аналогично:

[account]
user = oscamclient
pwd = pass
cccreshare = 1

Логика hop та же, что в CCcam F-строках, но синтаксис другой. В смешанной сети (часть пиров на CCcam, часть на OScam) это один из самых частых источников путаницы — люди настраивают hop с одной стороны и забывают согласовать с другой.

Порты, протокол и проверка работы reshare

Настроить конфиг — полдела. Важно убедиться, что reshare реально работает, а не просто выглядит правильно на бумаге.

Порт CCcam по умолчанию 12000 и директива SERVER LISTEN PORT

Стандартный порт CCcam для обмена с пирами — 12000. В конфиге задаётся директивой:

SERVER LISTEN PORT: 12000

Этот порт должен быть открыт в firewall и проброшен на роутере, если сервер за NAT. Классика: всё настроено, но клиент за CGNAT и его порт 12000 недоступен снаружи — решар с его стороны просто не поднимется. Проверить доступность порта можно с внешней машины через nc -zv your.server.ip 12000.

Версия протокола CCcam 2.x.x и совместимость пиров

Протокол CCcam версии 2.x.x (актуально 2.3.x) — де-факто стандарт. Проблемы совместимости возникают когда один сервер работает на старой версии 2.0.x, а другой на 2.3.x. Конкретно это проявляется в неверной передаче hop-значений и усечении списка карт. Если пир «видит» меньше карт, чем должен — проверьте версии с обеих сторон.

Просмотр активных карт в веб-интерфейсе (порт 16001)

Веб-интерфейс CCcam доступен на порту 16001. Открываете в браузере http://your.server.ip:16001 — там вкладка Shares показывает все карты, которые сейчас видит сервер. Для каждой карты отображается CAID, провайдер и текущее значение hop. Это самый быстрый способ убедиться, что решар поднялся и карта дошла до нужного уровня.

Если карта есть в Shares с hop 1, но клиент её не видит — проблема в F-строке или RESHARE-директиве. Если карты в Shares нет вообще — проблема с C-строкой или соединением с пиром.

Команды диагностики: статус линий, hop карт, ECM time

Смотреть лог в реальном времени: tail -f /tmp/CCcam.log. Там видно ECM time для каждого запроса — нормальное значение до 500 мс, всё выше 1000 мс — уже тревожно, выше 2000 мс — гарантированные фризы. В веб-морде вкладка ECM info показывает среднее время по каждой карте. Если ECM time у решарной карты сильно выше, чем у той же карты у источника — цепочка слишком длинная.

Частые ошибки настройки reshare и что НЕ работает

Разберём антипаттерны — то, что люди делают неправильно чаще всего.

Зацикливание (loop) при взаимном решаре двух серверов

Классическая петля: сервер A обменивается картами с сервером B, оба с uphops=1. Сервер A отдаёт карту серверу B → B считает её своей и отдаёт обратно серверу A → A получает ту же карту с hop на единицу больше. В итоге в сети циркулируют дубли одной карты с разными hop-значениями, нагрузка растёт, ECM-запросы начинают идти по неоптимальному маршруту.

Решение: при взаимном обмене ограничить uphops с обеих сторон. Если у A локальная карта hop 0, то B должен принимать её с uphops не больше 1, и при отдаче обратно серверу A — A должен отклонять карты с hop >= 1 от B (то есть uphops=0 для обратного направления). Настраивайте взаимный обмен асимметрично — не копипастите одну F-строку на оба сервера.

Карта не появляется у клиента: hop превышен

Если карта есть в Shares сервера с hop 2, но у клиента её нет — проверьте downhops в F-строке. Если downhops=1, клиент получит карту только если она идёт с hop не выше 1 (то есть карта local + 1 hop). Карта с hop 2 уже не пройдёт. Увеличьте downhops до 2 или оптимизируйте цепочку, чтобы карта приходила с меньшим hop.

Фриз каналов из-за длинной цепочки hop

Длинная цепочка — это не только про теорию. На практике: hop 1 даёт ECM time ~200–400 мс, hop 2 — 400–700 мс, hop 3 и выше — уже рулетка. Некоторые каналы начинают фризить при ECM time выше 600 мс — особенно каналы с агрессивными EMM или частой сменой CW. Reshare не «чинит» медленный источник — если карта наверху даёт 800 мс, внизу по цепочке будет 1200+ и фризы неизбежны.

Почему 'F: user pass 0 0' блокирует раздачу

Это самая частая путаница у новичков. Строка F: user pass 0 0 создаёт аккаунт пользователя, но с нулевыми hop — карт он не получит. Это не «клиент без решара», это «клиент без ничего». Если хотите дать пользователю карты, но запретить их раздачу дальше — используйте RESHARE: 0 перед строкой, а downhops оставьте 1. Или просто не добавляйте RESHARE директиву, но ставьте downhops=0 — тогда клиент видит карты, но не может их передать.

И ещё один кейс: пир за NAT/CGNAT. Если у клиента закрыт порт 12000 и он не проброшен — входящие подключения к нему не проходят. Он сам может подключиться к вашему серверу по исходящему соединению, но поднять обратный канал для решара не сможет. Проброс порта или VPN-туннель — единственный выход.