CCcam lines: настройка и подключение C-line на ресивере

Если вы впервые держите в руках строку вида C: my.server.net 12000 user123 pass456 и не понимаете, куда её вставить и почему ничего не работает — этот материал закроет все вопросы. Разберём cccam lines от формата до диагностики реальных проблем: фризов, отвалов и каналов, которые упорно не открываются.

Что такое CCcam line и как читать формат C-line

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

Структура строки C: host port user pass

Формат выглядит так:

C: my.server.net 12000 user123 pass456

Разбиваем по полям:

• C: — префикс, обозначает клиентское подключение (Client line). Пишется с большой буквы, двоеточие обязательно.
• my.server.net — адрес сервера. Может быть DNS-именем или IPv4 напрямую (например, 91.234.56.78). DNS предпочтительнее, если у сервера динамический IP.
• 12000 — TCP-порт. Типичный диапазон — от 10000 до 30000, но встречаются и нестандартные значения. Порт задаётся провайдером линии.
• user123 — логин доступа.
• pass456 — пароль. Разделители — пробелы, никаких запятых или точек с запятой.

Поля чувствительны к регистру. User123 и user123 — разные логины. Это банальная причина половины нерабочих подключений, которые я видел.

Чем C-line отличается от N-line и F-line

Путаница между типами строк встречается постоянно, поэтому фиксируем чётко:

Префикс	Протокол	Назначение
C:	CCcam	Ваш ресивер подключается к CCcam-серверу как клиент
N:	Newcamd	Подключение по протоколу Newcamd (другой формат, другой порт)
F:	CCcam	Раздаёт доступ вашим клиентам — вы сами выступаете сервером

N-line не вставляется в CCcam.cfg как C-line — у неё другой формат и другой раздел конфига. Если вам дали строку с префиксом N:, её нужно добавлять в секцию Newcamd или использовать OScam с protocol = newcamd.

Откуда берётся line и что в ней передаётся

По C-line ресивер не скачивает ключи насовсем. Каждый раз при смене пакета каналов он отправляет ECM-запрос на сервер, сервер расшифровывает его с помощью физической смарт-карты и возвращает CW (Control Word). Задержка этого обмена — и есть ECM time, главная метрика качества подключения.

Важно: через line не передаётся сама карта, только ответы на конкретные запросы. Именно поэтому при высоком ECM time каналы начинают фризить — CW не успевает прийти до смены периода шифрования.

Настройка C-line в CCcam.cfg и в OScam

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

Путь к файлу /var/etc/CCcam.cfg и синтаксис

На большинстве образов (OpenPLi, OpenATV, OpenVision) файл конфига лежит по пути /var/etc/CCcam.cfg. На старых образах Gemini и некоторых клонах встречается /usr/keys/CCcam.cfg. Проверить просто:

find / -name "CCcam.cfg" 2>/dev/null

Добавление C-line в конфиг выглядит так — просто вставляете строку в файл:

# CCcam client lines
C: my.server.net 12000 user123 pass456
C: backup.server.net 15000 user123 pass456

Строки читаются сверху вниз. Несколько C-lines — нормально, CCcam попробует их по порядку. После правки файла нужен перезапуск демона:

# На системах с init.d:
/etc/init.d/CCcam restart

# На systemd (редко на ресиверах, но бывает):
systemctl restart CCcam

Никакого перезапуска самого ресивера не нужно — только демона.

Подключение C-line через OScam (oscam.server, протокол cccam)

OScam — более гибкая альтернатива CCcam, и многие опытные пользователи переходят на него именно ради тонкой настройки. C-line в OScam прописывается в файле /etc/oscam/oscam.server или /usr/local/etc/oscam.server:

[reader]
label         = myserver
protocol      = cccam
device        = my.server.net,12000
user          = user123
password      = pass456
cccversion    = 2.3.2
cccmaxhops    = 2
group         = 1
cccwantemu    = 0

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

После правки oscam.server перезапускаем:

/etc/init.d/oscam restart
# или через веб-интерфейс OScam на порту 8888

Параметры CCcam version и nodeid

