Миграция с CCcam на OScam: полное руководство 2026

Если вы занимаетесь кардшарингом дольше пары лет, рано или поздно упираетесь в потолок CCcam. Процесс cccam to oscam — это не просто смена программы, это переход на другую архитектурную философию. И да, первый раз это пугает: два десятка файлов конфигурации вместо одного CCcam.cfg, незнакомые термины reader/user/group. Но через час-два после первого успешного запуска понимаешь, почему OScam стал стандартом для серьёзных установок.

В этом гайде — конкретика. Реальные блоки конфигурации, пути к файлам, команды отладки. Без воды.

Почему стоит переходить с CCcam на OScam

CCcam — монолит. Один процесс делает всё: принимает клиентов, подключается к upstream, декодирует ECM. Это удобно для простых случаев, но масштабирование — боль. OScam разделяет эти роли явно: reader отвечает за исходящие подключения к источникам карт, user/account — за входящих клиентов, протоколы подключаются независимо как модули.

Ограничения CCcam: закрытый код, отсутствие обновлений

CCcam застрял на версии 2.3.x уже много лет. Закрытый бинарник, никаких коммитов, никакой возможности пофиксить баг самому. Если ваш STB или дистрибутив не поддерживает старые библиотеки — проблема ваша, не авторов. Современные CAS, появившиеся после 2015 года, CCcam просто не умеет обрабатывать.

Отладка в CCcam — это чтение лога и угадывание. Нет ни внятного веб-интерфейса, ни детального ECM-трейса на уровне конкретного reader'а.

Преимущества OScam: открытый исходник, активная разработка, поддержка современных CAS

OScam получает коммиты регулярно. Исходный код открыт, поэтому сборки под Enigma2, OpenWrt, ARM и x86 собирает огромное сообщество. Поддерживаются Viaccess 3.0, Nagra 3, BISS, Conax, Cryptoworks — всё что CCcam не знает.

Веб-интерфейс на порту 8888 показывает в реальном времени: статус каждого reader'а, активных клиентов, ECM time, историю декодирования. Это не luxury — это то, без чего серьёзная отладка невозможна.

Совместимость: OScam умеет говорить по протоколу CCcam в обе стороны

И это главная причина, почему миграция cccam to oscam не требует менять ничего у клиентов. OScam поддерживает протоколы CCcam, newcamd, camd35, gbox, radegast одновременно — в рамках одного запущенного процесса. Клиент на старой прошивке STB, который умеет только CCcam, подключится к OScam и не заметит разницы.

Когда миграция не нужна

Честно: если у вас одна C: строка и два клиента — CCcam справляется. Переходить ради перехода не стоит. OScam оправдывает сложность при 5+ reader'ах, нескольких протоколах одновременно, или когда нужна тонкая фильтрация по CAID/провайдеру.

Структура конфигов: CCcam.cfg против OScam

В CCcam всё в одном файле: C: строки для upstream, F: строки для клиентов, N: для newcamd. В OScam конфигурация разбита на несколько файлов, и каждый отвечает за свою область.

Файлы CCcam: один CCcam.cfg для всего

Типичный CCcam.cfg выглядит так:

C: upstream.example.com 12000 myuser mypassword
F: client1 clientpass 1 0 0
F: client2 clientpass2 1 0 0
N: newcamd.example.com 15000 myuser mypass 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Просто и понятно. Но отладить что именно не так с конкретным reader'ом — удачи.

Файлы OScam: oscam.conf, oscam.server, oscam.user, oscam.dvbapi, oscam.services

OScam читает директорию конфигурации, обычно это:

  • Enigma2 STB: /etc/tuxbox/config/oscam/
  • Linux-сервер (debian/ubuntu): /usr/local/etc/oscam/ или /etc/oscam/
  • OpenWrt/Entware: /opt/etc/oscam/
  • Некоторые STB-дистрибутивы: /var/etc/ или /usr/keys/

