Настройка reshare в OScam: гайд по конфигу 2026

OScam reshare: настройка этого механизма — одна из тех тем, где половина инструкций в интернете либо неполная, либо устаревшая. Люди часами правят конфиги и не понимают, почему карта не уходит дальше одного узла. Чаще всего проблема в том, что никто не объясняет, как group в oscam.server связан с group в oscam.user — а без этой связи хоть какие значения reshare ставь, ничего не заработает.

Здесь разберём механику hops, параметры по файлам, пошаговую настройку и диагностику. Без воды — только конфиги и логика работы.

Что такое reshare в OScam и как работает механика hops/group

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

Без явного разрешения reshare OScam по умолчанию не позволяет клиенту отдавать карту дальше. Это поведение контролируется параметрами в трёх файлах конфигурации.

Reshare простыми словами: переотдача карты дальше по цепочке

Схема цепочки выглядит так: сервер → клиент → субклиент. Сервер держит карту (hop 0). Клиент получает её по CCcam/NEWCAMD — у него hop 1. Если reshare разрешён, субклиент получает карту уже с hop 2.

Значения reshare работают так: reshare = -1 — переотдача полностью запрещена. reshare = 0 — карта видна только локально, не реширится. reshare = N — карта может уйти на N узлов вглубь. Значение reshare = 1 даёт клиенту право отдать карту одному уровню субклиентов.

Что такое hop (uphops/downhops) и почему он ограничивает глубину

Hop — это счётчик расстояния карты от источника. Каждый раз, когда карта передаётся следующему узлу, hop увеличивается на 1. Карта с hop 0 или 1 считается "локальной" и наиболее стабильной. Чем выше hop — тем больше задержка ECM и тем нестабильнее соединение.

Параметр cccmaxhops задаёт максимальный hop, который сервер примет от пира. Если карта приходит с hop 4, а у вас стоит cccmaxhops = 3, карта будет отсечена. Это нужно учитывать: если вы принимаете карты уже с hop 2-3 и хотите реширить их дальше, суммарная глубина цепочки может выйти за ваш лимит.

Роль group: как группы изолируют, кому карта реширится

Вот что большинство статей пропускает. В OScam каждый reader (источник карты в oscam.server) принадлежит одной или нескольким группам через параметр group. Каждый account (клиент в oscam.user) тоже имеет свой group. Карта из reader реширится клиенту только тогда, когда их группы пересекаются — то есть есть хотя бы один общий номер группы.

Если у reader стоит group = 1, а у account group = 2 — reshare не заработает, даже если все остальные параметры правильные. Перечислять несколько групп можно через запятую: group = 1,2,3. Если у клиента нужны карты из двух reader с разными группами — в account нужно указать оба номера.

Параметры reshare в oscam.server и oscam.user: разбор по строкам

Файлы конфигурации лежат в разных местах в зависимости от платформы. На обычном Linux-сервере это /usr/local/etc/oscam.server, /usr/local/etc/oscam.user, /usr/local/etc/oscam.conf. На enigma2-ресиверах (Dreambox, VU+, Octagon и т.д.) конфиги обычно в /etc/tuxbox/config/oscam/. Типичная ошибка — редактировать файл на сервере, а реальный конфиг лежит на ресивере в другом месте.

cccam reshare и cccmaxhops в секции [cccam] протокола

В файле oscam.conf есть секция [cccam], которая задаёт глобальные параметры протокола CCcam. Вот пример:

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

Здесь reshare = 1 — глобальное разрешение на один уровень переотдачи для всех. cccmaxhops = 10 — максимальная глубина цепочки карт, которую сервер примет. Это глобальные значения, они действуют на всех клиентов, если не переопределены на уровне account.

reshare в блоке reader (oscam.server) для конкретного пира

В oscam.server для каждого reader можно задать свой уровень reshare. Пример блока reader:

[reader]
label                    = peer_01
protocol                 = cccam
device                   = 192.168.1.100,12000
user                     = myuser
password                 = mypass
group                    = 1
reshare                  = 2
cccmaxhops               = 5

Параметр reshare = 2 здесь означает, что карты, полученные от этого reader, могут уйти на два уровня вглубь. group = 1 — только клиенты с group 1 получат эти карты при reshare.

cccmaxhops и cccreshare в блоке account (oscam.user)

В oscam.user для каждого клиента можно переопределить reshare индивидуально. Пример account:

[account]
user                     = client_01
pwd                      = secretpass
group                    = 1
reshare                  = 1
cccreshare               = 1
cccmaxhops               = 3
au                       = 1

