Сравнение протоколов satellite cardsharing: CCcam vs OScam
Если вы уже знаете что такое cardsharing и стоите перед выбором между CCcam, OScam, NewCamd и MGcamd — эта статья для вас. Здесь не будет маркетинга. Только реальные цифры ECM time, примеры конфигов и честный ответ на вопрос: что ставить на ресивер. Этот satellite cardsharing comparison построен на практике, а не теории.
Что сравниваем: протоколы и реализации satellite cardsharing
Первая ошибка, которую делают почти все — путают протокол с программой. CCcam и NewCamd — это протоколы передачи DCW (Decryption Control Words) по сети. OScam и MGcamd — это программный стек, который умеет говорить по этим протоколам. Разница принципиальная.
Грубая аналогия: HTTP — это протокол, а Firefox — реализация. Точно так же OScam — реализация, которая поддерживает одновременно CCcam, NewCamd, camd35 и другие протоколы. А "CCcam" как программа — это конкретный демон от Ferrari Electronics, который говорит только на своём протоколе.
Разница между протоколом и софтверной реализацией
Протокол определяет формат пакетов, аутентификацию и способ передачи DCW. Реализация — это конкретный бинарник, который вы запускаете на ресивере или сервере. OScam может работать и как сервер (раздавая C-lines клиентам CCcam), и как клиент (подключаясь к CCcam-серверу провайдера). CCcam так не умеет.
CCcam — закрытый протокол на порту 12000
CCcam работает по TCP на порту 12000 по умолчанию. Порт можно менять директивой SERVER LISTEN PORT в /etc/CCcam.cfg. Протокол закрытый, проприетарный — Ferrari Electronics никогда не публиковала спецификацию. Всё что есть в open source — это реверс-инжиниринг.
Конфиг клиента выглядит так:
C: hostname.server.com 12000 username password
Это "C-line" — стандартный формат подключения к CCcam-серверу. Для фидов используется "F-line", для NewCamd — "N-line", для MGcamd — "M-line".
OScam — open source форк с поддержкой CCcam/NewCamd
OScam вырос из форков mgcamd и camd35, но давно стал самостоятельным проектом. Поддерживает CCcam, NewCamd, camd35 (порт 33000, UDP/TCP), radegast, gbox и ещё дюжину протоколов. Конфигурация разбита на несколько файлов: /etc/oscam/oscam.conf, oscam.server, oscam.user, oscam.dvbapi.
Читер oscam.server для подключения к CCcam-серверу:
[reader]
label = my_cccam_server
protocol = cccam
device = hostname.server.com,12000
user = username
password = password
caid = 0500,1802,0604
group = 1
NewCamd — старый протокол на порту 15000
NewCamd появился раньше CCcam и до сих пор используется, хотя и реже. Стандартный порт — 15000. Протокол проще CCcam, хуже масштабируется на большое количество клиентов. OScam поддерживает NewCamd и на стороне сервера, и клиента. Конфиг клиента в newcamd.list: строка формата N: hostname port user pass deskey...
MGcamd — лёгкий клиент для Enigma2
MGcamd — это только клиент, не сервер. Написан именно для слабых ресиверов: Dreambox DM800, DM7025, Vu+ Solo. Потребляет минимум RAM и CPU, но функциональность урезана — нет webif, нет cacheex, нет локальных readers кроме смарт-карт. Конфиг — файл newcamd.list с N-lines и C-lines.
Сравнение по скорости ECM и производительности
ECM time — это время от запроса до получения DCW. Для нормального просмотра нужно укладываться в 500мс. Оптимум — до 300мс. Ниже 200мс — отлично. Реальные цифры зависят от CAS-системы канала, пинга до сервера и наличия кэша.
Типичные значения ECM time по типам CAS при хорошем соединении:
- Viaccess 2.6 — ~200мс
- Nagra 3 — ~280мс
- Irdeto 2 — ~350мс
- NDS Videoguard — ~400мс
Это цифры без cacheex. С cacheex в OScam повторные запросы отдаются из кэша за 10-50мс.
Среднее ECM time для CCcam (250-450 мс)
CCcam без всяких трюков показывает 250-450мс на большинстве CAS. Это нормально для просмотра, но каждый запрос идёт через полный цикл: запрос → сервер → CAS → ответ. Кэширования на уровне протокола нет. Если канал переключился — снова полный цикл.
ECM time для OScam (180-350 мс при правильной настройке)
OScam без cacheex примерно сопоставим с CCcam. Но стоит включить cacheex — картина меняется. При наличии кэш-пиров повторный запрос на тот же ECM возвращается мгновенно, без обращения к серверу. Это и даёт итоговые 180-350мс в среднем.
Влияние EMM на нагрузку
EMM (Entitlement Management Messages) — сервисные сообщения для обновления подписки на карте. Для cardsharing клиента они не нужны и только загружают соединение. В oscam.server отключается так:
saveemm-u = 0
saveemm-s = 0
saveemm-g = 0
В CCcam аналога нет — EMM-трафик всегда идёт, отключить программно нельзя.
Кэширование: cacheex в OScam vs отсутствие в CCcam
Cacheex — это обмен ECM-кэшем между двумя OScam-серверами. Три режима: mode 1 (пассивный приём), mode 2 (активная отдача), mode 3 (push без запроса). Конфиг в oscam.server:
[account]
user = cachepeer
password = secret
caid = 0500
cacheex = 2
cacheex-maxhop = 3
CCcam как закрытый протокол такой функции не имеет в принципе. Если сравниваете скорость OScam с cacheex против CCcam без него — сравнение некорректное.
Нагрузка на CPU слабого ресивера (Vu+ Solo, DM800)
На слабом железе разница ощутима. MGcamd в режиме клиента грузит CPU на 5-15%. CCcam — 15-30%. OScam с активным cacheex и несколькими readers — 20-40%, иногда больше. На ресиверах с 64-128MB RAM OScam ещё и по памяти может упираться, если включить много функций.
Рабочая схема для слабого железа: MGcamd как клиент на ресивере, OScam как сервер на роутере (OpenWrt) или Raspberry Pi. Ресивер получает DCW от локального OScam за 10-30мс — минимальная нагрузка, максимальная скорость.
Стабильность и поддержка современных CAS
Последний релиз CCcam — версия 2.3.2, вышла в 2015 году. С тех пор — тишина. Ferrari Electronics закрыли проект, и это проблема.
OScam активно поддерживается: актуальная ветка svn r11725 и выше, форки oscam-emu добавляют поддержку Powervu, Tandberg, BISS. Если провайдер вещания обновил CAS — шансы что OScam-emu уже поддерживает новую версию несравнимо выше, чем у CCcam 2.3.2.
Поддержка Nagra Merlin, Powervu, Tandberg
CCcam 2.3.2 не поддерживает Nagra Merlin 2, Powervu и Tandberg — просто не умеет работать с этими CAS. OScam-emu (форк с расширенным emuhandler) поддерживает все три. Если ваш пакет использует Powervu или Tandberg — выбора нет, только OScam-emu.
Работа с BISS-ключами и constant.cw
BISS (Basic Interoperable Scrambling System) — схема шифрования, часто используемая для спортивного вещания. Ключи статические, не меняются в процессе трансляции. OScam поддерживает constant.cw файл — список пар transponder/key. Это вообще не cardsharing в классическом смысле, но удобно для BISS-каналов без смарт-карты. CCcam тоже поддерживает constant.cw через плагины, но OScam это делает нативно.
Reader-конфигурация для DVB-карт
Если у вас физическая смарт-карта через DVB-ридер — OScam умеет работать с mouse (классический serial reader), smargo (USB smartcard reader), omnikey, pcsc. Пример reader для встроенного ридера Enigma2-ресивера:
[reader]
label = local
protocol = internal
device = /dev/sci0
group = 1
caid = 0500
Для smargo:
[reader]
label = smargo_reader
protocol = mouse
device = /dev/ttyUSB0
group = 1
Failover и fallback reader через group
В oscam.dvbapi можно указать приоритет обращения к readers через параметр group. Если основной reader (group 1) не отвечает — OScam переключается на резервный (group 2). Это работает автоматически, с настраиваемым таймаутом cwfailaccepttimeout. У CCcam failover реализован хуже — нет гибкого управления приоритетами между локальной картой и удалённым шарингом.
Удобство настройки и логирование
CCcam — один файл /etc/CCcam.cfg. Всё в нём: C-lines, F-lines, N-lines, M-lines, параметры сервера. Просто и понятно. OScam — модульная структура из нескольких файлов. Сложнее для новичка, но гибче для администратора.
Webif в OScam (порт 8888) — мониторинг в реальном времени
Это реально одно из главных преимуществ OScam. Открываете http://ip-ресивера:8888 и видите: статус каждого reader, текущее ECM time, количество обработанных ECM/EMM, активные клиенты, cacheex статистику. В реальном времени, без перезагрузки страницы.
В CCcam есть telnet на порту 16001, команда status. Работает, но webif это другой уровень удобства.
Конфиги CCcam vs модульная структура OScam
Файлы OScam и их назначение:
/etc/oscam/oscam.conf— глобальные настройки: webif порт, loglevel, cachedelay/etc/oscam/oscam.server— readers (локальные карты, удалённые серверы)/etc/oscam/oscam.user— клиенты (кто подключается к вашему серверу)/etc/oscam/oscam.dvbapi— приоритеты CAID для dvbapi
oscam.dvbapi особенно важен — без него OScam будет перебирать все readers подряд, не зная какой CAID какому reader соответствует. Пример:
priority
P: 0500:020800 ; Viaccess Canal+
P: 1802:000000 ; Nagra Digiturk
Логи: уровни debug 0-255
В oscam.conf параметр loglevel от 0 (нет логов) до 255 (полный debug). Для повседневной работы достаточно 64. Для диагностики ECM проблем — 255, но это генерирует несколько мегабайт в час на слабом ресивере.
Live log через telnet/ssh
Следить за логом в реальном времени:
tail -f /tmp/.oscam/oscam.log
Или через webif — вкладка "Live Log". Там же можно менять loglevel на лету без перезапуска демона. У CCcam такой возможности нет — только перезапуск для изменения параметров.
Критерии выбора провайдера cardsharing
Протокол и软ware — это только часть уравнения. Качество сервера провайдера не менее важно. Но как выбрать, не зная конкретных имён? Смотреть на измеримые параметры.
На что смотреть: uptime сервера, среднее ECM time
Uptime должен быть выше 99% — это значит не более 87 часов простоя в год. Меньше — уже проблема. Среднее ECM time смотрите в webif OScam после нескольких часов работы: там накапливается статистика. Если ECM time стабильно выше 800мс — сервер перегружен или физически далеко.
Поддерживаемые CAS и пакеты под нужный спутник
Перед покупкой уточните: какой CAID, какой провайдер, какой спутник. Например, Viaccess 0x0500 на 19.2°E и Viaccess 0x0500 на 13.0°E — это разные конфигурации. Сервер может поддерживать один и не поддерживать другой.
Тестовый период перед оплатой
Нормальный провайдер даёт тестовый доступ на 24-48 часов. За это время можно проверить реальное ECM time на вашем железе, стабильность под нагрузкой (переключение каналов), работу failover. Без теста — деньги на ветер.
Качество техподдержки и формат конфига (C-line/N-line)
Хороший провайдер выдаёт готовый конфиг под ваш клиент: C-line для CCcam/OScam, N-line для NewCamd. Если дают только "хост, порт, логин, пасс" и говорят "разбирайтесь сами" — тревожный сигнал. Техподдержка должна отвечать в разумное время, особенно если сервер упал.
Гео-расположение сервера и пинг
Проверяем до покупки:
ping hostname.server.com
telnet hostname.server.com 12000
Пинг до сервера должен быть ниже 50мс. При 100мс+ ECM time вырастет пропорционально. Сервер в Европе для европейских пакетов логичен. Если сервер в Азии, а вы декодируете Astra 19.2°E — готовьтесь к задержкам.
Что не работает: типичные ошибки сравнения
Большинство сравнений в интернете содержат одни и те же ошибки. Разберём главные.
Сравнение ECM time на разных каналах — некорректно
ECM time зависит от CAS-системы канала прежде всего. Viaccess принципиально быстрее Irdeto. Если вы сравниваете CCcam на Viaccess-канале и OScam на NDS Videoguard-канале — вы сравниваете разные CAS, а не разные протоколы. Корректный satellite cardsharing comparison возможен только на одном и том же транспондере, в одно и то же время, с тем же CAID.
Старые сборки CCcam на современных образах Enigma2
CCcam 2.1.4 не работает на Enigma2 OE 2.5+ нормально. Несовместимость библиотек, проблемы с dvbapi. Если тестируете CCcam — используйте версию 2.3.2 (последняя официальная). Сравнивать 2.1.4 с актуальным OScam svn r11725 — нечестно в обе стороны.
Запуск OScam без правильного oscam.dvbapi
Без настроенного oscam.dvbapi с приоритетами CAID OScam будет последовательно опрашивать все readers при каждом ECM-запросе. ECM time может вырасти до 2-5 секунд — не потому что OScam медленный, а потому что он перебирает 5 readers вместо сразу идти в нужный. Это не баг, это конфигурация.
Игнорирование cacheex при сравнении скорости
Сравнивать OScam без cacheex с OScam с cacheex — получите другие цифры. Сравнивать OScam с cacheex против CCcam без него и делать вывод "OScam быстрее" — некорректно методологически. Честный satellite cardsharing comparison требует одинаковых условий: cacheex либо у обоих, либо ни у кого.
И ещё одно: два разных демона на одном ресивере — нельзя. CCcam и OScam одновременно на одном боксе конфликтуют за dvbapi и порты. Выбирайте один.
Какой протокол быстрее: CCcam или OScam?
OScam быстрее в среднем на 50-100мс за счёт cacheex и оптимизированной обработки ECM. При включённом cacheex mode 2 повторные запросы возвращаются из кэша за 10-50мс вместо полного цикла запроса к серверу. CCcam работает быстрее только в простой схеме без кэш-пиров и с минимумом readers — тогда оверхед OScam на инициализацию становится заметным.
Можно ли использовать CCcam-конфиг (C-line) на OScam?
Да, OScam полностью поддерживает протокол CCcam. C-line добавляется в /etc/oscam/oscam.server как отдельный reader с параметрами: protocol = cccam, device = hostname,12000, user = username, password = password. OScam подключится к CCcam-серверу как обычный CCcam-клиент. Провайдер не увидит разницы.
Какой стандартный порт у CCcam и NewCamd?
CCcam — порт 12000 по умолчанию, меняется директивой SERVER LISTEN PORT в /etc/CCcam.cfg. NewCamd — порт 15000. camd35 — порт 33000, работает как по UDP, так и по TCP. При работе за NAT нужно пробрасывать соответствующие порты на роутере к IP ресивера.
Что такое cacheex и почему его нет в CCcam?
Cacheex — механизм обмена ECM-кэшем между OScam-серверами. Когда один сервер расшифровал ECM и получил DCW, он передаёт результат кэш-пирам. Следующий запрос на тот же ECM возвращается мгновенно из кэша. CCcam — закрытый проприетарный протокол, Ferrari Electronics никогда не добавляла такую функцию. Протокол не предусматривает peer-to-peer обмен кэшем, только классическую схему запрос-ответ.
Какой софт меньше нагружает CPU слабого ресивера?
MGcamd — самый лёгкий: 5-15% CPU на DM800 при обычном просмотре. OScam с активным cacheex и несколькими readers — 20-40%. CCcam занимает 15-30%. На Vu+ Solo или DM800 с ограниченными ресурсами оптимальная схема: MGcamd как клиент непосредственно на ресивере, OScam как сервер на отдельном устройстве — роутере с OpenWrt или Raspberry Pi Zero W.
Поддерживает ли CCcam современные CAS типа Nagra Merlin?
Нет. Последняя версия CCcam 2.3.2 вышла в 2015 году и не получала обновлений. Nagra Merlin 2, Powervu и Tandberg не поддерживаются. Для этих CAS нужен OScam-emu — форк с расширенным emuhandler, который активно поддерживается сообществом. Если ваш пакет использует любой из этих CAS — CCcam не вариант.
Как проверить ECM time после настройки?
В OScam: откройте http://ip-ресивера:8888, перейдите во вкладку Status — колонка ECM Time показывает среднее значение по каждому reader. В CCcam: telnet на порт 16001, команда status. Норма — ниже 500мс, комфорт — ниже 300мс. Если стабильно выше 800мс — проблема либо в пинге до сервера, либо в перегрузке шары, либо в неправильном oscam.dvbapi.
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.