Global Active Device в CCcam: что это и как настроить

Если вы настраивали CCcam и наткнулись на строку G: в конфиге или увидели упоминание global active device в логах — это не какой-то декоративный параметр. Это одна из ключевых настроек, которая напрямую определяет, как пиры воспринимают ваш сервер и сколько карт они от вас ждут. Неправильное значение = freeze каналов каждые 10 секунд, ECM-таймауты и дисконнекты со стороны пиров.

Разберём всё по порядку: что означает этот параметр на уровне протокола, как его правильно считать, где настраивать и как диагностировать проблемы.

Что такое Global Active Device в протоколе CCcam

Global active device — это число, которое CCcam-сервер объявляет удалённому пиру во время начального handshake. Оно говорит пиру: «у меня есть N активных карт-устройств, к которым я готов маршрутизировать ECM-запросы». Пир, получив это число, строит свой share-лист и понимает, на сколько карт он может рассчитывать.

Это не hop count и не reshare — это именно счётчик физических и логических источников декриптования. Путаница здесь дорого обходится.

Происхождение параметра G: в CCcam.cfg

Параметр появился в CCcam начиная с версии 2.1.x как способ явно контролировать декларацию мощности сервера. До этого количество карт вычислялось автоматически, что приводило к расхождениям между тем, что сервер обещал, и тем, что реально мог отдать.

В конфиге выглядит просто: строка G: 4 в начале /etc/CCcam.cfg или /var/etc/CCcam.cfg. Всё. Одна строка, одно число. Но от этого числа зависит поведение всей сети пиров.

Пример типичного конфига с F: линией:

G: 4
F: myuser mypassword 2 0 1
C: peer1.example.com 12000 user1 pass1
C: peer2.example.com 12000 user2 pass2

Здесь F: определяет, что клиент myuser может видеть карты с reshare до 2 хопов, а G: 4 говорит всем пирам, что у вас суммарно 4 активных устройства.

Разница между Active Device и Hop

Hop count (параметр reshare в F: строке) — это глубина переброски: сколько раз карта может быть пересдана между серверами. Global active device — это не про глубину, а про ширину: сколько уникальных источников карт у вас есть.

Можно иметь G: 1 и reshare 5 — один физический ридер, который передаётся через пять серверов. Или G: 10 и reshare 0 — десять ридеров, которые никому не пересдаются. Это совершенно разные вещи.

Как поле передаётся в network handshake

При установке CCcam-соединения между двумя серверами происходит обмен зашифрованными пакетами. Упрощённо структура выглядит так: после SHA1-хеша логина/пароля в handshake-пакете идёт блок с информацией о сервере, где один из байтов (или короткое целое, в зависимости от версии протокола) содержит именно значение global active device.

Пир читает это поле и записывает его в свою внутреннюю таблицу доступных карт. Если реальных карт окажется меньше — ECM-запросы начнут уходить в пустоту и возвращаться с таймаутом. Именно поэтому завышенное G: хуже, чем заниженное.

Как правильно считать активные устройства

Формула прямая: Global Active Device = локальные физические ридеры + рабочие C: линии с реальными картами на удалённой стороне. Dead-линии, резервные пиры в standby, линии которые коннектятся раз в сутки — не считать.

Пример: один локальный ридер со смарт-картой HD+ и три C: линии, все три онлайн и с картами. Итог: G: 4. Не 3, не 5 — именно 4.

Локальные ридеры (PCSC, smargo, internal)

Каждый физический ридер с вставленной рабочей картой = 1 устройство. Тут важный момент: если у вас PCSC ридер и smargo подключены одновременно, но в каждом по одной карте — это 2 устройства.

А вот если у одного провайдера (например, HD+) вы вставили две карты в два ридера — это 2 устройства, не 1. CCcam не схлопывает их по провайдеру; каждый ридер считается отдельно. Физически это разные точки декриптования с разными серийными номерами карт.

Другая ситуация: один физический ридер смарго с одной картой HD+ и одной картой Sky одновременно (если ридер поддерживает dual). Это по-прежнему 1 устройство — один ридер, пусть и с двумя CAID. В G: он идёт как 1.

Подключённые C: линии от других серверов

Каждая C: линия, которая реально онлайн и на удалённой стороне которой есть живые карты — +1 к счётчику. Но только если reshare на той стороне позволяет вам видеть карты.

Проверяйте в веб-интерфейсе CCcam (порт 16001), вкладка Servers: статус должен быть CONNECTED, а в колонке Shares должно быть ненулевое значение. Линия есть в конфиге, но показывает 0 shares — в G: она не идёт.

R: и N: линии — учитывать или нет

R: линии (Radegast) — не учитываются в G:. Это отдельный протокол, CCcam их не декларирует как часть global active device при обмене с CCcam-пирами.

N: линии (newcamd) — аналогично. Newcamd-устройства передают информацию о CAID и провайдере через собственный механизм, отдельно от CCcam handshake. В G: не включаются. Это один из самых частых источников ошибки: человек добавляет 5 N: линий, ставит G: 8, а пиры по факту видят только 3 CCcam-источника.