cccreshare — это переопределение reshare именно для протокола CCcam в блоке account. Оно имеет приоритет над глобальным reshare из [cccam] в oscam.conf. cccmaxhops = 3 здесь означает, что этот конкретный клиент не получит карты с hop выше 3.

Глобальные значения в oscam.conf и приоритет переопределения

Приоритет работает так: значение в блоке account или reader переопределяет глобальное из [cccam]. Но есть важное правило цепочки — фактический лимит reshare по всей цепочке равен минимальному значению из всех узлов.

Если у вас стоит reshare = 5, но у вашего пира-источника стоит reshare = 1, карта уйдёт максимум на 1 уровень — ваш более высокий лимит просто проигнорируется. Это же работает в обратную сторону: ваш высокий reshare не поможет, если клиент на своей стороне жёстко ограничил приём карт.

Пошаговая настройка reshare: от группы до проверки линии

Вот последовательность, которая реально работает. OScam reshare: настройка требует согласованности трёх файлов, поэтому делаем всё по порядку.

Шаг 1: назначить общий group для reader и account

Открываем /usr/local/etc/oscam.server и в блоке нужного reader прописываем group = 1 (или любой другой номер). Затем открываем /usr/local/etc/oscam.user и в блоке клиента, которому нужно реширить карты из этого reader, прописываем тот же номер группы: group = 1.

Если один клиент должен получать карты из нескольких reader с разными группами — перечисляем все: group = 1,2. Без совпадения группы дальнейшие шаги бессмысленны.

Шаг 2: задать reshare/cccreshare и cccmaxhops

В блоке reader в oscam.server ставим reshare = 2 (или нужную глубину). В блоке account клиента в oscam.user ставим cccreshare = 1 и cccmaxhops = 5. Консервативное значение cccmaxhops — 2–5. Не ставьте 10+ без необходимости, иначе карты расползутся далеко и нагрузка на сервер вырастет.

В oscam.conf в секции [cccam] глобальный reshare можно оставить как fallback: reshare = 1.

Шаг 3: включить webif и проверить статус в разделе Readers/Users

В oscam.conf добавляем или проверяем секцию веб-интерфейса:

[webif]
httpport                 = 8888
httpuser                 = admin
httppwd                  = adminpass
httprefresh              = 10
httpallowed              = 127.0.0.1,192.168.1.0/24

После рестарта OScam веб-интерфейс доступен на http://<ip>:8888. В разделе Readers смотрим колонки hop и reshare — там видно, какие карты пришли и с каким hop. В разделе Users — что реально отдаётся клиентам.

Рестарт сервиса: service oscam restart или /etc/init.d/oscam restart. Проверить, что порт CCcam слушается: ss -tlnp | grep 12000.

Шаг 4: проверить hop и reshare через лог уровня debug

В oscam.conf в секции [global] временно ставим debuglevel = 255. После рестарта в логе появятся строки вида:

2026/01/15 14:22:31 c (client_01) card added { 0500:000000 } hop=1 reshare=1

Здесь видно: карта добавлена клиенту client_01 с hop 1 и reshare 1. Если строки с card added нет — значит, карта до клиента не дошла, и надо смотреть причину в логах выше.

Отладка reshare: логи, уровни debug и чтение цепочки

Диагностика — самая полезная часть, когда что-то идёт не так. OScam пишет подробные логи, нужно только правильно их читать.

Уровни логирования и параметр debug в oscam.conf

В секции [global] файла oscam.conf параметр debuglevel работает как битовая маска. Значение 65535 включает всё. Для диагностики reshare достаточно 255. После отладки обязательно снизить до 0 или 64 — иначе логи забьют диск.

[global]
logfile                  = /var/log/oscam/oscam.log
debuglevel               = 255
loghistorysize           = 4096

Параметр loghistorysize задаёт, сколько строк лога хранится для просмотра через webif. При значении 4096 история достаточно большая, чтобы найти нужный момент подключения клиента.

Как увидеть, на каком hop отвалилась переотдача

В логе ищем строки с именем клиента и словами card или no card. Если видите что-то вроде:

2026/01/15 14:23:10 c (client_01) no card found for 0500:000000 (hop limit exceeded)

— значит, карта есть, но hop превышает cccmaxhops у этого account. Если строки нет вообще — скорее всего не совпадают group.

