ТВ шара: настройка CCcam и OScam сервера в 2026

Тв шара — разговорное название кардшаринга, которым пользуются все, кто хоть раз пытался открыть закодированные каналы на своём ресивере. Технически это раздача control words (CW) — ключей расшифровки — по сети от сервера к клиенту. Ресивер отправляет ECM-запрос на сервер, сервер вычитывает ответ с физической карты и возвращает control word, ресивер расшифровывает поток. Всё это должно уложиться в ~10 секунд — именно столько живёт один CW до смены.

Ниже — конкретная инструкция по настройке и отладке, без лишней воды.

Что такое тв шара и как работает кардшаринг

Принцип работы: обмен ключами (control words) по сети

Когда ресивер встречает закодированный поток, он извлекает из него ECM-пакет — зашифрованный запрос к условному доступу. В обычной схеме смарт-карта, вставленная локально, расшифровывает этот пакет и выдаёт control word. В шаринге карта физически находится на удалённом сервере, а ECM по протоколу передаётся туда и обратно через интернет.

Ключ меняется примерно каждые 10 секунд. Если за это время сервер не успел ответить — пошли фризы. Отсюда жёсткое требование к пингу: при RTT больше 300–400 мс стабильного просмотра не будет. Оптимум — до 80–100 мс.

Роли сервера и клиента в шаринге

Сервер — это машина с физической смарт-картой (или эмулятором), на которой запущен CCcam, OScam или аналог. Клиент — ресивер, который подключается к серверу и запрашивает CW. Один сервер может обслуживать десятки клиентов параллельно, но каждый одновременный запрос одного и того же CAID требует отдельного тюнера/карты.

CAID, ECM и SID — базовая терминология

CAID (Conditional Access Identifier) — числовой идентификатор системы шифрования. Например, Viaccess — 0x0500, Nagravision — 0x1800, Irdeto — 0x0600. ECM — Entitlement Control Message, зашифрованный пакет в потоке, содержащий CW. SID (Service ID) — идентификатор конкретного канала внутри транспондера. Без совпадения CAID между запросом клиента и картой на сервере ничего не заработает.

Тут же важный нюанс: CAID может совпадать, а provider ID — нет. Viaccess, например, разбит по провайдерам (ident), и если в конфиге ресивера прописан не тот ident — канал молчит, хотя CAID формально правильный.

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

CCcam — закрытый протокол/демон, заточенный под Enigma2. Простой в базовой настройке, но менее гибкий. OScam — открытый, поддерживает кучу протоколов (newcamd, cccam, camd35, радегаст и ещё с десяток), умеет приоритизировать ридеры, имеет удобный веб-интерфейс. MGcamd — по сути клиент под newcamd, часто используется там, где нужна простота без сервера.

Для полноценного сервера с несколькими ридерами и клиентами OScam предпочтительнее — он даёт детальное логирование и гибкий failover. CCcam проще поднять за 15 минут, если нужен базовый клиент на одну строку подключения.

Настройка OScam сервера: конфиг-файлы и порты

Структура каталога /etc/tuxbox/config/oscam/ или /usr/keys/

На Enigma2-боксах (Dreambox, VU+, Zgemma и т.д.) конфиги OScam живут в /etc/tuxbox/config/oscam/. На чистом Linux без тюнер-прошивки — обычно /usr/keys/ или /etc/oscam/. Минимальный набор файлов: oscam.conf, oscam.server, oscam.user. Дополнительно могут быть oscam.dvbapi (для привязки к тюнеру), oscam.srvid (имена каналов) и oscam.providers.

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

Минимальный рабочий oscam.conf:

[global]
logfile = /tmp/oscam.log
maxlogsize = 500
nice = -1
WaitForCards = 1

[webif]
httpport = 8888
httpuser = admin
httppwd = yourpassword
httprefresh = 30
httpallowed = 127.0.0.1,192.168.0.0-192.168.255.255

[newcamd]
port = 15000@0500:000000

[cccam]
port = 12000

Веб-интерфейс на порту 8888 — удобнейший инструмент для мониторинга ридеров и клиентов в реальном времени. Без него диагностировать проблемы раза в два сложнее. Секция [newcamd] содержит порт и CAID через @, секция [cccam] — порт для CCcam-протокола.

Файл oscam.server: описание ридеров и протоколов

Каждый ридер — отдельная секция [reader]. Пример ридера, подключающегося к апстрим-серверу по cccam:

[reader]
label = upstream_cccam
protocol = cccam
device = sharehost.example.com,12000
user = mylogin
password = mypass
caid = 0500
group = 1
reconnecttimeout = 15

