Кардшаринг: настройка и тест CCcam/OScam в 2026
Если вы уже подняли линию или получили её от провайдера, но каналы не открываются или сыпятся фризами — эта статья именно про это. Здесь не будет теории про то, что такое кардшаринг вообще, только практика: кардшаринг настройка тест CCcam и OScam, реальные конфиги, порты и разбор ошибок по симптомам. Я разберу это так, как обычно диагностирую сам — от быстрой проверки статуса до чтения лога построчно.
Статья рассчитана на тех, кто уже открыл CCcam.cfg или oscam.server и не понимает, почему статус вроде бы зелёный, а картинка чёрная. Пройдёмся по всем слоям — от порта до CAID.
Как проверить, что кардшаринг вообще работает: быстрый тест за 5 минут
Прежде чем лезть в конфиги, нужно понять на каком этапе всё ломается. Есть три разных состояния: сервер недоступен вообще, сервер отвечает но карты нет, и карта есть но конкретный канал не расшифровывается. Это три разных проблемы с разными решениями, и путать их — главная ошибка новичков.
Проверка статуса соединения через веб-интерфейс OScam (порт 8888)
Если у вас OScam, откройте браузер и зайдите на http://IP-ресивера:8888. Это стандартный порт webif, если вы не меняли его в oscam.conf. На вкладке Status → Readers вы увидите список ридеров и их состояние. Зелёный — соединение установлено. Красный или жёлтый — проблема на уровне сети или авторизации, дальше можно даже не смотреть каналы.
На вкладке Status → Clients видно, сколько клиентов подключено и какие ECM они запрашивают прямо сейчас. Это самый быстрый способ понять, живая линия или нет — если webif вообще не грузится, проблема либо в порту 8888 (не проброшен или занят), либо демон не запущен.
Чтение CCcam.info и лога /var/tmp/CCcam.log
У CCcam своего веб-интерфейса нет, но есть текстовая статистика. На большинстве Enigma2-ресиверов она доступна через telnet на порт 16000 (команда 4 в CCcam Info Server даёт список карт) либо через файл, который генерирует сам CCcam при запуске с флагом -d. Проще всего смотреть /var/tmp/CCcam.log — там пишутся все попытки подключения, ошибки авторизации и список полученных карт.
Если в логе вы видите строки вида login failed — это не проблема сети, это неверный логин/пароль в C-line. Если строк вообще нет и лог пустой — CCcam либо не стартовал, либо не может достучаться до хоста.
Что означают статусы CONNECTED, ROUTE и CARD
CONNECTED значит только то, что TCP-соединение с сервером установлено — дальше начинается вопрос авторизации и наличия карт. ROUTE в OScam означает, что для конкретного CAID/provider построен маршрут через определённого ридера. CARD — что сервер реально отдаёт данные карты по этому маршруту. Все три статуса зелёные — тогда и только тогда должны открываться каналы этой карты.
Тест открытия канала и замер времени ECM
Откройте канал и посмотрите на ECM time в информационном экране ресивера (обычно кнопка INFO дважды, либо через плагин типа CCcamInfo/OScam webif → ECM history). Норма — 100–400 мс. До 600 мс — терпимо, картинка иногда подвисает на секунду при смене сцены. Выше 700–800 мс — гарантированные фризы, потому что ресивер не успевает получить ключ до истечения текущего.
Именно эта связка — статус соединения плюс ECM time — и есть базовый кардшаринг настройка тест, который стоит гонять при любой жалобе на "не работает". Отдельно скажу: сервер отвечает, но карты нет — это одна ситуация (обычно неверная group или провайдер не отдаёт этот CAID), сервер недоступен — совсем другая (порт, сеть, DNS).
Настройка клиента CCcam: разбор строки C-line
CCcam исторически проще в базовой настройке — вся конфигурация клиента обычно укладывается в одну строку. Но именно из-за этой простоты люди совершают глупые ошибки: лишний пробел, не тот регистр, перенос строки в неправильном месте.
Синтаксис строки: C: host port username password
Классическая C-line выглядит так:
C: example.host 12345 myusername mypassword
Разделитель — ровно один пробел между полями. host может быть доменным именем или IP, port — то, что вам выдал провайдер линии (единого стандартного порта для CCcam не существует, это всегда произвольное число, обычно в диапазоне 10000–30000). Username и password регистрозависимы — это частая причина, почему "вроде всё правильно, а не коннектится": кто-то скопировал логин с большой буквы, хотя провайдер выдал строчными.
Файл CCcam.cfg и его расположение (/var/etc/ или /usr/keys/)
На современных Enigma2-образах конфиг обычно лежит в /var/etc/CCcam.cfg, но на части старых и альтернативных образов используется /usr/keys/CCcam.cfg или вообще /etc/CCcam.cfg с симлинком куда-то ещё. Проверить просто:
find / -iname "CCcam.cfg" 2>/dev/null
Эта команда покажет все файлы с таким именем в системе. Если их два — велика вероятность, что вы правите не тот, а демон читает другой. Классика жанра: человек десять раз переписывает C-line, перезапускает CCcam, ничего не меняется — потому что фактически используется файл по другому пути, а не тот, что открыт в редакторе.
Параметры отладки: DEBUG, SHOW TIMING
Добавьте в начало CCcam.cfg строки:
DEBUG: 1 SHOW TIMING: 1 LOGFILE: /var/tmp/CCcam.log
DEBUG: 1 включает подробный лог, SHOW TIMING добавляет в этот лог время отклика на каждый ECM-запрос — это ровно то, что нужно, чтобы увидеть реальную задержку, а не полагаться на глаз при просмотре канала.
Перезапуск демона и применение изменений
Любые правки CCcam.cfg не применяются на лету. Нужен рестарт демона:
killall -9 CCcam /etc/init.d/softcam start
Либо через панель управления образа (OpenWebif → Softcam Panel → перезапуск). Если после правки поведение не изменилось вообще — в 9 случаях из 10 демон просто не был перезапущен, либо перезапустился, но подхватил старый файл из кэша (актуально для некоторых image с read-only /etc и симлинками на flash).
Настройка OScam: reader, account и протоколы CS357x/CS378x
OScam устроен сложнее CCcam, но именно эта сложность даёт гибкость и, что важнее для диагностики, нормальные логи и webif. Конфигурация разнесена по трём файлам, и понимание того, как они связаны между собой — ключ к тому, чтобы не гадать, где искать проблему.
Секция [reader] в oscam.server: protocol=cccam
Файл /etc/oscam/oscam.server (на части образов — /var/etc/oscam/oscam.server) описывает подключения к внешним серверам. Пример ридера для подключения по протоколу cccam:
[reader] label = server1 protocol = cccam device = example.host,12345 user = myusername password = mypassword cccversion = 2.3.4 group = 1 cccreshare = 1 inactivitytimeout = 30
protocol=cccam говорит OScam, что это протокол CS378x (современный CCcam-протокол). device указывает хост и порт через запятую, а не через пробел, как в CCcam.cfg — это первое, на чём спотыкаются те, кто переходит с CCcam на OScam.
Секция [account] в oscam.user и привязка group
Файл /etc/oscam/oscam.user описывает, кто может подключаться к вашему OScam как клиент — например, ваш собственный ресивер. Пример:
[account] user = clientname pwd = clientpass group = 1 au = 1 uniq = 1
Здесь group = 1 — это то же самое число, что и в reader. Если group не совпадает, картина будет такая: reader подключён, карты в системе есть, но конкретный клиент (ваш ресивер) их не видит, потому что группы не пересекаются. Это, пожалуй, самая частая причина фразы "статус зелёный, а каналов нет" при работе через OScam — и её почти никогда не объясняют в готовых шаблонах конфигов, которые гуляют по форумам.
oscam.conf: включение webif и nanny-параметров
В /etc/oscam/oscam.conf в секции [webif] включается сама панель:
[webif] httpport = 8888 httpuser = admin httppwd = adminpass httprefresh = 10
В секции [global] стоит проверить nanny-параметры — они отвечают за то, как OScam ведёт себя при недоступности карты (переключение на резервный ридер, задержки при повторных попытках). Для стабильной работы важно, чтобы preferlocalcards = 1 был выставлен, если у вас есть и локальная карта, и шаринг — иначе OScam может предпочесть более медленный удалённый источник локальному.
Отличия cccam vs newcamd (порт 15000+) при подключении
Помимо cccam, OScam умеет протокол newcamd (тот же принцип, что и у CS357x — старый, но местами до сих пор используемый протокол). Ридер для newcamd выглядит иначе:
[reader] label = server2 protocol = newcamd device = example.host,15000 key = 0102030405060708091011121314 user = myusername password = mypassword
Порт для newcamd почти всегда начинается с 15000 и выше по негласному соглашению провайдеров, хотя формально это тоже произвольное число. Ключевое отличие — newcamd требует DES-ключ (параметр key), а cccam — нет. Если провайдер линии дал вам ключ из 28 hex-символов, это почти наверняка newcamd, и protocol=cccam с этими данными работать не будет.
Диагностика: почему не открываются каналы и как это чинить
Это раздел, ради которого всё затевалось. Готовые конфиги с форумов дают строку подключения, но не учат читать лог и сопоставлять, что именно происходит с конкретным ECM-запросом. А без этого любая проблема превращается в "переустановил образ и стало работать", хотя причина могла быть в одной цифре.
ECM отправляется, но приходит "rejected" — проблема групп/провайдера
Если в логе OScam вы видите что-то вроде found by reader server1 (rejected), значит запрос дошёл до карты, но она отказалась его расшифровывать. Причины: провайдер линии не держит нужный CAID/provider ID для этого пакета каналов, либо у вас в oscam.user не открыт доступ к этой группе через caid/group-фильтры. Проверяется это через PID-info на ресивере (обычно длинное нажатие кнопки EPG или отдельный плагин) — там видно CAID и Provider ID текущего канала, их нужно сверить с тем, что реально отдаёт линия.
CONNECTED, но нет карт (no cards) — reshare или локальная карта
Статус CONNECTED в webif означает только успешный TCP/авторизационный хендшейк. Если рядом при этом ноль карт — сервер, к которому вы подключились, сам является клиентом чужой линии (reshare-сервер) и в моменте либо потерял связь с источником, либо у него временно нет доступных карт для реэкспорта. Это внешняя проблема, чинить у себя нечего — разве что переключиться на другой ридер, если он есть.
Фризы и высокий ECM time — сеть, hops, перегрузка сервера
Hop — это количество "перепрыжек" от вашего клиента до физической карты. Hop 0-1 — карта у сервера, к которому вы подключены, локальная либо в одном шаге. Hop 2 и выше означает, что сигнал идёт через цепочку reshare-серверов, и каждый добавляет задержку и точку отказа. На практике hop больше 2 почти всегда даёт нестабильную картинку на HD-каналах — там ECM критичнее по времени, чем на SD.
Отдельная история — вечерний прайм-тайм. Канал спокойно открывается днём, а вечером, часов в 20–22, начинает фризить — это почти всегда перегрузка сервера линии, когда одновременно подключено много клиентов. Тут ваша настройка ни при чём, разве что стоит проверить лимит соединений, который вам выделил провайдер (maxconnections или похожий параметр).
Каналы одного пакета идут, другого нет — вопрос caid/provid
Одна линия редко покрывает вообще всё. Если один оператор спутникового вещания у вас открывается, а другой нет при абсолютно одинаковом статусе соединения — значит линия просто не держит CAID этого пакета. Это не баг конфига, это ограничение самой линии, и решается только сменой или добавлением источника с нужным покрытием.
Чтение лога OScam: t: (timeout), r: (rejected), g: (group)
В логе OScam каждая строка ECM-запроса содержит короткие маркеры результата. t: — timeout, карта не ответила за отведённое время (обычно связано с сетью или перегрузкой). r: — rejected, карта ответила отказом (см. выше про CAID/provider). g: — блокировка на уровне group, то есть у клиента формально нет прав запрашивать этот CAID через эту группу. Научиться на глаз отличать эти три буквы — экономит часы гадания, потому что каждая указывает на совершенно разный слой проблемы: сеть, линию или локальную настройку доступа.
И ещё момент, который почти никогда не упоминают: если время на ресивере расходится с реальным больше чем на пару минут, ECM может ломаться даже при технически рабочем соединении, потому что часть протоколов сверяет временные метки. Настройте NTP на ресивере (в OpenWebif это обычно Настройки → Система → Время, синхронизация по сети) — банальная вещь, а отлавливают её иногда сутками.
Как выбрать провайдера линии, не наступив на грабли (без имён)
Называть конкретные сервисы я не буду — рынок такой, что сегодня одни, завтра другие, а критерии оценки остаются одинаковыми независимо от того, кто именно предоставляет линию.
Признаки стабильного сервера: локальные карты, низкий ECM time, аптайм
Хороший источник обычно прямо говорит, что карты у него локальные, а не полученные через десяток reshare-серверов. Заявленный ECM time в описании должен быть в районе 100–300 мс — если цифры не называют вообще, это тревожный звоночек. Аптайм линии тоже стоит спрашивать напрямую: насколько стабильно она держится в течение месяца, бывают ли многочасовые падения.
Красные флаги: только reshare, hop 3+, отсутствие тестового периода
Если по факту подключения вы видите в логе hop 3 и выше — перед вами длинная цепочка перепродажи одной и той же карты, и рано или поздно она даст сбой именно у вас, а не у источника. Второй красный флаг — категорический отказ дать тестовый доступ хотя бы на несколько часов. Нормальный провайдер линии не боится показать, как оно работает у вас на конкретном оборудовании.
Что спрашивать: CAID/provider нужного пакета, лимит соединений
Перед оплатой имеет смысл прямо спросить, какие CAID и provider ID покрывает линия — и сверить со списком того, что вы хотите смотреть. Также стоит уточнить лимит одновременных соединений: если у вас два-три ресивера в доме, а линия рассчитана строго на одно подключение, вы упрётесь в это в первый же вечер.
Почему тестовая линия обязательна перед оплатой
Кардшаринг настройка тест перед оплатой — это не формальность, а единственный способ проверить то, что никакое описание не покажет: как линия ведёт себя именно в ваш прайм-тайм, на вашем канале интернета, с вашим железом. Заявленные 150 мс ECM в рекламном тексте и реальные 150 мс на вашем ресивере в 21:00 буднего дня — совершенно разные вещи. Вставьте тестовую строку в конфиг, оставьте её поработать хотя бы вечер, и уже по результатам принимайте решение.
Как узнать порт для подключения CCcam?
Единого стандартного порта для CCcam не существует — он произвольный и указывается провайдером линии в C-line. Для сопутствующих сервисов есть условные ориентиры: telnet-статистика CCcam Info обычно на 16000, webif OScam — на 8888, newcamd — от 15000 и выше. Но сам порт подключения к линии всегда индивидуален.
Почему статус CONNECTED есть, а каналы не открываются?
CONNECTED означает только успешное TCP-соединение и авторизацию, не более того. Дальше нужно проверять, есть ли нужная карта (CARD в OScam), совпадает ли group клиента и ридера, и отдаёт ли линия вообще CAID/provider ID этого канала. Смотрите лог на предмет rejected и no cards — там будет точный ответ.
Какой нормальный ECM time для кардшаринга?
100–400 мс считается хорошим показателем, до 600 мс ещё терпимо для глаза, выше 700–800 мс уже гарантированные фризы. На время влияет качество сети, число hops до реальной карты, загрузка сервера линии в конкретный момент и общая стабильность источника.
Что лучше для настройки — CCcam или OScam?
OScam гибче: поддерживает несколько протоколов одновременно, даёт полноценный webif и подробные логи для диагностики. CCcam проще на старте — вся настройка клиента укладывается в одну C-line. Если планируете серьёзно разбираться и диагностировать проблемы, OScam удобнее именно для этого.
Как протестировать линию перед оплатой?
Запросите у провайдера тестовый период, вставьте выданную строку в конфиг (C-line для CCcam или reader для OScam), проверьте открытие нужных пакетов каналов именно вечером в прайм-тайм, замерьте ECM time и понаблюдайте за фризами хотя бы пару часов, сверьте CAID/provider с тем, что реально нужно.
Почему после правки конфига ничего не изменилось?
Самая частая причина — не перезапущен демон CCcam или OScam после изменения файла. Вторая по частоте — правился не тот файл, потому что конфиг существует в нескольких путях (например /var/etc и /usr/keys для CCcam.cfg). Третья — синтаксическая ошибка: лишний пробел, неверный регистр логина, случайный перенос строки внутри значения.