OScam betatunnel: настройка betatunnel в oscam.conf

Если OScam уже стоит, ридеры подключены, шара отвечает — но часть каналов просто не открывается, причина часто в одном: ресивер шлёт ECM с caid 1702 (Betacrypt), а источник умеет только 1722 (Nagravision2). Или наоборот. OScam betatunnel настройка решает именно эту задачу — конвертацию запроса между двумя протоколами в рамках одной транзакции. Ниже — конкретно и по делу, без пересказа вики.

Что такое betatunnel и зачем он нужен в OScam

Betacrypt (caid 1702) и Nagravision2 (caid 1722) — технически родственные протоколы от Kudelski. Они используют один и тот же алгоритм шифрования, но идентификаторы у них разные. Когда ресивер посылает ECM-запрос с caid 1702, а карта или сервер отдаёт CW только по caid 1722 — без конвертации получите тишину.

Betatunnel в OScam — это встроенный механизм, который перекодирует ECM-запрос перед отправкой к ридеру, и потом так же тихо возвращает ответ обратно. Для ресивера это выглядит прозрачно: он думает, что получил ответ на свой caid 1702, хотя реально запрос ходил по 1722.

Проблема несовпадения caid: 1702 vs 1722

Типичная ситуация: спутниковый канал передаёт ECM в нескольких системах одновременно — и в Betacrypt (1702), и в Nagravision2 (1722). Ресивер выбирает одну. Если он выбрал 1702, а ваша карта или шара поддерживает только 1722 — канал не откроется без туннеля.

Ещё встречаются caid 1833 и 1834 — это Nagravision3. Для них нужен отдельный target в правиле, потому что 1722 и 1833 — разные системы несмотря на схожесть имён. Не перепутайте.

Betacrypt и Nagravision — как связаны протоколы

Оба протокола разработаны Kudelski Group и в базе используют одинаковый алгоритм дескремблирования. Именно поэтому конвертация вообще возможна — CW, полученный по 1722, подходит для дескремблирования потока, зашифрованного под 1702. Если бы это были принципиально разные алгоритмы, никакой туннель не помог бы.

Когда betatunnel включается автоматически, а когда нужен вручную

OScam не включает betatunnel автоматически. Некоторые прошивки и сборки могут иметь дефолтные правила, но рассчитывать на это не стоит. Если канал не открывается и в логе видно, что ECM с caid 1702 уходит в никуда — прописывайте правило вручную в oscam.server.

Есть случай, когда ресивер сам корректно запрашивает 1722 — тогда betatunnel не нужен совсем. Более того, если прописать туннель там, где он не нужен, можно получить двойную конвертацию и битый CW. Сначала смотрите лог, потом трогаете конфиг.

Параметр betatunnel в oscam.server: синтаксис и примеры

Параметр прописывается внутри секции [reader] в файле oscam.server. Путь к файлу зависит от прошивки: на большинстве систем это /etc/tuxbox/config/oscam/oscam.server, на некоторых OpenPLi и Enigma2-сборках — /var/etc/oscam.server, на роутерах типа Asus с Entware — /opt/etc/oscam/oscam.server. Проверьте, где у вас реально лежат конфиги OScam.

Строка betatunnel = 1702.FFFF:1722 в секции [reader]

Базовый пример полной секции reader с туннелем:

[reader]
label         = mycard
protocol      = camd35
device        = 192.168.1.100:15000
user          = login
password      = pass
caid          = 1702,1722
group         = 1
betatunnel    = 1702.FFFF:1722

Строка betatunnel = 1702.FFFF:1722 говорит: «ECM-запрос с caid 1702 и любым ident-ом — конвертируй в caid 1722 перед отправкой к этому ридеру».

Формат caid_source.ident_source:caid_target

Разбор строки по частям:

• 1702 — исходный caid (то, с чем приходит ECM-запрос от ресивера)
• FFFF — ident источника; FFFF означает «любой провайдер», можно указать конкретный, например 000000 или реальный провайдный ID
• 1722 — целевой caid (то, в что конвертируем перед отправкой к ридеру)

Если нужна точная фильтрация по провайдеру — укажите его явно: 1702.003311:1722. Это полезно, когда на одном ридере несколько провайдов и туннель нужен только для одного из них.