Внутри этой директории:

  • oscam.conf — глобальные параметры, секции [global], [cccam], [webif], [monitor]
  • oscam.server — reader'ы (исходящие подключения к upstream)
  • oscam.user — аккаунты клиентов (входящие подключения)
  • oscam.dvbapi — настройки для локального декодирования через DVB API
  • oscam.services — фильтры по сервисам/каналам (опционально)

Соответствие секций: C: строка → [reader], F: строка → [account]

Это ключевое понимание для миграции cccam to oscam. Каждая C: строка становится секцией [reader] в oscam.server. Каждая F: строка становится секцией [account] в oscam.user. Один-к-одному, без магии.

Расположение по платформам

Запуская OScam, всегда явно указывайте директорию: oscam -c /etc/oscam/. Без флага -c OScam ищет конфиги в директории по умолчанию, которая зависит от того как он скомпилирован — может найти не то.

Конвертация C: строк в [reader] секции

Берём конкретный пример. Есть C: строка:

C: upstream.provider.com 12000 mylogin mypassword

В oscam.server это становится:

[reader]
label                = upstream_main
protocol             = cccam
device               = upstream.provider.com,12000
user                 = mylogin
password             = mypassword
group                = 1
cccversion           = 2.3.2
cccmaxhops           = 5
cccwantemu           = 0
inactivitytimeout    = 30
reconnecttimeout     = 30

Анатомия C: строки: host port username password

Формат C: строки: C: hostname port username password. Всё один-к-одному переносится в поля device (host,port через запятую без пробела), user и password.

Параметры cccversion, cccmaxhops, cccwantemu

cccversion — версия протокола CCcam которую OScam представляет upstream серверу. Дефолт 2.3.2. Если upstream ожидает другую версию — меняем. cccmaxhops определяет сколько карт по глубине hop'ов OScam запросит у upstream. 5 — разумный максимум, для прямых подключений ставьте 1. cccwantemu = 0 означает «не запрашивать эмулятор карт» — для реальных карт всегда 0.

Группы (group) и почему они важны при множестве reader'ов

Это то, что большинство гайдов объясняют плохо, и из-за чего половина ошибок после миграции. Группы — это механизм ACL между reader и user. Reader с group = 1 видит только user'ы у которых в параметре group есть цифра 1. Если у вас три reader'а от разных партнёров, дайте им group = 1, 2, 3 соответственно. Тогда вы контролируете какие клиенты видят какие reader'ы.

Простое правило: если хотите чтобы клиент видел все reader'ы — у него group = 1,2,3. Хотите изолировать — только нужные номера. Без совпадения group декодирование не произойдёт, и в логе появится rejected group.

Конвертация F: строк в [account] секции

F: строка в CCcam:

F: client1 secretpass 1 0 0

Параметры после пароля: максимум hop'ов, количество reshare, allow_downgrade (0 = нет). В oscam.user это становится:

[account]
user                 = client1
pwd                  = secretpass
group                = 1
cccmaxhops           = 1
cccreshare           = 0
au                   = 0
monlevel             = 0

F: line формат и его аналог в oscam.user

cccmaxhops у account — это сколько hop'ов этот клиент получит от вас. Если ваш reader даёт hop 0 (прямая карта), и клиенту вы ставите cccmaxhops = 1, он получит эти карты как hop 1. Ставьте 1 для обычных клиентов, 0 если хотите дать прямой доступ (не рекомендую для внешних).

Раздача линии клиентам через CCcam-протокол OScam'ом

OScam принимает CCcam-клиентов через порт, указанный в секции [cccam] файла oscam.conf. Клиенты подключаются точно так же как к обычному CCcam серверу: host, port, username, password. Протокол идентичен.

Настройка cccmaxhops для клиента отдельно от reader'а

Reader и account имеют независимые cccmaxhops. Reader'овский параметр определяет что OScam запрашивает у upstream. Account'овский — что OScam отдаёт клиенту. Это позволяет, например, получать карты hop 0-5 с upstream, но клиентам отдавать только hop 0-1.