Для физической смарт-карты через USB-ридер (например, Smargo) протокол будет smartreader или mouse, device — /dev/ttyUSB0. Если на одном CAID несколько ридеров — OScam выбирает по приоритету (параметр caid с весами) или по времени отклика. Это одно из главных преимуществ OScam перед CCcam.

Файл oscam.user: учётные записи клиентов и AU

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

Параметр au = 1 разрешает автообновление (Auto Update) — передачу EMM-пакетов клиенту для обновления подписки на карте. Параметр uniq ограничивает число одновременных сессий от одного аккаунта. На production-сервере обычно ставят uniq = 1 или 2.

Открытие портов (например, 12000 newcamd, 12345 cccam) и проброс на роутере

Если ресивер за NAT — без проброса портов клиенты извне не доберутся. Для OScam нужно пробросить TCP-порт, указанный в oscam.conf: для newcamd это обычно 15000, для cccam — 12000 или 12345. На роутере создаётся правило: внешний порт X → внутренний IP ресивера (статический!) : порт X.

Серый IP (CGNAT) у провайдера — отдельная боль. Если выданный IP начинается с 10.x.x.x, 100.64.x.x или 172.16–31.x.x — это CGNAT, пробросить порт не получится стандартным способом. Выход: VPN с белым IP (WireGuard на VPS поднимается за 20 минут), reverse tunnel через SSH или запрос у провайдера белого IP (часто бесплатно).

Настройка CCcam: файлы CCcam.cfg и строки C-line/F-line

Расположение CCcam.cfg в /var/etc/ или /usr/keys/

На большинстве Enigma2-прошивок файл живёт по адресу /var/etc/CCcam.cfg. На некоторых сборках — /usr/keys/CCcam.cfg. Проверить просто: find / -name CCcam.cfg 2>/dev/null. Демон при запуске читает файл один раз, поэтому после правок нужен перезапуск.

Формат C-line для клиента: C: host port user pass

C-line — строка подключения к серверу. Синтаксис:

C: server.example.com 12000 myusername mypassword

Разбор по полям: C: — тип строки (client). Дальше через пробел: хост (DNS или IP), порт TCP, логин, пароль. Никаких кавычек, никаких лишних символов. Регистр логина/пароля имеет значение — именно здесь половина проблем с "не подключается".

Можно указывать несколько C-line — CCcam будет пробовать их по порядку. Но держать более 2–3 строк смысла нет: если основной сервер лежит, скорость фолловера часто тоже никакая.

Формат F-line для сервера: F: user pass uphops downhops

F-line описывает клиента, которому разрешено подключаться к вашему CCcam серверу:

F: clientuser clientpass 1 0

Первое число — uphops (сколько hop клиент может распространять карты вверх по цепочке), второе — downhops (сколько hop вниз). Значение 1 0 — стандартное: клиент видит карты, но не может их реселлить дальше.

Параметры hops, SERVER LISTEN PORT и DEBUG

В CCcam.cfg на стороне сервера обязательно прописать:

SERVER LISTEN PORT : 12000
DEBUG : 0
CCCAM VERSION : 2.3.0

Параметр hop — количество пересылок от физической карты до конечного клиента. Hop 1 — карта на сервере, к которому вы подключены напрямую. Hop 2 — карта на сервере, у которого уже есть C-line на другой сервер. Чем больше hop, тем выше латентность и ниже стабильность. Hop больше 2 на практике почти всегда даёт фризы — ECM-time растёт.

Перезапуск демона и проверка лога

На Enigma2 перезапуск:

/etc/init.d/CCcam restart

или через плагин менеджер. Лог смотреть в /tmp/CCcam.log — там видны подключения клиентов и статус карт. Веб-интерфейс CCcam доступен на порту 16001 (по умолчанию), или через специальный плагин CCcam.info. Быстрый телнет: telnet localhost 16000 — выдаёт текстовый статус.

Решение типовых ошибок шаринга

Канал не открывается: проверка CAID и ECM-времени

Первый шаг диагностики — убедиться, что CAID канала совпадает с тем, что обрабатывает ридер. В OScam это видно в веб-интерфейсе (порт 8888): вкладка "Live Log" покажет, куда уходит ECM-запрос. В oscam.log ищи строки вида:

ECM caid 0500 sid 1234 prov 000000 ... answered by reader upstream_cccam (120ms)

Если ответа нет или пишет not found — либо CAID не совпадает, либо нужный provider ID не прописан в ридере. Добавь параметр ident = 0500:000000,000010 в секцию ридера в oscam.server.

Высокий ECM-time и фризы изображения