Виртуальные карты newcamd/cccam

C: линии, которые сами подключены к newcamd-серверу через мост — в G: учитываются как CCcam C: линии, если они поднятые. Но виртуальные карты, сгенерированные эмуляторами без реального физического ридера — не учитываются и добавлять их в G: не нужно. Пиры всё равно получат timeout при попытке декриптования.

В OScam аналог этой логики описывается через секции [reader] в /etc/oscam/oscam.server. Параметры cccreshare и reshare управляют тем, какие ридеры объявляются CCcam-клиентам.

Настройка G: в CCcam.cfg и эквивалент в OScam

В CCcam всё просто. В OScam — чуть сложнее, потому что прямого аналога G: нет, но поведение контролируется через несколько параметров одновременно.

Синтаксис строки G: <число> в CCcam.cfg

Строка должна стоять в начале файла, до любых F:, C:, N: секций:

G: 4
NEWCAMD LISTEN PORT = 15050
F: user1 pass1 2 0 1
C: server1.host.com 12000 login1 pass1
C: server2.host.com 12000 login2 pass2
C: server3.host.com 12000 login3 pass3

Значение — целое число от 0 до 255. Ноль означает «не декларировать» — пир увидит сервер, но без информации о картах. На практике G: 0 ставят на транзитных серверах без собственных карт, но это редкость.

Путь к конфигу: /var/etc/CCcam.cfg и /usr/keys/

На Enigma2-ресиверах (VU+, Dreambox, Zgemma) конфиг чаще всего лежит в двух местах:

• /var/etc/CCcam.cfg — основной путь для большинства дистрибутивов OpenATV, OpenPLi
• /usr/keys/CCcam.cfg — альтернативный путь, используется в некоторых сборках Gemini и старых образах

На обычном Linux-сервере (Debian, Ubuntu) стандартный путь — /etc/CCcam.cfg. Убедитесь, что редактируете правильный файл: ps -ef | grep CCcam покажет, с каким конфигом запущен демон.

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

После изменения G: нужен перезапуск — «горячего» применения нет. На Enigma2:

/etc/init.d/softcam restart

На сервере с CCcam напрямую:

killall -9 CCcam && sleep 2 && CCcam -d

Флаг -d запускает в режиме демона. Если запускаете в screen или через systemd — используйте соответствующий метод. Потеря сессий при перезапуске неизбежна: все подключённые клиенты реконнектятся автоматически через 30-60 секунд.

Эквивалент в oscam.conf и oscam.server

OScam не имеет прямой строки G:, но поведение управляется тремя параметрами:

В /etc/oscam/oscam.conf, секция [global]:

[global]
logfile = /var/log/oscam/oscam.log
maxlogsize = 100

В /etc/oscam/oscam.server, для каждого CCcam-reader:

[reader]
label = cccam_peer1
protocol = cccam
device = peer1.example.com,12000
user = login1
password = pass1
cccmaxhops = 2
cccreshare = 1
reshare = 1

Параметр cccreshare определяет, пересдаёт ли OScam карты от этого ридера CCcam-клиентам. Если cccreshare = 0 — карты от этого ридера не декларируются, аналогично тому, как C: линия с reshare 0 на удалённой стороне не попала бы в G:. OScam вычисляет декларируемое число активных устройств автоматически на основе активных reader-секций с ненулевым reshare.

Типичные проблемы из-за неверного Global Active Device

Завышенный global active device — это одна из тех настроек, где «больше» не значит «лучше». Намного лучше.

Freeze каналов каждые 10 секунд

Классический симптом завышенного G:. Пир отправляет ECM на карту, которую вы пообещали, но которой нет. ECM уходит, таймаут 10 секунд, картинка замерзает, потом снова открывается на несколько секунд — и опять freeze. Цикл повторяется.

Почему именно 10 секунд? Это стандартный ECM timeout в большинстве конфигураций CCcam. Значение можно изменить, но root cause это не лечит.

Пиры дисконнектят с ошибкой too many cards

Некоторые CCcam-серверы настроены с лимитом на максимальное количество карт от одного пира. Если вы декларируете G: 50, а у вас реально 3 карты, сервер пира может посчитать это подозрительным и оборвать соединение. В логах пира появится что-то вроде: cccam: peer disconnected, card count mismatch.

ECM-таймауты в логе

В /tmp/CCcam.log это выглядит так:

20260415 14:23:11 cccam: client 192.168.1.10 requested caid 0500 but no matching card
20260415 14:23:21 cccam: ecm timeout for caid 0x0500, provider 0x000000
20260415 14:23:21 cccam: card removed: caid 0500 on reader smargo0

Строка «no matching card» при живом ридере — прямое указание на то, что G: не соответствует реальности, или ридер упал и не переподнялся.

Неравномерная нагрузка между ридерами

Заниженный G: приводит к другой проблеме: часть ридеров не видна пирам, вся нагрузка ложится на декларированные. Один ридер перегружен, остальные простаивают. Это видно через веб-интерфейс: нагрузка на одну карту 80+ запросов в секунду, на другие — 0.

