Протокол Camd35: настройка кардшаринга в OScam

Главная Статьи Протокол Camd35: настройка кардшаринга в OScam

Дата публикации

18.06.2026

Протокол Camd35: настройка кардшаринга в OScam

Если вы уже запустили OScam, прописали локальный ридер и теперь думаете, по какому протоколу отдавать CW клиентам или забирать их с каскадного сервера — скорее всего, вы упрётесь в выбор между CCcam, newcamd и camd35. Camd35 протокол кардшаринг — тема, которую большинство туториалов освещает поверхностно: скопировал пример конфига, оно как-то заработало, и ладно. Здесь разберём детально: что за зверь, чем отличается от конкурентов и как грамотно настроить связку сервер-клиент.

Что такое протокол Camd35 и чем он отличается от CCcam и newcamd

Происхождение протокола и его место в экосистеме кардшаринга

Camd35 вырос из проекта camd3 — одного из первых open-source эмуляторов для DVB-карт. Протокол изначально проектировался как простой транспорт для ECM/EMM-запросов: клиент шлёт зашифрованный ECM, сервер возвращает CW. Никаких сложных握手, никакого обмена картами между узлами — только запрос и ответ.

Это принципиально отличает camd35 от CCcam-пиринга, где серверы обмениваются данными о картах и строят так называемые card-sharing-цепочки. В camd35 ничего подобного нет: сервер либо может расшифровать ECM с помощью локальной карты, либо нет.

Camd35 (UDP) против cs378x (TCP) — в чём разница

Тут многие путаются, поэтому сразу: camd35 и cs378x — это один и тот же протокол на прикладном уровне. Разница только в транспорте.

  • camd35 — работает поверх UDP, порт по умолчанию 15000
  • cs378x — тот же протокол поверх TCP, порт обычно 15001

UDP-вариант быстрее при идеальных условиях, но не держит состояние сессии. За NAT или на нестабильных каналах сессия рвётся, и клиент просто перестаёт получать CW без каких-либо внятных ошибок. TCP-вариант (cs378x) решает эту проблему: соединение явное, разрывы детектируются, переподключение происходит автоматически.

На практике: если клиент и сервер в одной локальной сети — можно использовать camd35/UDP. Всё остальное — cs378x/TCP без вариантов.

Когда Camd35 предпочтительнее CCcam и newcamd

CCcam — протокол с куда большими накладными расходами. Он тащит за собой метаданные карт, счётчики, пиринговую логику. Если вам нужен простой каскад «один сервер с картой → несколько клиентов», camd35 справится лучше и с меньшей нагрузкой на железо.

По сравнению с newcamd: оба протокола шифруют трафик, но по-разному. Camd35 генерирует ключ сессии на основе пароля пользователя (MD5 от пароля → AES-ключ). Newcamd использует отдельный статический DES-ключ длиной 14 байт, который прописывается в конфиге явно. У newcamd чуть больше гибкости в управлении ключами, но camd35 проще в настройке каскадов OScam-to-OScam.

Настройка Camd35-сервера в OScam

Секция [camd35] и [cs378x] в oscam.conf

Начнём с главного конфига. Пути зависят от образа:

  • Enigma2 на Vu+/DM: /etc/tuxbox/config/oscam/oscam.conf
  • OpenATV/OpenPLi: /var/etc/oscam/oscam.conf
  • Docker-контейнер или x86: /etc/oscam/oscam.conf

Для UDP-варианта в oscam.conf нужна секция:

[camd35]
port = 15000
serverip = 0.0.0.0

Для TCP-варианта — отдельная секция:

[cs378x]
port = 15001
serverip = 0.0.0.0

Важный момент: если на той же машине уже висит newcamd на порту 15000 или 15001 — будет конфликт привязки, OScam выдаст ошибку Cannot bind to port и не стартует соответствующий листенер. Смените порт на что-нибудь вроде 15010/15011 и не забудьте обновить правило фаервола.

Параметр serverip со значением 0.0.0.0 означает прослушивание на всех интерфейсах. Если хотите ограничить — укажите конкретный IP интерфейса.

Создание пользователя в oscam.user

Файл пользователей — oscam.user в той же директории. Пример записи:

[account]
user = myclient
pwd = secretpass123
group = 1,2
caid = 0500,1800
ident = 0500:032830
au = 1
uniq = 0
maxconnections = 1

Обратите внимание на pwd: в camd35 этот пароль — не просто строка аутентификации. Из него выводится ключ шифрования всей сессии. Клиент и сервер независимо вычисляют этот ключ из одинакового пароля. Если хоть один символ отличается — весь обмен ECM/EMM будет мусором, и в логах появится wrong password или просто decoded: 0 без объяснений.

Параметр au = 1 разрешает передачу EMM для автообновления ключей карты. Без него AU работать не будет, даже если всё остальное настроено верно. И обязательно проверьте, что caid в записи пользователя совпадает с caid карты — иначе EMM просто не дойдут.

Привязка ридера и групп каналов

Группы — механизм маршрутизации ECM в OScam. Ридер с картой и пользователь должны быть в одной группе, иначе сервер не будет использовать эту карту для данного клиента.