ECM-time выше 800–1000 мс — гарантированные фризы, потому что CW меняется каждые 10 секунд, и если запрос занимает секунду, буфер вычерпывается. Причины: плохой пинг до сервера, перегруженный апстрим или большой hop.

Проверить пинг банально: ping -c 20 server.example.com — смотри не только среднее, но и джиттер. Если разброс пинга больше 50 мс — стабильного шаринга не будет. Это не решается настройкой конфига — только сменой сервера или маршрута.

Ещё вариант фризов — CW приходит вовремя, но ресивер не успевает его применить из-за нагрузки на CPU. На старых боксах типа Dreambox 500S это актуально: несколько одновременных записей + шаринг = перегруз.

Статус сервера offline / no card

"No card" в логе CCcam и "offline" в OScam webif означают одно: сервер не отдаёт CW. Алгоритм проверки:

1. Проверить, доступен ли порт: telnet sharehost.example.com 12000 — должно соединиться
2. Проверить логин/пароль в C-line — опечатка в одном символе = нет подключения
3. Убедиться, что порт открыт на файрволле сервера: iptables -L -n | grep 12000
4. Проверить апстрим — возможно, сервер сам потерял карту

Если telnet не соединяется — проблема сетевая или файрволл. Если соединяется, но канал не открывается — проблема аутентификации или CAID.

Ошибки AU и обновления ключей

AU (Auto Update) ломается по нескольким причинам. Первая и неочевидная — неверное время на ресивере. EMM-пакеты содержат временные метки, и если часы ресивера расходятся с реальным временем больше чем на несколько минут — AU отклоняется. Настрой NTP: ntpdate -u pool.ntp.org и добавь в cron. Часовой пояс тоже имеет значение.

Вторая причина — параметр au = 0 в oscam.user или AU не включён на ридере (audisabled = 1 в oscam.server). Проверь оба файла.

Конфликты портов и блокировка провайдером

Если на одном ресивере запущены одновременно CCcam и OScam, и оба слушают, например, порт 12000 — один из них упадёт или не запустится. Проверь: netstat -tlnp | grep 12000. Реши конфликт, поменяв порт в одном из конфигов.

Некоторые провайдеры блокируют "нестандартные" TCP-порты. Если порт 12000 или 15000 заблокирован — попробуй 80, 443 или 8080. В OScam порт меняется в oscam.conf, в CCcam — параметр SERVER LISTEN PORT. Но учти: на порту 443 может уже висеть HTTPS, если на том же хосте есть веб-сервер.

Как выбрать провайдера шаринга: критерии без рекламы

На что смотреть: аптайм, пинг, локальные карты vs решары

Главный критерий — стабильность ECM-time, а не количество каналов. Сервер с 500 каналами и ECM 800 мс хуже, чем сервер с 50 каналами и ECM 80 мс. Перед подпиской попроси тестовый доступ на 24–48 часов и замерь реальное ECM-время в логе OScam или через CCcam.info.

Локальные карты (hop 1) всегда стабильнее решаров (hop 2+). Если провайдер держит физические карты у себя — это хорошо. Если он сам перепродаёт чей-то шаринг — цепочка длиннее, и каждый дополнительный узел добавляет латентность и точку отказа.

Поддерживаемые протоколы и количество hop

Хороший сервер предлагает минимум два протокола: CCcam и newcamd/cccam через OScam. Это важно — разные ресиверы и прошивки лучше работают с разными протоколами. Если доступен только один вариант — меньше гибкости при переезде или смене оборудования.

Количество hop должно быть явно указано. Hop 1 = локальная карта. Если в описании написано просто "много каналов" без упоминания hop — скорее всего, это решар с hop 2–3.

Тестовый период и стабильность ECM-time

Без теста не берём. Нормальная практика — 24–72 часа тестового доступа. За это время смотри: ECM-time (должен быть стабильно под 200 мс), число дисконнектов (ноль или близко к нулю), поведение в прайм-тайм (19:00–23:00 — пиковая нагрузка).

Скачущий ECM-time — например, 50 мс в 3 ночи и 900 мс в 20:00 — признак перегруженного сервера. С таким стабильного просмотра не будет.

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

Красные флаги: нет тестового периода вообще, поддержка отвечает через 2+ суток, сервер не работает больше нескольких часов подряд, в описании нет информации о протоколах и hop. Ещё один признак — отсутствие статистики аптайма. Нормальный сервер показывает uptime 99%+.

Отдельно: если C-line или тестовые данные приходят через публичный чат или Telegram без верификации — это не сервис, это помойка. Данные уходят к десяткам людей одновременно, нагрузка непредсказуема.