CCcam reshare: настройка сервера и C-line в 2026

Если вы уже держите рабочий CCcam-сервер и понимаете, что такое C-line, — эта статья для вас. CCcam reshare: настройка пересдачи карт между пирами — тема, которую большинство гайдов либо обходит стороной, либо объясняет на уровне "поставь 2 и будет работать". Не будет. По крайней мере, не всегда. Разберём конкретно: синтаксис, приоритеты параметров, типичные петли и связку с OScam.

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

Reshare простыми словами: пересдача полученной линии

CCcam получает ECM от вышестоящего пира, расшифровывает его и отдаёт DCW своим клиентам. Reshare — это когда сервер не просто отдаёт DCW клиенту-ресивер, а позволяет другому CCcam-серверу забрать этот сервис и раздать его дальше своим клиентам. То есть пересдача.

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

Что такое hop (хоп) и как считаются уровни 1, 2, 3

Hop — это количество промежуточных серверов между источником карты и конечным пользователем. Hop 1 означает, что карта пришла с локального ридера или смарт-карты напрямую. Hop 2 — вы получили карту от пира и раздаёте её своим клиентам. Hop 3 — ваш клиент тоже является CCcam-сервером и пересдаёт дальше.

Параметр reshare в строке говорит серверу: "позволь следующему уровню пересдать это ещё раз". Если выставить reshare = 1, карта уйдёт на один уровень ниже вас, но дальше не пойдёт. Значение 0 означает полный запрет пересдачи.

Разница между локальными картами и пересданными от пира

Локальные карты (физические смарт-карты в ридере или EMM) всегда имеют hop 1. Их можно раздавать без ограничений — они ваши. Карты от пира приходят уже с hop 2+. Именно здесь важен параметр uphops: он показывает, сколько промежуточных серверов уже было до вас.

Если пир прислал карту с uphops = 1 и без права reshare — канал у вас откроется, но отдать эту карту своему суб-пиру не получится. Это не ошибка конфига — это ограничение, установленное выше по цепочке.

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

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

Файл конфигурации обычно лежит по одному из двух путей: /var/etc/CCcam.cfg (Enigma2-боксы) или /usr/keys/CCcam.cfg (некоторые дистрибутивы). Редко, но встречается /etc/CCcam.cfg. Проверьте запущенный процесс командой ps aux | grep CCcam — там будет путь к конфигу.

Глобальные параметры reshare выглядят так:

RESHARE : 2
MAXHOPS : 3
GLOBAL LISTEN PORT : 12000

RESHARE : 2 означает, что по умолчанию все карты раздаются с глубиной пересдачи 2. Но это именно дефолт — строчные параметры в C-line и F-line имеют приоритет над глобальными. Это ключевой момент, который часто упускают.

Параметр reshare в C-line и N-line

C-line — это строка подключения к чужому серверу, то есть вы клиент:

C: hostname.example 12000 myuser mypassword no { 0:0:2 }

Разбор фигурных скобок { caid:provid:reshare }: 0:0:2 означает "все CAID, все провайдеры, reshare = 2". Это значение говорит вашему серверу, с каким hop-лимитом принимать карты от этого пира и передавать их дальше.

N-line работает аналогично, но используется для Newcamd-соединений. Синтаксис чуть другой, но принцип тот же — фигурные скобки определяют reshare для конкретного соединения.

Настройка раздачи через F-line (friend)

F-line — это строка, которой вы описываете своего "друга" или клиента-сервера, которому раздаёте карты:

F: frienduser friendpass 1 0 0 { 0:0:2 }

Три числа после пароля: первое — uphops (сколько hop от источника принимать), второе — downhops (сколько hop вниз разрешать), третье — reshare (разрешить ли пересдачу дальше). В фигурных скобках — тонкая настройка по CAID и провайдеру.

Если глобально стоит RESHARE : 2, но в F-line написано { 0:0:0 } — карта не уйдёт дальше. Строка побеждает глобал. Всегда.

Где физически лежит файл: /var/etc/CCcam.cfg и /usr/keys/

После правки конфига сервис нужно перезапустить. На Enigma2:

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

Или через init-скрипты: /etc/init.d/CCcam restart. На некоторых сборках путь к бинарнику — /usr/bin/CCcam, на других — /usr/local/bin/CCcam. Проверьте через which CCcam.

Ограничение reshare: контроль hop, провайдеров и CAID

Ограничение по CAID и provider ID в скобках

Формат фильтрации позволяет точечно управлять пересдачей конкретных карт. Пример: разрешить пересдачу только для Viaccess с provider ID 032830 и только на один уровень:

{ 0500:032830:1 }

Для Nagravision 3 (CAID 1830) с запретом пересдачи:

{ 1830:000000:0 }

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

Параметры MAXHOPS и RESHARE глобально

MAXHOPS : 3 — жёсткий потолок. Карты с hop > 3 сервер не примет вообще, даже если пир их предлагает. Это защита от длинных нестабильных цепочек.

RESHARE : 2 — дефолтная глубина для всех соединений, где не задан индивидуальный параметр. Хорошее значение для типичной сети: принимаете от пира (hop 2) и раздаёте своим клиентам (hop 3), дальше не идёт.

Запрет пересдачи отдельных карт (no reshare)

Иногда нужно отдать клиенту определённый пакет, но запретить ему пересдавать конкретную карту. Для этого в F-line ставится { caid:provid:0 }:

F: clientuser clientpass 2 1 0 { 0500:032830:0, 0:0:1 }