Чеклист: совпадают ли group у reader и account? Не равен ли reshare значению 0 или -1? Не достигнут ли cccmaxhops? Не стоит ли у пира-источника reshare ниже вашего? Проверяйте по порядку — в 90% случаев проблема в одном из этих пунктов.

Webif: колонки hop, reshare, ecmtime для диагностики

В веб-интерфейсе на странице Readers колонка hop показывает, с каким расстоянием карта пришла от источника. Колонка reshare — разрешённая глубина переотдачи для этой карты. Колонка ecmtime — время ответа в миллисекундах.

Если ecmtime выше 600–800 мс — карта нестабильна, скорее всего глубокая цепочка. Хорошие карты отвечают за 100–300 мс. На странице Users видно, какие карты клиент реально получил и с каким hop — это самый быстрый способ убедиться, что reshare работает.

Типичные ошибки настройки reshare и как их избежать

Вот что реально ломает настройку — и что не очевидно из документации.

Карта не реширится: несовпадение group

Самая частая ошибка. Reader с group = 1, account с group = 2 — reshare не работает, хотя все остальные параметры правильные. OScam не выдаёт явную ошибку об этом в обычном логе. Только при debuglevel = 255 в логе появится что-то похожее на no matching group.

Решение: убедиться, что хотя бы один номер группы совпадает у reader и account. Если клиенту нужны карты из нескольких reader — в account перечислить все нужные группы.

Reshare уходит слишком глубоко: занижаем cccmaxhops

Поставили reshare = 5 и cccmaxhops = 15 — и карты расползлись по десяткам субклиентов, нагрузка на сервер выросла, пошли тайм-ауты. Это реальная проблема при неконтролируемом reshare.

Нормальные значения: cccmaxhops = 2 для закрытого обмена между доверенными партнёрами, cccmaxhops = 5 максимум для более широкого распределения. Больше — только если точно знаете, зачем.

Конфликт глобального и локального reshare

В oscam.conf стоит reshare = 0, а в конкретном account поставили cccreshare = 2. Что победит? Локальное значение в account. Но если пользователь правит глобальный конфиг в надежде изменить поведение конкретного клиента — ничего не поменяется. Нужно редактировать блок account в oscam.user.

И обратная ситуация: в account стоит cccreshare = 3, но у пира-источника жёсткий reshare = 1. Фактический лимит — 1, потому что берётся минимум по всей цепочке.

Что НЕ работает: попытка реширить при reshare = 0

Если в блоке reader или в глобальной секции стоит reshare = 0 — клиент карту дальше не отдаст, независимо от cccmaxhops. Хоть cccmaxhops = 100 поставь. Нулевой или отрицательный reshare жёстко блокирует переотдачу — это и есть штатная защита от нежелательного распространения карт.

Как выбрать источник карт/пира для стабильного reshare

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

Критерии стабильного пира: аптайм, ecmtime, локальные карты

На что смотреть при выборе пира:

• ecmtime — время ответа ECM. Хороший показатель: до 300 мс. Больше 600 мс — нестабильно, при reshare субклиенты будут получать фриз.
• Аптайм — пир должен быть онлайн минимум 99% времени. Частые переподключения разрывают цепочку reshare.
• Hop карт — идеально hop 0 или 1 (локальные карты). Карты с hop 3+ уже имеют задержку и нестабильность, их reshare ещё на 1–2 узла — это заведомо плохой результат для субклиентов.
• Поддерживаемые пакеты — пир должен прозрачно указывать, какие CAID/пакеты он предоставляет, без туманных обещаний.

Почему важны локальные карты, а не длинные цепочки reshare

Карта hop 0 (физически вставлена в ридер на сервере) или hop 1 (получена от прямого владельца карты) — это надёжный источник. Время ответа предсказуемое, цепочка короткая. Если вы реширите такую карту на 2–3 уровня — субклиенты получат вполне приличное качество.

А вот если вы получаете карту с hop 5, потом реширите её ещё на 3 уровня — это цепочка из 8 узлов. Любой разрыв в любом месте — и вся цепочка падает. ECM начинает ходить через 8 серверов, задержки растут, фриз неизбежен.

Признаки ненадёжного источника

Чеклист: карты приходят с hop выше 3 — плохо. ecmtime скачет от 100 до 2000 мс непредсказуемо — плохо. Пир часто пересоединяется (в webif видно reconnects) — плохо. Нет информации о том, какие пакеты поддерживаются реально, только общие слова — плохо.

Хороший пир — это предсказуемость. Стабильный ecmtime, минимальный hop, понятный набор пакетов. Всё остальное создаёт проблемы при любом reshare.