Параметр cccversion в OScam или CCCAM VERSION в CCcam.cfg влияет на то, как сервер идентифицирует клиента. Если сервер настроен на приём только клиентов версии 2.3.0, а у вас прописана 2.3.2 — подключение может быть отклонено или работать нестабильно.

Параметр nodeid (или cccnodeid в OScam) — уникальный идентификатор клиента в сети. Если у вас несколько ресиверов с одинаковым nodeid, сервер может блокировать все подключения, кроме первого. В OScam nodeid генерируется автоматически, но его можно задать вручную в oscam.conf в секции [global].

Порты, firewall и проверка соединения

CCcam работает исключительно по TCP. UDP не используется. Это означает, что если между вашим ресивером и сервером стоит NAT или firewall — порт из C-line должен быть открыт и проброшен.

Какие порты открыть на роутере и сервере

На стороне клиента (ваш ресивер) пробрасывать порты не нужно — вы инициируете исходящее соединение. Нужно только убедиться, что исходящий трафик на нужный TCP-порт не блокируется вашим роутером или провайдером.

Ситуация с CGNAT и мобильным интернетом — отдельная боль. Если ресивер подключён через 4G/5G модем или роутер с CGNAT, исходящие соединения работают нормально. Проблема возникает только если вы сами хотите поднять сервер — входящие соединения через CGNAT без VPN или туннеля не пробросить.

Веб-интерфейс CCcam слушает на порту 16001 по умолчанию. Его можно изменить в CCcam.cfg:

WEBINFO LISTEN PORT : 16001

Проверка доступности порта (telnet, nc, ping)

Прежде чем копаться в конфигах — проверяем, доступен ли сервер вообще:

# Пинг хоста (проверяем только доступность IP, не порта):
ping -c 4 my.server.net

# Проверка TCP-порта через telnet:
telnet my.server.net 12000

# Через nc (netcat) — чище:
nc -zv my.server.net 12000 -w 5

Если telnet подвисает без вывода — порт закрыт или фильтруется. Если сразу выдаёт Connection refused — порт не слушается на сервере. Если соединение установилось и выдало несколько нечитаемых байт — CCcam/OScam на сервере работает и ждёт handshake.

Статус подключения в веб-интерфейсе CCcam (порт 16001)

Открываем в браузере http://IP-ресивера:16001. Раздел Servers показывает статус каждой C-line: Connected/Disconnected, количество карт, поддерживаемые CAID. Раздел ECM показывает время ответа в реальном времени.

Если в колонке CAID у сервера пусто или показывает CAID, которых нет у нужного вам пакета — каналы не откроются, даже при статусе Connected.

Диагностика проблем: нет каналов, FREEZE, отвал line

Это самая полезная часть. Большинство гайдов по cccam lines останавливаются на формате строки и говорят «вставьте и перезапустите». Что делать, когда это не работает — объясняет уже единицы.

Line подключается, но каналы не открываются

Статус Connected в веб-интерфейсе, но при переключении на зашифрованный канал — чёрный экран. Причины:

• Несовпадение CAID. Источник предоставляет карту с CAID 0x0500 (Viaccess), а ваш канал требует CAID 0x0B00 (Conax). Смотрим список CAID в разделе Servers и сравниваем с тем, что требует канал.
• Provider ID. Даже при совпадении CAID сервер может не иметь доступа к конкретному провайдеру или пакету внутри системы шифрования. Это видно в детальном ECM-логе.
• Несовпадение версии CCcam. Сервер ожидает клиент версии 2.3.0, у вас прописана 2.3.2 или наоборот — подключение есть, но карты не раздаются.
• BISS и PowerVu. Каналы с этими системами шифрования через обычную C-line не открываются вообще — им нужен отдельный SoftCAM с ключами или специальная поддержка на стороне сервера. Если вам дали линию и сказали, что она работает с BISS — уточняйте детали протокола.

Лог для диагностики:

tail -f /tmp/CCcam.log
# или для OScam:
tail -f /tmp/oscam.log

В логах ищем строки с ECM и статусами found / not found.

Фриз и заикания: ECM time и кэш