Здесь для Viaccess 032830 reshare = 0, для всего остального reshare = 1. Клиент получит и то, и другое, но Viaccess 032830 пересдать дальше не сможет.

Контроль числа подключений и uphops/downhops

Директива DOWNHOPS : 2 в глобальном конфиге ограничивает, на сколько уровней вниз карта уходит от вашего сервера. Uphops — ограничение по количеству hop от источника до вас при приёме. Эти параметры работают как дополнительные фильтры поверх значений в строках.

Проброс портов, firewall и проверка соединения

Открытие порта 12000 (TCP) на роутере

CCcam по умолчанию слушает TCP 12000. Если сервер за NAT — нужен проброс порта. На большинстве домашних роутеров это делается в разделе "Port Forwarding" или "Virtual Servers". Пробросьте внешний TCP 12000 на внутренний IP сервера, тот же порт.

Двойной NAT (провайдерский + роутерный) — отдельная боль. Если провайдер сам использует CGNAT, внешний IP у вас серый, и входящие соединения просто не дойдут. В таком случае либо договаривайтесь с провайдером о белом IP, либо используйте VPN-туннель (OpenVPN, WireGuard) между пирами.

На самом сервере проверьте firewall. Для iptables:

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

Проверка через telnet и веб-интерфейс CCcam (порт 16001)

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

telnet  12000

Если соединение установилось — порт открыт. CCcam также держит HTTP-интерфейс на порту 16001. Зайдите в браузере на http://<ip>:16001 — там видны все подключённые клиенты, серверы, активные карты и их hop. Именно здесь смотрите, передаётся ли reshare: в разделе "Clients" у подключённого пира должны быть видны карты с соответствующим hop-значением.

Настройка на OScam-стороне: reader и [account] reshare

Если в вашей сети смешана связка CCcam ↔ OScam — нужно знать эквиваленты параметров. В файле /etc/oscam/oscam.server для ридера, подключающегося к CCcam-серверу:

[reader]
label         = cccam_peer
protocol      = cccam
device        = hostname.example,12000
user          = myuser
password      = mypassword
cccreshare    = 2
cccversion    = 2.3.0
ccckeepalive  = 1

Параметр cccreshare здесь — аналог reshare в C-line CCcam. В файле /etc/oscam/oscam.user для аккаунта, которому OScam раздаёт карты:

[account]
user          = clientuser
pwd           = clientpass
cccreshare    = 1

Согласование версии протокола через cccversion важно: если CCcam-сервер работает на 2.3.x, а OScam представляется как 1.x — reshare может интерпретироваться по-другому или вообще не передаваться.

Проверка статуса пиров и активных reshare

В веб-интерфейсе OScam (http://<ip>:8888) смотрите раздел "Readers" — там виден статус подключения к CCcam-пиру и количество полученных карт. В CCcam-интерфейсе (порт 16001) раздел "Servers" покажет, что ваш сервер получил от каждого пира и с каким hop.

Типичные ошибки reshare и что НЕ работает

Каналы открываются, но reshare не уходит дальше

Это самый частый вопрос. Канал открывается — значит, DCW доходит до вашего декодера. Но суб-пир жалуется, что карта не видна. Причины по убыванию вероятности:

• В F-line для суб-пира стоит { 0:0:0 } или reshare = 0 явно — проверьте строку
• Вышестоящий пир отдал карту без права reshare — uphop пришёл, но reshare = 0 на его стороне
• Глобальный MAXHOPS слишком маленький, и карта с hop 2 не передаётся дальше
• Firewall блокирует входящее соединение от суб-пира на порт 12000

Смотрите логи: tail -f /tmp/CCcam.log или cat /tmp/CCcam.log | grep reshare. Там будет видно, почему карта не передаётся.

Зацикливание (loop) и дубли карт в сети

Если два CCcam-сервера добавили друг друга в C-line и оба разрешили reshare — образуется петля. Сервер А получает карту от Б и пересдаёт её обратно Б. Б видит "свою" карту дважды: оригинал и пересданный дубль с hop+1. Это засоряет сеть, увеличивает нагрузку и может вызвать нестабильность.

Решение простое: если вы подключены к пиру как клиент (C-line), не добавляйте его же в F-line с reshare > 0. Либо используйте директиву CARD LOOP PROTECTION : yes в CCcam.cfg — она фильтрует дубли по идентификатору карты.

Слишком большой hop — нестабильность и фризы

Каждый дополнительный hop — это дополнительная задержка получения DCW. На практике: hop 1 даёт задержку 50–150 мс, hop 3 — уже 300–500 мс и больше. Для стандартных CAID (Nagravision, Viaccess) это ещё терпимо. Но для карт с частой сменой ключей — каждые 10–30 секунд — задержка в 400 мс на hop 3–4 гарантирует постоянные фризы.

Держите цепочку короткой. Hop 1–2 — норма. Hop 3 — пограничное состояние. Hop 4+ — почти всегда фризы на динамичных каналах.

Чего избегать при настройке пересдачи

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

Отрицательные значения reshare (например, -1) CCcam просто игнорирует, трактуя их как 0. Дублирование одной и той же карты от двух разных пиров не повышает стабильность — сервер будет использовать первый ответивший источник, второй будет простаивать. Для реального резерва нужна грамотная приоритизация через PRIORITY CAID OVER PROVID или OScam с его load-balancing.

CCcam reshare: настройка с умом — это не только правильный синтаксис, но и понимание договорённостей с пирами и архитектуры всей сети.