Ограничение количества карт через au, services, betatunnel

Для Sky DE и других Nagra-провайдеров, использующих CAID 1801/1833, нужен betatunnel. В секции [account] добавьте:

betatunnel           = 1801.FFFF:1722

Это конвертирует запросы между разными CAID одного провайдера. Без betatunnel каналы на таких провайдерах будут фризиться даже при рабочем reader'е.

Настройка oscam.conf: global, cccam, monitor

Центральный файл конфигурации. Минимальный рабочий вариант:

[global]
logfile              = /var/log/oscam/oscam.log
nice                 = -1
WaitForCards         = 1
clienttimeout        = 5000
fallbacktimeout      = 2500
bindwait             = 5
netprio              = 0

[cccam]
port                 = 12000
reshare              = 0
version              = 2.3.2
nodeid               = A1B2C3D4E5F60011
stealth              = 1

[webif]
httpport             = 8888
httpuser             = admin
httppwd              = changeme
httpallowed          = 127.0.0.1,192.168.0.0-192.168.255.255
httprefreshtimeout   = 10

[monitor]
port                 = 988
aulow                = 30
monlevel             = 2

Секция [global] и logfile, nice, clienttimeout

clienttimeout в миллисекундах — сколько ждать ответа от reader перед тем как вернуть клиенту ошибку. 5000 (5 секунд) — разумный дефолт. fallbacktimeout — когда переключаться на резервный reader. Ставьте его примерно в половину от clienttimeout. nice = -1 повышает приоритет процесса OScam в планировщике — на нагруженных системах помогает.

Секция [cccam]: port, reshare, version, nodeid

port — порт на котором OScam принимает CCcam-клиентов. Стандарт 12000, но можно любой. reshare = 0 для приватного сервера (клиенты не могут пробрасывать карты дальше), 1 или 2 если нужен resharing. version = 2.3.2 — совместима с большинством клиентов. Если у вас клиенты на старых прошивках, которые шлют version 2.0.11, переопределите version в конкретном [account].

Про nodeid — это 16-символьный hex-идентификатор вашего сервера. Если не задать, OScam генерирует автоматически, но каждый раз новый при перезапуске. При reshare между партнёрами коллизия nodeid (два сервера с одинаковым ID) ломает маршрутизацию карт — карты появляются как дубли или вообще не приходят. Лучше задать явно и зафиксировать.

Секция [webif]: httpport, httpuser, httppwd, httpallowed

httpallowed — критически важный параметр. Открывать webif на внешний интерфейс без фаервола — плохая идея. Ограничьте локальной сетью: 127.0.0.1,192.168.0.0-192.168.255.255. Если нужен удалённый доступ — туннель SSH, не открытый порт.

Секция [monitor] для отладки

Порт 988 используется для подключения oscam-monitor клиентов и внешних инструментов. monlevel = 2 даёт пользователям с monlevel = 2 в [account] доступ к статистике через monitor.

Тестирование и отладка после миграции

Первый запуск — всегда в foreground с максимальным debug-уровнем. Не запускайте OScam как сервис пока не убедились что базовая конфигурация работает.

Запуск с -d для дебага

# Полный дебаг, foreground, явная директория конфигов:
oscam -c /etc/oscam/ -d 65535

# Или более умеренный уровень (255 покрывает основное):
oscam -c /etc/oscam/ -d 255

# В фоне с логом:
oscam -b -c /etc/oscam/ -d 255

При -d 65535 лог будет огромным — только для начального поиска проблем. Для production используйте -d 0 или вообще без флага.

Чтение oscam.log: ECM, CW, reader status

Ключевые сообщения которые нужно искать в логе:

  • connected to upstream.provider.com:12000 — reader подключился успешно
  • ECM: SID 1234 CAID 0604 ... -> found (CW received) — декодирование сработало
  • CW not found — карта не ответила, reader не знает этот канал
  • rejected group — несовпадение group между reader и user, проверяйте group в обоих файлах
  • disconnected from ... reconnecting — reader теряет соединение