Если у вас несколько карт разных провайдеров — распределите их по группам (group = 1 для одного пакета, group = 2 для другого) и в oscam.user укажите только те группы, к которым у конкретного пользователя должен быть доступ. Это чище и безопаснее, чем давать всем доступ ко всему.

Настройка Camd35-клиента в OScam

Ридер типа camd35 и cs378x в oscam.server

На стороне клиента — файл oscam.server. Пример ридера для UDP-подключения:

[reader]
label = myserver_camd35
protocol = camd35
device = 192.168.1.100,15000
user = myclient
password = secretpass123
group = 1,2
caid = 0500,1800
ident = 0500:032830
reconnecttimeout = 30
lb_weight = 100

Для TCP-варианта меняем только две строки:

protocol = cs378x
device = 192.168.1.100,15001

Разница в параметре device для UDP и TCP кажется незначительной, но протокольно это разные вещи. При protocol = camd35 OScam отправляет датаграммы на указанный UDP-порт. При protocol = cs378x — устанавливает TCP-соединение и держит его живым.

Параметры device, key, group, caid

В отличие от newcamd, в camd35 нет отдельного параметра key с DES-ключом. Шифрование сессии выводится из password — это одновременно и секрет аутентификации, и ключевой материал. Если видите в примерах конфигов строку key = для camd35-ридера — это либо ошибка, либо остаток от newcamd-конфига.

Параметры caid и ident на клиенте — это фильтры: OScam будет слать через этот ридер только ECM с указанными CAID и provider ID. Если оставить их пустыми, ридер будет получать все ECM, что может привести к лишней нагрузке и медленным таймаутам по неподдерживаемым каналам.

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

Веб-интерфейс по умолчанию — порт 8888. Открываете http://[IP]:8888, раздел Readers. Там видно статус каждого ридера: ONLINE/OFFLINE/CONNECTED, счётчик ECM time (среднее время ответа в миллисекундах) и поле rc — результат последних запросов.

Значения rc, которые важно знать:

  • E0 / decoded — всё хорошо, CW получен
  • E1 / not found — карта не знает этого ECM (не тот провайдер или caid)
  • E2 / timeout — сервер не ответил вовремя
  • E3 / error — ошибка на стороне сервера или проблема с дешифровкой

Для просмотра живых логов:

tail -f /var/log/oscam.log

Для максимально подробного дебага можно запустить OScam вручную:

oscam -d 255 -c /etc/oscam

Флаг -d 255 включает все уровни логирования — вывод будет объёмным, но там видно каждый ECM-запрос, ответ и статус шифрования.

Диагностика и устранение типичных ошибок Camd35

Ошибка 'wrong password' и рассинхрон ключей

Это самая частая проблема. Клиент подключился (статус ONLINE), но CW не приходят или приходят мусором — freeze на каналах. В логе сервера видно что-то вроде:

2026/01/15 10:23:41 c [camd35] wrong password for user myclient

Причины бывают неочевидными. Пробел в конце пароля, разный регистр, копипаст с невидимым символом — всё это ломает дешифровку, потому что ключ сессии выводится из точного байтового значения пароля. Проверяйте пароль посимвольно, особенно если копируете из веб-интерфейса.

Ещё один вариант: старые клиенты на camd3 (не camd35) могут не поддерживать шифрование сессии и слать трафик в открытом виде. Современный OScam-сервер с camd35 такое не примет. Если подключается legacy-клиент — нужно либо обновить его, либо поднять отдельный листенер без шифрования (что в 2026 году — плохая идея).

Постоянный rc=E1/not found и проблема с caid/ident

Клиент подключён, сервер отвечает, но все ответы — not found. Чеклист:

  1. CAID в oscam.user на сервере совпадает с CAID канала?
  2. Provider ID (ident) в oscam.server на клиенте совпадает с реальным провайдером?
  3. Группы между oscam.user и ридером на сервере пересекаются?
  4. На карте вообще есть подписка на нужный пакет?

Пункт 3 часто упускают. Если ридер с картой в group = 1, а пользователь в group = 2 — OScam не будет маршрутизировать ECM через эту карту для этого пользователя. Молча. Без ошибок в логе.

Также: карты V13/V14 (Viaccess) с большим количеством провайдеров иногда дают долгий ECM time — 600-800 мс и выше. При таком времени ответа freeze неизбежен, даже если rc=E0. Это не проблема конфига camd35, это характеристика конкретной карты или перегруженного хопа.

Обрывы UDP-сессии и фильтрация портов NAT

UDP не держит состояние, и NAT-роутер выбрасывает запись из таблицы трансляций после таймаута бездействия — обычно 30-120 секунд в зависимости от прошивки. Если в этот момент не было ECM-запросов (тихий канал, пауза в трансляции) — следующий пакет уйдёт в никуда.

Если вы за двойным NAT (например, CGNAT у провайдера + домашний роутер) — camd35/UDP вообще не жизнеспособен. Пакеты будут теряться случайно и непредсказуемо. Переходите на cs378x/TCP: TCP-сессия держит соединение, и OScam сам обрабатывает переподключение через reconnecttimeout.