Диагностика:

tail -f /tmp/CCcam.log
cat /tmp/ecm.info

Для OScam с отладкой:

oscam -d 255 2>&1 | grep -i "ecm\|reader\|caid"

Проверка количества активных устройств в реальном времени

Не угадывать, а смотреть. Инструменты есть и в CCcam, и в OScam.

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

Открываете http://IP_СЕРВЕРА:16001/. По умолчанию логин и пароль пустые, или берутся из CCcam.cfg строки WEBINFO USER и WEBINFO PASS:

WEBINFO USER = admin
WEBINFO PASS = secretpass
WEBINFO LISTEN PORT = 16001

Вкладка «Servers» показывает все C: линии: статус соединения, количество shares, hop count. Вкладка «Shares» — полный список CAID от каждого источника. Суммируете онлайн-источники с ненулевыми shares — получаете реальное значение для G:.

OScam webif на порту 8888

OScam webif доступен на http://IP_СЕРВЕРА:8888/status.html. Раздел «Readers» показывает каждый ридер, его статус (CONNECTED/FAILED), количество активных CAID. Раздел «Users» — кто подключён и через какой ридер идут ECM.

Конфигурация webif в /etc/oscam/oscam.conf:

[webif]
httpport = 8888
httpuser = admin
httppwd = password
httprefresh = 10

Команды через telnet и ssh

Через SSH на сервер:

# Смотрим текущий node ID и статус
cat /tmp/CCcam.nodeid

# Проверяем процесс и параметры запуска
ps -ef | grep CCcam

# Смотрим последние события
tail -100 /tmp/CCcam.log | grep -E "card|reader|caid"

Для OScam через командный интерфейс (если включён):

telnet 127.0.0.1 8967

Парсинг статуса через cccam.cgi

CCcam предоставляет CGI-интерфейс на том же порту 16001. Запрос http://IP:16001/cccam.cgi?files возвращает текстовый дамп состояния. Можно парсить через curl и grep для мониторинга:

curl -s -u admin:pass http://127.0.0.1:16001/cccam.cgi?files | grep -i "active"

Это удобно для скриптов мониторинга — сравниваете декларированное G: с фактическим числом активных ридеров и получаете алерт при расхождении.

Безопасность и сетевые ограничения

Неправильно настроенный сервер — это не только freeze каналов, но и повышенное внимание со стороны пиров. И не в хорошем смысле.

Открытые порты: 12000, 13000, 16001

Стандартные порты CCcam:

• 12000 — server-to-server CCcam соединения (C: линии)
• 13000 — альтернативный, используется некоторыми конфигурациями
• 16001 — веб-интерфейс
• 15050 — newcamd (N: линии), если включён

Открывать все эти порты наружу без фильтрации — плохая идея. Особенно 16001: веб-интерфейс без пароля или со слабым паролем — прямой путь к просмотру всего вашего share-листа посторонними.

Iptables правила для CCcam порта

Минимальный набор правил для защиты CCcam-сервера:

# Разрешить CCcam только с доверенных IP
iptables -A INPUT -p tcp --dport 12000 -s TRUSTED_IP_1 -j ACCEPT
iptables -A INPUT -p tcp --dport 12000 -s TRUSTED_IP_2 -j ACCEPT
iptables -A INPUT -p tcp --dport 12000 -j DROP

# Веб-интерфейс — только с локальной сети
iptables -A INPUT -p tcp --dport 16001 -s 192.168.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j DROP

Замените TRUSTED_IP_1 и TRUSTED_IP_2 на реальные адреса ваших пиров. Если пиры динамические — используйте подсеть или смотрите в сторону VPN-туннеля между серверами.

Защита от сканеров через fail2ban

CCcam-порт активно сканируется. Fail2ban с кастомным фильтром по логам CCcam помогает:

# /etc/fail2ban/filter.d/cccam.conf
[Definition]
failregex = cccam: invalid login from 
            cccam: auth failed from 
ignoreregex =

Применяйте бан после 5 неудачных попыток за 10 минут, бан на 24 часа. Это стандартная защита, но она работает.

Влияние NAT и проброса портов на handshake

За обычным NAT CCcam работает нормально — handshake проходит, значение global active device передаётся без изменений. Проблема возникает при CGNAT (carrier-grade NAT): пир видит внешний IP провайдера, а не ваш сервер. Handshake может проходить, но соединение нестабильно из-за асимметричной маршрутизации.

При CGNAT значение G: не синхронизируется корректно с реальным числом устройств — соединение есть, но ECM-запросы теряются. Решение: VPN до пира (WireGuard или OpenVPN) или запрос выделенного IP у провайдера.

Важный момент: проброс портов в роутере (port forwarding) не влияет на значение G:. Сам параметр передаётся в прикладном уровне протокола CCcam, не в TCP-заголовках. NAT его не трогает.

OScam в режиме proxy для CCcam подставляет собственное вычисленное значение активных устройств в обмен — то есть количество активных reader-секций с ненулевым cccreshare. Это автоматическое поведение, и на практике оно работает корректно, если конфиг oscam.server настроен правильно.