Миграция с 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 APIoscam.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 или внешние мониторы.