Что такое Betatunnel в CCcam и OScam: настройка

Если вы настраиваете OScam и наткнулись на строку betatunnel в примерах конфигов — или видите в логах, как ECM с caid 1702 куда-то уходит и не возвращается — эта статья для вас. Что такое betatunnel, зачем он вообще существует и почему без него часть каналов просто не откроется, разберём по порядку: от теории до рабочего конфига.

Что такое betatunnel простыми словами

Определение и зачем он нужен

Что такое betatunnel — это механизм преобразования (туннелирования) ECM-запросов с одного caid на другой. Конкретно: когда приходит ECM с caid 1702 (Betacrypt), а у вас есть карта или ридер, работающий на caid 1722 (Nagravision), сервер в стандартном режиме просто не знает, кому отдать этот запрос. Tuннель решает это: он на лету переписывает заголовок ECM, превращая 1702-запрос в формат, понятный Nagravision-ридеру.

Без туннеля ситуация такая: OScam видит ECM, ищет ридер с поддержкой caid 1702, не находит — и запрос уходит в мусор. Канал не декодируется. Карта Nagra при этом вполне живая и могла бы ответить, просто никто её не спросил.

Betacrypt и Nagravision: связь caid 1702 и 1722

Betacrypt — это фактически надстройка над Nagravision. Исторически Betacrypt (caid 1702) использовали немецкие операторы, и криптографически он построен на том же движке, что и Nagravision (1722). Это означает, что одна и та же смарт-карта может физически обрабатывать оба формата — нужно только правильно сформировать запрос.

Родственный caid 1801 — тоже Nagravision, третья версия. Иногда встречается схема туннелирования 1702 → 1801, особенно для новых транспондеров. Логика та же самая, просто целевой caid другой.

Когда betatunnel реально требуется

Туннель нужен в трёх случаях. Первый: у вас карта Nagravision (1722), а транслируемые каналы используют Betacrypt (1702) — провайдер не перешёл на единый caid для всего мультиплекса. Второй: вы используете эмулятор или softcam, который работает только с 1722, но принимаете ECM с 1702. Третий: ваш источник в CCcam/OScam-сети отдаёт ключи только по 1722, а запросы к вам приходят на 1702.

Если каналы открываются и без туннеля — не трогайте ничего. betatunnel решает конкретную проблему несовместимости caid, не более.

Как работает betatunnel на уровне протокола

Структура ECM и подмена caid

ECM (Entitlement Control Message) — это зашифрованный пакет, содержащий Control Word (CW), которым декодируется видеопоток. В заголовке каждого ECM прописан caid — идентификатор системы условного доступа. Когда OScam получает ECM с caid 1702, он ищет ридер, у которого этот caid заявлен. Если ридер настроен только на 1722 — матча нет.

Betatunnel вмешивается до этого поиска. OScam переписывает caid в заголовке ECM с 1702 на 1722, после чего ридер Nagravision видит «свой» запрос и обрабатывает его нормально. CW возвращается, OScam прозрачно передаёт его клиенту — тот даже не знает, что запрос был преобразован.

Провайдер ident и таблица 1702:1722

Строка туннеля имеет формат caidSrc:provid:caidDst. Поле provid — это идентификатор провайдера (provider ID), шестизначное шестнадцатеричное число. Нули (000000) означают «любой провайдер» — туннель срабатывает на все ECM с caidSrc независимо от провайдера.

Когда нужна точность — например, карта реагирует на 1722 только для конкретного провайдера — указывают точный provid: betatunnel = 1702:003311:1722. Несколько правил перечисляются через запятую в одной строке. Порядок имеет значение: первое совпавшее правило и срабатывает.

Отличие туннелирования от обычного шаринга

При обычном шаринге ECM идёт к ридеру, который его понимает нативно. При туннелировании OScam сам модифицирует запрос перед отправкой. Это происходит локально, внутри процесса OScam — никакого дополнительного сетевого хопа нет. Ответ (CW) возвращается обратно тем же путём и «разворачивается» в исходный контекст caid 1702 для клиента.