Параметр keepalive в oscam.conf для секции [cs378x] помогает удерживать TCP-соединение через агрессивные файрволы:

[cs378x]
port = 15001
serverip = 0.0.0.0
keepalive = 1

Как выбрать источник карты для Camd35-подключения

Критерии стабильного сервера: ECM time, аптайм, локальная карта

Когда настраиваете Camd35 протокол кардшаринг для работы с внешним источником, главный показатель — ECM time. До 300 мс — хорошо, 300-500 мс — приемлемо, выше 600 мс — начнутся freeze на быстро меняющихся каналах. Это не вопрос протокола, это вопрос задержки и нагрузки на карту.

Локальная карта лучше перешаренной всегда. Каждый дополнительный хоп добавляет 50-150 мс и точку отказа. Если источник сам тянет CW с чужого сервера по CCcam — ваши ECM идут через три сервера минимум, и ECM time будет соответствующим.

Аптайм важен, но его сложно проверить заранее. Косвенный признак надёжного источника — наличие разных CAID и провайдеров с реальными ident-кодами, а не один-два канала для демонстрации.

Признаки ненадёжного источника

Несколько красных флагов, которые видно сразу после подключения:

  • ECM time скачет от 100 до 2000 мс в течение одного часа — карта перегружена или хоп нестабилен
  • AU не работает — EMM не проходят, значит либо au не выставлен, либо карта не локальная и EMM физически некуда передавать
  • Частые rc=E2 (timeout) при нормальном пинге до сервера — сервер отвечает на ping, но не справляется с ECM-нагрузкой
  • Нет нужного provider ident в ответах — значит карта не покрывает ваш пакет, хотя CAID совпадает

Постоянный freeze при правильном конфиге — почти всегда проблема на стороне источника, а не вашей настройки.

Юридические аспекты и легальное использование

Camd35 протокол кардшаринг — это инструмент. Как и любой инструмент, он может использоваться законно и незаконно. Законные сценарии: тестовый стенд с собственной картой, каскад между вашими же серверами для раздачи по дому, разработка и отладка образов для DVB-оборудования.

Использование чужих карт без согласия владельца или оператора — это нарушение условий абонентского договора и, в большинстве юрисдикций, уголовно наказуемо. Протокол не делает это менее незаконным. Настраивайте только то, на что у вас есть права.

Какой порт использует протокол Camd35 по умолчанию?

UDP-вариант camd35 по умолчанию слушает порт 15000, TCP-вариант cs378x — обычно 15001. Оба порта задаются в соответствующих секциях oscam.conf и могут быть изменены на любой свободный порт. Главное — синхронизировать настройку на сервере и клиенте и открыть нужный порт в фаерволе.

Чем camd35 отличается от cs378x?

На прикладном уровне это один и тот же протокол. Разница в транспорте: camd35 работает поверх UDP, cs378x — поверх TCP. TCP-вариант (cs378x) стабильнее за NAT и на нестабильных каналах, потому что держит явное соединение и умеет переподключаться. UDP-вариант не имеет механизма восстановления сессии — при потере пакетов клиент просто не получает CW.

Почему клиент подключается, но каналы не открываются (rc=not found)?

Нужно проверить несколько вещей последовательно: совпадает ли CAID в oscam.user на сервере с CAID канала; совпадает ли provider ident в oscam.server на клиенте с реальным провайдером карты; пересекаются ли группы (group) между записью пользователя и ридером на сервере. Если всё совпадает — проверьте, есть ли на карте реальная подписка на нужный пакет и выставлен ли au = 1 для передачи EMM.

Что означает ошибка 'wrong password' в логе OScam?

В camd35 пароль — это не просто строка для входа. Из него выводится ключ шифрования всей сессии. Если пароль на сервере и клиенте отличается хотя бы одним символом — ключи не совпадут, и весь обмен ECM/EMM будет зашифрован разными ключами. Сервер не сможет расшифровать запросы клиента и выдаст wrong password. Это принципиальное отличие от протоколов, где пароль используется только для аутентификации.

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

Да, это один из лучших сценариев применения протокола. Один OScam поднимает листенер в секции [camd35] или [cs378x] и выступает сервером. Второй OScam создаёт ридер с protocol = camd35 или protocol = cs378x и выступает клиентом. Так строится каскад без CCcam-пиринга и его накладных расходов — чисто, просто, с полным контролем через группы и фильтры CAID.

Camd35 шифрует трафик?

Да. Весь обмен ECM/EMM в camd35 шифруется с помощью AES-ключа, выведенного из пароля пользователя. Для сравнения: newcamd использует статический DES-ключ из 14 байт, который прописывается в конфиге явно и не зависит от пароля. Подход camd35 проще в управлении — не нужно генерировать и синхронизировать отдельные ключи, достаточно задать надёжный пароль для каждого пользователя.

О статье

  • Практические советы и инструкции
  • Материалы по спутниковому ТВ
  • Поддержка и помощь 24/7