ECM time в логе показывается в миллисекундах. Всё до 300ms — нормально. 500ms и выше — проблема, канал будет фризиться.

Веб-интерфейс: статус reader'ов, активные клиенты, ecm log

Откройте http://127.0.0.1:8888 в браузере. Вкладка Readers показывает каждый reader с колонкой Status: должно быть OK или CONNECTED. DISCONNECTED — reader не может подключиться, проверяйте host/port/credentials. В вкладке Users видны активные клиенты и их ECM time.

Тест декодирования через dvbapi или внешний клиент

Самый честный тест — подключить реальный клиент (Enigma2 бокс, VLC с tvheadend, любой IPTV плеер) и переключить зашифрованный канал. Если канал декодируется — система работает. Если фризит или чёрный экран — смотрите ECM log в webif.

При работе в Docker важный момент: dvbapi требует доступа к /dev/dvb/* устройствам, и в контейнере это не работает без --network=host и проброса устройств. Для чистого cccam to oscam шлюза без локального декодирования Docker работает нормально в bridge режиме.

Типичные проблемы при миграции и их решение

Клиенты не подключаются: несовпадение cccversion

Самая частая проблема после миграции cccam to oscam. Старый STB или software-клиент представляется серверу как CCcam 2.0.11. Если в oscam.conf у вас version = 2.3.2, handshake может разойтись. Решение: в конкретном [account] добавьте cccversion = 2.0.11. OScam будет согласовывать версию индивидуально для этого клиента.

[account]
user                 = oldstb_client
pwd                  = password
group                = 1
cccversion           = 2.0.11
cccmaxhops           = 1

Reader подключился, но ECM нет: проблема с group или caid

Reader показывает CONNECTED в webif, но декодирования нет. Первое — проверяем group. У reader'а group = 1, у клиентского [account] тоже должно быть group = 1. Если не совпадает — в логе будет rejected group.

Второе — CAID фильтрация. Если в [reader] указан параметр caid, OScam будет запрашивать только эти CAID у upstream. Убедитесь что нужный CAID не отфильтрован. Для начала уберите caid из [reader] совсем и проверяйте без фильтрации.

Высокий ECM time: лишние hop'ы или сетевая задержка

ECM time выше 400ms почти всегда означает либо сетевую задержку до upstream (ping > 150ms — уже много), либо лишние hop'ы. Проверьте cccmaxhops у reader'а — если стоит 10, OScam запрашивает карты через цепочки посредников. Оптимальный cccmaxhops для читателя = 0 (прямая карта) или 1.

При работе через VPN-туннель добавьте keepalive = 1 и уменьшите inactivitytimeout до 15-20 секунд. VPN-туннели, особенно через UDP, режут длинные idle-соединения.

Freezing каналов: betatunnel и Nagra/Viaccess специфика

Каналы Sky DE, Sky IT на Nagra используют CAID 1801. Если без betatunnel — периодические фризы каждые ~30 секунд (период обновления CW). Настройка в [account] или глобально в oscam.conf:

betatunnel           = 1801.FFFF:1722,0604.FFFF:0604

Для Viaccess (Canal+, некоторые региональные пакеты) иногда нужен параметр ident в [reader] чтобы указать конкретный provider ID. Без него OScam запрашивает все ident у upstream, что замедляет ECM.

Множество CAID с одного reader'а фильтруйте через caid и ident:

[reader]
label                = multi_upstream
protocol             = cccam
device               = upstream.example.com,12000
user                 = user
password             = pass
group                = 1
caid                 = 0604,0918,1801
ident                = 0604:000000;1801:000000

Частые вопросы

Можно ли запускать CCcam и OScam одновременно?

Да, если они слушают разные порты. Рабочая схема для постепенной миграции: OScam поднимаете на порту 12001, CCcam оставляете на 12000. Клиентов переводите по одному, меняя порт в их конфигурации. Когда все клиенты перешли — CCcam останавливаете. Минус: два процесса потребляют в два раза больше памяти и CPU. На слабом STB с 128MB RAM это может быть проблемой.

Какая версия OScam стабильнее для production?

Последняя стабильная из официального SVN или git-зеркала. Не берите сборки с форумов от неизвестных авторов — были случаи backdoor в патченых бинарниках. Лучше потратить 20 минут и собрать под свою архитектуру из исходников: ./configure --enable-cccam --enable-newcamd --enable-webif && make. Для Enigma2 STB используйте тулчейн от вашего дистрибутива (OpenPLi, OpenATV).

Нужно ли менять что-то у клиентов после перехода на OScam?

Нет. OScam с настроенным protocol = cccam в [account] выглядит для клиента как обычный CCcam-сервер. Host, port, username, password не меняются. Клиент не знает и не должен знать что на сервере теперь OScam. Единственный случай когда нужно вмешаться — несовпадение cccversion, о котором написано выше.

Как перенести peer-обмены (resharing) с партнёрами?

Каждый партнёр превращается в пару: [reader] в oscam.server для получения его линии, и [account] в oscam.user для раздачи ему вашей. Используйте отдельные group для каждого партнёра: партнёр A — group = 10, партнёр B — group = 11. Их [account] видят только reader'ы из своей group, линии не перемешиваются. Это важнее чем кажется — без изоляции по group случайный reshare между партнёрами создаёт hop-петли.

OScam потребляет больше CPU чем CCcam?

Сравнимо. На одноядерном MIPS-процессоре в старом STB разница незаметна — узкое место всегда сеть и количество ECM/sec. На современном x86-сервере или многоядерном ARM OScam работает эффективнее за счёт многопоточности. Реальный враг производительности — высокий cccmaxhops, который заставляет обрабатывать карты через длинные цепочки и увеличивает количество ECM-запросов.

Что делать со старым CCcam.cfg — удалять?

Не удалять минимум 30 дней. Сохраните как: cp /etc/CCcam.cfg /root/backups/CCcam.cfg.bak.$(date +%Y%m%d). Если OScam начнёт давать проблемы через неделю, быстрый откат — это просто запустить CCcam со старым конфигом. Удалять только после того как OScam работает стабильно в production больше месяца.

Практические советы для стабильного просмотра

Даже самая стабильная линия CCCam или OSCam требует пары простых подготовительных шагов. Обновляйте прошивку ресивера, раз в неделю очищайте ECM‑кеш и держите 15–20% свободного места на USB‑накопителе или во встроенной памяти, чтобы кардридер записывал ключи без задержек.

При настройке антенны оставляйте запас по MER/BER: смещение на два градуса или ослабленный F‑коннектор чаще становится причиной “фризов”, чем сам кардшаринг. Держите под рукой короткий патч‑корд для проверки другого роутера и сохраните два профиля в OSCam — под TCP и под UDP — чтобы мгновенно переключиться, если провайдер начнёт фильтровать протокол.

Utgard.tv следит за каждым хабом 24/7, однако вы можете ускорить диагностику, если будете вести небольшой журнал действий. Записывайте время переключения канала, активный CAID и то, использовали ли вы Wi‑Fi или Ethernet. Такой мини‑отчёт позволит инженерам воспроизвести вашу конфигурацию в лаборатории и предложить решение не за часы, а за минуты.

  • Держите активными две линии: если первый сервер уходит на обслуживание, второй тут же подхватывает поток без повторного ввода логина.
  • Раз в месяц делайте замер скорости и задержек. Стабильных 1–2 Мбит/с при пинге до 80 мс достаточно для SD/HD, но если джиттер превышает 20 мс — переведите роутер на провод.
  • Сохраните в закладки страницу статуса Utgard.tv и Telegram‑бота @utgard_tv_bot — там появляются уведомления о работах раньше, чем успеют среагировать SEMrush или внешние мониторы.