Фриз — это когда канал работает, но картинка периодически замирает на 1-3 секунды. Классический симптом высокого ECM time.

Хорошее значение ECM time — стабильно до 300-400 мс. При 500-700 мс уже начинаются периодические заикания. Выше 800 мс — фризы регулярные, смотреть невозможно.

Причины высокого ECM time:

• Физическая удалённость сервера (пинг 150+ мс)
• Длинная цепочка решары: ваш сервер → промежуточный решар → ещё один решар → карта. Каждый hop добавляет 50-200 мс.
• Перегрузка источника в прайм-тайм
• Каналы с частой сменой ключей (некоторые спутниковые пакеты меняют CW каждые 5-10 секунд вместо стандартных 10)

В OScam можно настроить кэш ECM-ответов через cachex, что снижает фактическое количество запросов к серверу при переключении каналов.

Частые отключения и причины нестабильности

Если линия каждые несколько часов отваливается и переподключается — смотрим на следующее:

• Динамический IP у клиента. Если сервер привязал вашу линию к IP-адресу, а провайдер сменил его — подключение отвалится до следующей переаутентификации. Решение: VPN с постоянным IP или уточнение у источника, используется ли привязка по IP.
• Лимит подключений. Большинство источников ограничивают количество одновременных сессий на одну линию. Подключили два ресивера с одной C-line — один из них будет регулярно выбиваться.
• Блокировка по nodeid. Если nodeid совпадает с другим клиентом сервера, он может блокировать одного из них.
• Таймаут keepalive. CCcam и OScam периодически отправляют keepalive-пакеты. Если сеть нестабильна и пакет не доходит вовремя — сервер закрывает соединение. В OScam параметр reconnecttimeout в oscam.server регулирует поведение при потере связи.

Как оценить качество CCcam line при выборе источника

Когда выбираете источник cccam lines, маркетинговые описания можно игнорировать. Смотрим на конкретные технические характеристики.

Объективные критерии: ECM time, аптайм, стабильность

Нормальный источник честно сообщает следующее:

• Среднее ECM time для конкретных пакетов (должно быть до 400 мс)
• Тип карт: локальные (физические карты на сервере) или решары. Локальные всегда лучше — меньше hops, ниже ECM time
• Поддерживаемые CAID и список конкретных пакетов
• Лимит одновременных подключений на линию
• Заявленный аптайм (реалистично — 98-99% в месяц; 100% — это ложь)

Параметр cccmaxhops в OScam (или CCCAM HOP в CCcam.cfg) позволяет ограничить глубину решары, которую вы принимаете. Значение 1 означает только локальные карты источника, 2 — допускает один уровень решары. Чем меньше, тем стабильнее.

Что проверять в тестовый период

Если источник предлагает тестовый доступ (обычно 24-48 часов) — используйте его правильно:

• Переключайтесь между каналами быстро и фиксируйте время отклика
• Тестируйте в прайм-тайм (вечер по московскому времени) — именно тогда нагрузка на сервер максимальная
• Проверяйте конкретные каналы из нужных вам пакетов, а не рандомные
• Смотрите на ECM time в веб-интерфейсе или логах OScam, а не только на картинку
• Дождитесь как минимум одной смены ключей пакета — стабильные источники переживают её без фризов

Технические признаки ненадёжного источника

Плохой источник легко вычислить технически:

• ECM time скачет от 200 мс до 2000 мс в течение часа — признак перегрузки или нестабильной сети
• В разделе Servers в веб-интерфейсе видно много hops (3-4 уровня) — вы последний в цепочке решары
• Частые реконнекты в логах даже при стабильной сети на вашей стороне
• Разные CAID пропадают из списка и появляются — нестабильный пул карт
• При смене ключей пакета линия «висит» 30-60 секунд — источник медленно обновляет CW

Конфликт нескольких C-lines с одинаковым CAID — отдельная история. Если у вас в конфиге две линии, обе декларируют CAID 0x0500, CCcam будет отправлять ECM-запрос первой по списку и только при таймауте переключится на вторую. В OScam это поведение тонко настраивается через приоритеты групп ридеров в oscam.user — параметр group и fallbacktimeout.