Задержка при туннелировании минимальная — миллисекунды на переписывание заголовка. Но если карта медленная (>300 мс ECM time), плюс ещё туннель — на быстро меняющихся ECM (каждые 10 секунд на некоторых пакетах) возможны кратковременные фризы именно в момент смены Control Word.

Настройка betatunnel в OScam

Параметр betatunnel в oscam.conf и oscam.user

В OScam параметр betatunnel можно прописать в двух местах: в глобальном конфиге (/etc/oscam/oscam.conf, секция [global]) или в файле пользователей (/etc/oscam/oscam.user, секция конкретного [account]).

Разница принципиальная. Глобальный уровень применяется ко всем запросам через этот OScam-инстанс. Уровень account применяется только к запросам от конкретного пользователя/клиента. Если у вас несколько клиентов с разными нуждами — настраивайте на уровне account. Если туннель нужен для всего трафика через сервер — пишите в global.

Есть ещё третий вариант: параметр в секции [reader] файла /etc/oscam/oscam.server. Там он применяется только к запросам, которые идут на этот конкретный ридер. Это самый точечный контроль.

Синтаксис betatunnel = 1702:0000:1722

Базовая строка выглядит так:

betatunnel = 1702:000000:1722

Три поля через двоеточие: исходный caid, provid (шесть нулей = любой), целевой caid. Несколько правил через запятую:

betatunnel = 1702:000000:1722,1702:000000:1801

Важный нюанс: в старых сборках OScam (до примерно r11000) встречается сокращённый формат с четырьмя нулями вместо шести в provid — 1702:0000:1722. В актуальных версиях правильно использовать шесть символов. Если после прописки туннель не работает — проверьте, сколько нулей принимает ваша сборка: смотрите oscam --build-info и дату компиляции.

Пример рабочего reader-блока

Типовой ридер в /etc/oscam/oscam.server для карты Nagravision с включённым туннелем под Betacrypt:

[reader]
label         = nagra_card
protocol      = mouse
device        = /dev/ttyUSB0
caid          = 1702,1722
ident         = 1702:000000;1722:000000
betatunnel    = 1702:000000:1722
group         = 1
emmcache      = 1,3,2

Обратите внимание: в строке caid перечислены оба caid — 1702 и 1722. Без 1702 в списке caid ридер не будет принимать ECM с этим caid даже при наличии туннеля. Это частая ошибка: туннель прописан, а caid в ридере не добавлен.

Если беtatunnel задан и в [global], и в [reader] — приоритет у reader-уровня. Дублирующие правила просто применяются повторно, что не ломает работу, но засоряет логи. Лучше держать правила в одном месте.

Настройка betatunnel в CCcam

Где CCcam обрабатывает Betacrypt автоматически

Чистый CCcam не имеет отдельной директивы betatunnel. Если к CCcam подключена физическая карта Nagravision через локальный ридер и карта физически поддерживает Betacrypt — CCcam может декодировать 1702-каналы без дополнительных настроек. Карта сама разбирается с ECM.

Но это работает не всегда. Если CCcam использует сетевой источник (другой сервер) или эмулятор, который не умеет Betacrypt нативно — нужна прослойка.

Когда нужен внешний эмулятор (OScam как proxy)

Типовая рабочая схема: локальный OScam с настроенным betatunnel выступает как ридер для CCcam. OScam принимает ECM от CCcam, делает туннелирование, отправляет на карту или в сеть, возвращает CW обратно в CCcam. CCcam раздаёт CW клиентам.

Связь между ними — по протоколу cs378x (cccam-протокол) или newcamd. OScam при этом слушает на локальном порту, CCcam подключается к нему как к обычному серверу.

Проверка через CCcam.cfg и логи

В /etc/CCcam.cfg добавляется строка подключения к локальному OScam. Для cs378x-протокола:

C: 127.0.0.1 12000 username password