Несколько правил туннелирования в одной строке

Несколько правил разделяются запятой без пробелов:

betatunnel = 1702.FFFF:1722,1722.FFFF:1702

Или с разными провайдерами:

betatunnel = 1702.000000:1722,1702.003311:1834

Второй пример — один провайд конвертируем в 1722, другой в 1834 (Nagravision3). Работает в рамках одного ридера.

Двунаправленное туннелирование 1722 в 1702

Обратное правило нужно реже, но бывает: ресивер шлёт 1722, а ридер/карта ожидает 1702. Тогда:

betatunnel = 1722.FFFF:1702

На практике это встречается при работе с некоторыми эмуляторами и софт-камами, которые по умолчанию работают только с Betacrypt. Направление всегда определяется по логу — смотрите, с каким caid приходит запрос и что ожидает источник.

Настройка betatunnel для dvbapi (локальный ресивер)

Когда OScam работает как локальный CA-демон для самого ресивера через dvbapi — туннель можно настроить и в oscam.dvbapi. Это другой сценарий: не «сервер для клиентов по сети», а «OScam расшифровывает поток прямо на этом же боксе».

Туннелирование на стороне oscam.dvbapi

В файле oscam.dvbapi есть параметр betatunnel, работающий аналогично:

[dvbapi]
enabled       = 1
au            = 1
pmt_mode      = 0
betatunnel    = 1702.FFFF:1722

Путь к файлу: обычно тот же каталог, что и oscam.server — /etc/tuxbox/config/oscam/oscam.dvbapi или /var/etc/oscam.dvbapi.

Когда ресивер сам не умеет Betacrypt

Некоторые старые STB физически не умеют посылать ECM-запросы с caid 1702 — они работают только с 1722. В этом случае betatunnel в dvbapi не поможет (ресивер вообще не пошлёт 1702-запрос). Туннель нужен именно когда ресивер шлёт 1702, а источник умеет только 1722.

Если ресивер шлёт 1722 и источник отдаёт 1722 — всё работает без туннеля. Не добавляйте лишние правила.

Взаимодействие с приоритетами P: и I: в oscam.dvbapi

Строки P: (priority) и I: (ignore) в oscam.dvbapi влияют на то, какие caid вообще обрабатываются. Если написать I: 1702:0 — запросы по caid 1702 будут игнорироваться, и betatunnel никогда не сработает. Проверьте, что в секции нет игнора нужных caid.

Приоритет через P: работает раньше туннелирования — сначала выбирается, какой caid обрабатывать, потом применяется туннель. Логика последовательная, не параллельная.

Отладка: как проверить, что betatunnel работает

Голая конфигурация ничего не докажет. Нужен лог. Включить детальное логирование можно в oscam.conf в секции [global]:

[global]
logfile          = /var/log/oscam.log
loghistorysize   = 4096
loglevel         = 4

Или через веб-интерфейс: откройте http://<ip>:8888 (порт задаётся в oscam.conf параметром httpport), вкладка Logging — там можно менять уровень прямо в рантайме без перезапуска.

Чтение oscam.log: строки CW и caid в логе

При успешном туннелировании в логе будет видно две стадии одной транзакции. Сначала входящий запрос:

ECM caid: 1702 provid: 000000 srvid: 0123 reader: mycard

Затем строка с отправкой к ридеру покажет уже caid 1722 — именно это и означает, что туннель сработал. И финально строка с CW:

CW caid: 1702 provid: 000000 srvid: 0123 ecmtime: 187ms

ECM-time 187ms — нормально. Больше 500ms — пора разбираться с пингом до источника.

Уровни логирования debug 4 и debug 255

loglevel = 4 — достаточно для наблюдения за конвертацией caid. loglevel = 255 — максимальная детализация, включает все внутренние операции OScam. Полезен для глубокой отладки, но лог-файл растёт очень быстро. На продакшне держите 4, на диагностику переключайте в 255 через веб-интерфейс.

Проверка через веб-интерфейс OScam (статус ридеров)

