Миграция с 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 больше месяца.

Practical checklist for smooth viewing

Even the best CCCam or OSCam line needs two or three simple preparations. Update your receiver firmware, reset the ECM cache once a week and keep 15–20% free space on the USB stick or internal flash so that the reader can store keys without delays.

When tuning a dish, aim for MER/BER reserve: a two‑degree offset or a loose F‑connector often causes the “freezing” that users blame on cardsharing. Keep a short patch cord to test alternative routers, and save two profiles in OSCam — one for TCP, one for UDP — so you can switch instantly if your ISP starts filtering a protocol.

Utgard.tv monitors each hub 24/7, but you can speed up diagnostics by keeping a short log of your receiver actions. Note the time when you changed the channel, which CAID was active and whether you used Wi‑Fi or Ethernet. This tiny “journal” helps engineers reproduce your environment in the lab and return with a solution in minutes instead of hours.

  • Keep two line slots enabled: if the first server hits a maintenance window, the second one instantly takes over without re-entering credentials.
  • Run a monthly speed and latency test. Stable 1–2 Mbps with ping <80 ms is enough for SD/HD, but if jitter exceeds 20 ms, switch the router to wired mode.
  • Save the Utgard.tv status page and Telegram bot @utgard_tv_bot to bookmarks — they publish maintenance notices before SEMrush or uptime monitors raise alerts.