Shara TV biz: настройка CCcam и OScam сервера

Если вы оказались здесь, значит, уже знаете, что такое card sharing в общих чертах, и вам нужна конкретика — строки конфигов, реальные пути к файлам, команды. Именно так работает shara tv biz на практике: не теория, а рабочая связка ресивер–сервер–источник. Ниже — всё по делу, без лишней воды.

Что такое card sharing и как работает протокол CCcam/OScam

Принцип простой. Ресивер получает зашифрованный поток со спутника, вычленяет из него ECM (Entitlement Control Message) и отправляет его на удалённый сервер, где стоит физическая карта доступа. Сервер расшифровывает ECM, достаёт Control Word (CW) и возвращает его обратно. Ресивер использует CW для декодирования потока в реальном времени.

Весь этот обмен должен укладываться в 200–600 мс — это нормальный dcw-time для комфортного просмотра. Если время выше 800–1000 мс, начинаются фризы. Выше 1500 мс — чёрный экран.

Принцип работы: ECM, CW и dcw-time

ECM обновляется каждые 10 секунд (зависит от провайдера). За это время ресивер должен получить новый CW. Если не успел — картинка замерзает. Вся диагностика card sharing крутится вокруг этого таймера.

dcw-time в логах OScam отображается в миллисекундах. Ориентир: до 400 мс — отлично, 400–700 мс — норма, выше 700 мс — начинайте копать причину. Это может быть и сам источник, и канал до него, и перегруженный роутер.

Чем OScam отличается от CCcam

CCcam — старый добрый конь. Работает, понятен, но разработка фактически заморожена на версии 2.3.x. OScam, напротив, живёт и развивается. Гибкая система приоритетов, поддержка нескольких протоколов одновременно, cache exchange (cache-ex) — всё это OScam умеет из коробки.

На сервере лучше использовать OScam. На ресивере можно оставить родной плагин CCcam или поставить oscam-emu — зависит от прошивки. Enigma2 из коробки отлично работает с OScam через встроенный softcam.

Какие протоколы поддерживаются (cccam, newcamd, mgcamd)

OScam как сервер умеет говорить на языке cccam (порт 12000 по умолчанию), newcamd (15000–16000), mgcamd и camd35. Клиент выбирает протокол — сервер подстраивается. Это удобно, когда у вас разношёрстный парк ресиверов.

Установка и базовая настройка сервера OScam на Linux

Самый распространённый вариант — VPS на Debian/Ubuntu или непосредственно Enigma2-бокс (DreamBox, VU+, GigaBlue). Пути к конфигам различаются.

Структура каталога /etc/tuxbox/config или /var/etc/tuxbox/config

На Enigma2-боксах конфиги лежат в /etc/tuxbox/config/oscam/ или /var/etc/tuxbox/config/ — зависит от дистрибутива (OpenATV, OpenPLi и т.д.). На VPS с чистым Linux стандартный путь — /etc/oscam/.

Минимальный набор файлов:

• oscam.conf — глобальные настройки и секции протоколов
• oscam.server — источники (upstream-серверы)
• oscam.user — учётные записи клиентов
• oscam.dvbapi — приоритеты декодирования для Enigma2

Файл oscam.conf: секции [global], [cccam], [newcamd]

Базовый oscam.conf выглядит так:

[global]
logfile = /var/log/oscam.log
maxlogsize = 1024
pidfile = /var/run/oscam.pid
usrfile = /var/log/oscam.usr

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

[cccam]
port = 12000
reshare = 1
version = 2.3.2

[newcamd]
port = 15000@0500:000000
key = 0102030405060708091011121314

Порт 12000 — стандарт для CCcam-протокола. Newcamd идёт на 15000, где после @ указывается CAID и провайдер. Если несколько CAID — несколько строк port.

Файл oscam.server и oscam.user

В oscam.server описываются upstream-источники:

[reader]
label = my_source
protocol = cccam
device = hostname.example.com,12000
user = myuser
password = mypassword
caid = 0500,0604
group = 1
reconnecttimeout = 30

В oscam.user — клиенты, которые подключаются к вашему серверу:

[account]
user = client1
pwd = clientpass
group = 1
au = 1
uniq = 1

Параметр au = 1 включает авторизацию каналов (EMM). uniq = 1 запрещает одновременный вход под одним логином — важно для безопасности.

Запуск через systemd и проверка логов

На современных дистрибутивах OScam запускается через systemd. Команда запуска в демон-режиме:

oscam -b -c /etc/oscam/

Если настроен юнит systemd:

systemctl start oscam
systemctl enable oscam
systemctl status oscam

Логи в реальном времени:

tail -f /var/log/oscam.log

Webif доступен по адресу http://your-server-ip:8888. Там же вкладка Status — смотрите подключённых клиентов и ECM time прямо в браузере.

Конфигурация клиента CCcam.cfg на ресивере

На стороне ресивера — файл /etc/CCcam.cfg. Если используете oscam на ресивере вместо плагина CCcam, то конфиг уйдёт в oscam.server, но синтаксис C-line всё равно нужно знать.

Синтаксис строки C: line (host port username password)

Строка подключения:

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

Разбор по полям:

• hostname.example.com — хост или IP сервера
• 12000 — порт CCcam
• myuser / mypassword — учётные данные
• no — отключить решаринг в сторону источника (рекомендуется)
• { 0:0:2 } — hop count: максимальное количество ретрансляций карты

Hop count 2 — разумный максимум. Выше — цепочка удлиняется, latency растёт, качество падает.

Параметры F: line для решаринга

Если ваш сервер сам раздаёт линии клиентам, в CCcam.cfg добавляется F-line:

F: client1 clientpass 1 0 { 0:0:1 }

Первая цифра — количество разрешённых хопов для этого клиента. Вторая — минимальный уровень карты для доступа. Здесь я предпочитаю оставлять hop 1 — клиент видит только карты с вашего сервера, не дальше.

Не плодите хопы без надобности. Каждый лишний hop — это +50–150 мс к dcw-time и риск зацикливания, если один и тот же CAID виден из нескольких источников.

Настройка приоритета и игнор-листа (oscam.dvbapi)

На Enigma2 файл oscam.dvbapi управляет тем, какой источник брать первым для конкретного CAID:

P: 0500 @ 000000 : 0 : reader=my_source
P: 0604 @ 000000 : 0 : reader=my_source2
I: 0500 @ 010203

Строка I: — игнор-лист. CAID+провайдер в этой строке декодироваться не будут. Полезно, если один из источников постоянно отвечает timeout на конкретный пакет.

Конфликт нескольких C-line с одинаковым CAID — частая проблема. OScam берёт первый подходящий ридер по порядку в oscam.server, если не задан явный приоритет через caid и group. Правильнее разнести источники по группам и управлять через oscam.dvbapi.

Открытие портов, NAT и безопасность сервера

Без открытых портов клиенты не достучатся до сервера. Это звучит банально, но именно здесь 80% проблем с первичной настройкой shara tv biz.

Проброс портов 12000/16000 на роутере

Нужно пробросить TCP-порт 12000 (CCcam) и 15000 или 16000 (newcamd) с роутера на IP вашего сервера в локальной сети. Это делается в разделе Port Forwarding или Virtual Server роутера.

Но есть подводный камень — двойной NAT. Многие провайдеры сами сидят за NAT (CGNAT, Carrier-Grade NAT). В этом случае ваш "внешний" IP в роутере — это не публичный адрес, а ещё один приватный. Проверить просто: зайдите на icanhazip.com и сравните с IP в настройках роутера. Не совпадают — CGNAT. Решение: попросить провайдера выдать белый IP (часто платно) или использовать VPN/туннель с выходом на VPS с публичным адресом.

Правила iptables для ограничения доступа

Разрешить подключение к порту CCcam:

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

Ограничить количество одновременных подключений с одного IP — защита от брутфорса:

iptables -A INPUT -p tcp --dport 12000 -m connlimit --connlimit-above 3 -j REJECT

Сохранить правила:

iptables-save > /etc/iptables/rules.v4

Защита webif паролем и смена дефолтного порта

Webif на порту 8888 с паролем по умолчанию (admin/admin) — это открытая дыра. Первое, что нужно сделать после установки: сменить пароль в секции [webif] в oscam.conf и закрыть 8888 от внешней сети:

iptables -A INPUT -p tcp --dport 8888 ! -s 192.168.1.0/24 -j DROP

Это разрешает доступ к webif только из локальной сети. Если нужен удалённый доступ — пробрасывайте через SSH-туннель, не открывайте 8888 наружу напрямую.

Можно вообще сменить порт webif на нестандартный — в oscam.conf задайте httpport = 18765. Не панацея, но отсеивает автоматические сканеры.

Диагностика проблем: фризы, чёрный экран, частые отвалы

Это самая важная часть. Большинство туториалов дают конфиги и бросают пользователя один на один с проблемами. Разберём, как читать логи и что там искать.