Для newcamd:

N: 127.0.0.1 15050 username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Порты (12000 для cs378x, 15050 для newcamd) — те, что прописаны в /etc/oscam/oscam.conf в секциях [cs378x] и [newcamd] соответственно. Убедитесь, что OScam слушает на этих портах: netstat -tlnp | grep oscam.

В логах CCcam (/tmp/cccam.log или путь из конфига) при успешном подключении появится строка с подключённым ридером и списком caid, которые он поддерживает. Если 1702 там есть — туннель работает и CCcam знает об этом.

Диагностика и типичные ошибки betatunnel

В логах caid 1702 'not found' при живой карте Nagra

Самый частый симптом: в логах OScam (уровень 4, loghistory) видно ECM caid=1702 ... not found, при том что карта 1722 вставлена и работает на других каналах. Причина почти всегда одна из двух: либо betatunnel не прописан совсем, либо прописан на уровне global, но ридер не имеет 1702 в списке caid.

Включить уровень 4 в OScam: в /etc/oscam/oscam.conf в секции [global] установить loglevel = 4. После перезапуска OScam в логах будет видна вся цепочка: пришёл ECM, какой caid, куда пошёл, ответил ли ридер. Строка с betatunnel в логе подтверждает, что преобразование произошло.

Неверный provid в строке betatunnel

Если карта отдаёт CW для одного провайдера, но молчит для другого — дело в provid. Когда в строке betatunnel стоит конкретный провайдер (1702:003311:1722), а ECM приходит с другим provid — туннель не срабатывает, запрос падает.

Решение: временно заменить на нулевой provid (1702:000000:1722), проверить работу, затем уточнить provid из логов. В строках лога OScam при level 4 вы увидите что-то вроде ECM caid=1702 provid=003311 — берёте это значение и вписываете точно.

Каналы фризят только на части пакета

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

Ещё вариант: ECM приходит не на 1722, а на 1801. Это отдельная ветка Nagravision 3. Туннель 1702:000000:1722 тут не поможет — нужна отдельная строка: betatunnel = 1702:000000:1801. Проверьте в логах, какой именно целевой caid использует ваша карта.

Как выбрать источник для Betacrypt-каналов

Критерии надёжного источника без привязки к брендам

Для Betacrypt-каналов источник должен явно заявлять поддержку caid 1702 и/или 1722. Это не одно и то же: источник может отдавать только 1722 и ожидать, что туннелирование сделаете вы. Или отдавать 1702 напрямую. Уточняйте перед подключением.

Предпочтительный вариант — источник с локальной картой, а не с shared-картой из другой сети. Цепочки share увеличивают задержку ECM, и при туннелировании это складывается. Для Betacrypt-каналов со сменой ECM каждые 10–30 секунд задержка выше 800–900 мс стабильно даёт фризы.

Стабильность ответа ECM и аптайм

Смотрите на два числа: среднее время ответа ECM (ECM time) и аптайм подключения. ECM time для локальной карты — обычно 50–200 мс. Для сетевого источника с хорошим пингом — до 400–500 мс. Всё, что выше 700 мс, начинает проявляться визуально на экране при быстрой смене ECM.

Аптайм важен не сам по себе, а как индикатор стабильности. Частые реконнекты (несколько раз в сутки) — сигнал проблем с источником, и tunneling тут ничем не поможет: если соединение рвётся в момент смены ECM, канал зависнет на несколько секунд независимо от настроек.

Поддержка нужного caid и локальной карты

Проверяйте, что источник честно указывает caid в своих данных. В OScam это видно через веб-интерфейс на вкладке Readers — там отображаются все caid и провайдеры, которые отдаёт каждый ридер. Если 1702 или 1722 в списке нет — источник для Betacrypt-каналов не подходит, никакой betatunnel не поможет.

Оценивайте источник самостоятельно по этим метрикам. Тестовый период в несколько дней — нормальная практика. Смотрите на реальное поведение в логах, а не на маркетинговые описания.