В веб-интерфейсе на вкладке Readers видно статус каждого ридера: последний ECM-time, количество успешных/неуспешных ответов, caid которые ридер обработал. Если в колонке caid появился 1722 при том, что ресивер слал 1702 — туннель работает.

Маркеры успешной конвертации в логе

Признак нормальной работы туннеля — в одной транзакции caid запроса (1702) и caid в строке ответа CW (1702) совпадают, но внутри была конвертация. Признак проблемы — строка no matching reader или caid not supported вместо CW. Это значит, что туннель либо не настроен, либо настроен в другом ридере.

Типичные ошибки настройки betatunnel и что НЕ работает

Betatunnel не создаёт права там, где их нет. Это самая частая ошибка: человек прописывает туннель, но источник физически не содержит нужный провайдер под caid 1722. Туннель конвертирует запрос, карта его получает — и возвращает ошибку, потому что у неё нет прав на этот канал. Никакая настройка это не исправит.

Неверный порядок caid в правиле

Частая ошибка — написать betatunnel = 1722.FFFF:1702 вместо 1702.FFFF:1722, когда ресивер шлёт 1702. Правило тогда никогда не срабатывает — входящий 1702-запрос не совпадает с source 1722 в правиле. Лог покажет, что запросы уходят с caid 1702 без конвертации.

Туннель прописан не в том ридере

При нескольких ридерах OScam может отправить ECM к ридеру, в котором betatunnel не прописан. Приоритет ридеров настраивается через group и services. Если туннель стоит в reader B, но запрос routing-ом уходит в reader A — конвертации не будет. Смотрите лог: там видно, к какому именно ридеру пошёл ECM.

Конфликт с group и caid в секции [reader]

Параметр caid в секции reader определяет, какие caid этот ридер вообще обрабатывает. Если написать caid = 1722, но не включить 1702 — OScam не направит к этому ридеру запросы с caid 1702, и betatunnel не получит входящего запроса для конвертации. Добавьте оба caid: caid = 1702,1722.

Почему betatunnel не помогает при отсутствии прав на карте

Туннель — это только транспортная конвертация. Он не меняет права доступа. Если карта авторизована на пакет X под caid 1722 провайдер 003311, а вы пытаетесь расшифровать канал из пакета Y — туннель тут вообще ни при чём. Проблема в подписке источника. Это легко отличить в логе: туннель сработал (caid конвертирован), но CW вернулся пустой или с ошибкой decode failed.

Как выбрать источник (провайдер шары) под Betacrypt-каналы

Перед тем как заниматься OScam betatunnel настройка — стоит убедиться, что источник вообще поддерживает нужные caid и провайдеры. Никакой туннель не вытащит CW из источника, у которого их нет.

Критерии: стабильность caid 1722, низкий ping, аптайм

Смотрите на ECM-time в логе OScam — это реальный показатель скорости ответа источника. Нормально: до 300ms. Уже плохо: 500-800ms, будут периодические фризы. Выше секунды — канал будет постоянно подтормаживать при зэппинге.

Пинг до сервера в миллисекундах — не то же самое, что ECM-time. ECM-time включает обработку на стороне сервера. Источник с пингом 20ms может иметь ECM-time 400ms из-за нагрузки.

Проверка поддерживаемых provid без доверия к рекламе

После подключения источника смотрите на вкладку Readers в веб-интерфейсе OScam — там отображаются реально поддерживаемые caid и provid, которые сообщил сам источник при handshake. Это объективно. Если в списке нет нужного provid — туннель не поможет, ищите другой источник.

Ещё способ: включите loglevel = 4 и попробуйте включить конкретный канал. Если в логе видите caid: 1722 provid: XXXXXX и в ответе приходит нормальный CW — источник поддерживает этот провайдер. Если decode failed — нет.

Признаки технически грамотного источника

Хороший источник: ECM-time стабильный (отклонение ±50ms), в веб-интерфейсе виден полный список provid, нет строк connection loss в логе часами. Плохой источник: ECM-time скачет от 100ms до 2000ms, периодически пропадает соединение, на некоторые ECM-запросы не приходит ответ вообще.

OScam betatunnel настройка имеет смысл только при стабильном источнике. Если источник ненадёжный — никакие правила конвертации ситуацию не спасут.