Анализ ECM time и причин высокого пинга

В логе /var/log/oscam.log каждый успешный ECM выглядит примерно так:

2026/03/15 21:34:52 s   0500/010203/1234 CAID found (my_source, 234 ms)

234 мс — это dcw-time. Если видите 800+ мс постоянно, копайте причину. Пинг до сервера-источника:

ping hostname.example.com

Если пинг 200+ мс — проблема в маршруте или перегруженном источнике. Если пинг нормальный, а dcw-time высокий — сервер источника перегружен внутри. Это признак oversold-ситуации.

Фризы только в прайм-тайм (20:00–23:00) — классический признак перепроданного источника. В эти часы нагрузка максимальная, и сервер не справляется. В 3 ночи всё работает идеально, а вечером — черный экран каждые 10 минут.

Разные часовые пояса сервера и клиента тоже путают при анализе логов. Если сервер на UTC, а вы в UTC+3 — timestamps в логе будут на 3 часа назад. Учитывайте это при сопоставлении событий.

Ошибки в логах: rejected, no card, timeout

Три основных статуса проблем:

• not found — источник не имеет карты для этого CAID/провайдера. Проверьте параметр caid в oscam.server и CAID канала.
• timeout — запрос ушёл, ответ не пришёл за отведённое время. Либо разрыв соединения, либо источник завис.
• rejected — сервер принял подключение, но отклонил учётные данные или IP-адрес занесён в блокировку.

Команда для быстрого подсчёта ошибок за последний час:

grep "not found\|timeout\|rejected" /var/log/oscam.log | grep "$(date '+%Y/%m/%d %H')" | wc -l

Если счётчик десятки — проблема системная, не случайная.

Проблемы с ECM hop и перегрузкой канала

Cache exchange (cache-ex) — механизм OScam, при котором несколько серверов обмениваются уже решёнными CW между собой. Если CW уже есть в кэше, он отдаётся мгновенно без обращения к источнику. Это реально снижает dcw-time при использовании нескольких OScam-нод в одной сети.

Настройка cache-ex в oscam.conf:

[cacheex]
cacheex = 1
cacheex_maxhop = 2

Перегруженный канал между вами и источником — тоже частая причина. Попробуйте QoS на роутере: выделите приоритет для TCP-порта 12000. На MikroTik это делается через Simple Queue или Mangle+Queue Tree. На бюджетных роутерах — через настройки QoS в интерфейсе.

Как выбрать качественный источник: критерии без рекламы

Shara tv biz — это в первую очередь про качество источника. Ни один конфиг не спасёт, если сам upstream-сервер работает нестабильно. Конкретных провайдеров называть не буду — рынок меняется, а реклама здесь ни к чему. Но критерии — вот что реально важно.

На что смотреть: стабильность, ECM time, аптайм

Нормальный ECM time — до 400 мс в среднем. Аптайм за месяц — выше 99%. Не верьте цифрам на сайте, проверяйте сами: пишите логи 24–48 часов и считайте timeout'ы.

Скрипт для подсчёта процента успешных ECM за период:

TOTAL=$(grep "CAID" /var/log/oscam.log | wc -l)
FOUND=$(grep "CAID found" /var/log/oscam.log | wc -l)
echo "Успешно: $(( FOUND * 100 / TOTAL ))%"

Нормальный результат — выше 97%. Если ниже 90% — источник проблемный.

Признаки перепроданного (oversold) сервера

Oversold — когда на сервер продано больше линий, чем он реально может обслужить. Признаки:

• Фризы только в прайм-тайм (вечер будни, выходные)
• dcw-time скачет от 200 мс до 1500 мс в течение часа
• Частые timeout в логах при нормальном пинге
• Клиентам периодически сбрасывают соединение без видимой причины

В webif OScam смотрите вкладку Status — там видно текущий ECM time в реальном времени. Открыли вечером в пятницу — и если таймер улетает выше 800 мс, вы знаете ответ.

Тестовый период и проверка перед оплатой

Любой нормальный источник даёт тест — обычно 24 или 48 часов. Берите тест именно в рабочие часы и вечером: утром в среду всё работает у всех.

Во время теста запустите OScam с включённым логированием и не трогайте систему. Через 48 часов — анализируйте. Смотрите не только на dcw-time, но и на количество reconnect'ов в логе: строки вида connection timeout, reconnecting... говорят о нестабильном соединении с источником.

Тест меньше 12 часов — бессмысленный. Большинство серверов нестабильны именно в пиковые часы, а не постоянно.