CCcam line: формат, настройка и отладка C-line в 2026

Если вы получили от провайдера строку вида C: someserver.tld 12000 user1 pass1 и не понимаете, что с ней делать — эта статья закроет все вопросы. Разберём синтаксис cccam line по полям, пути конфигов на разных системах, команды перезапуска, диагностику и миграцию на OScam.

Что такое CCcam line и зачем она нужна

Определение C-line в протоколе CCcam

C-line — это строка конфигурации исходящего клиентского подключения к CCcam-серверу. Буква C означает именно Client: ваш ресивер или Linux-сервер подключается к удалённому CCcam-серверу, который держит карты или reshare-цепочки. По сути, cccam line — это учётные данные плюс адрес сервера, записанные в одну строку.

Протокол CCcam работает по TCP. Стандартный порт — 12000, хотя провайдеры часто используют другие из диапазона 12000–25000. Соединение устанавливается при старте CCcam-клиента и держится постоянно — это не HTTP-запрос, а persistent TCP-сессия.

Роль C-line в архитектуре клиент-сервер

Ресивер отправляет ECM-запрос (зашифрованный пакет от тюнера) через TCP на сервер. Сервер расшифровывает его с помощью физической карты или принятого reshare и возвращает CW (Control Word). Ресивер декодирует картинку. Всё это происходит за 100–400 мс — если дольше, получаете фриз.

C-line — единственная точка входа в этот процесс. Без неё клиент не знает, куда подключаться и с какими реквизитами.

Отличие C-line от N-line, F-line и L-line

В CCcam.cfg каждая буква в начале строки означает протокол:

• C: — CCcam (проприетарный протокол, TCP, обычно порт 12000+)
• N: — Newcamd (открытый протокол, TCP, обычно 15000+, обязателен DES-ключ)
• F: — Camd 3.x (устаревший протокол, редко используется)
• L: — Radegast (ещё один устаревший протокол)

N-line технически стабильнее — Newcamd открытый и хорошо задокументирован. Но в 2026 большинство провайдеров выдают именно C-line, потому что сервера на CCcam распространены больше.

Где физически хранится C-line на разных системах

Зависит от платформы и системы:

• Enigma2 (OpenATV, OpenPLi, Gemini): /var/etc/CCcam.cfg
• Dreambox DM500/DM800: /usr/keys/CCcam.cfg
• Linux x86/ARM (Raspberry Pi, VPS): /etc/CCcam.cfg
• Vu+ Solo/Duo/Ultimo: /var/etc/CCcam.cfg

Если файла нет — создайте его вручную. CCcam при старте читает конфиг из фиксированного пути в зависимости от сборки.

Синтаксис C-line: разбор каждого параметра

Формат: C: hostname port username password

Базовая структура любой cccam line выглядит так:

C: hostname port username password

Каждое поле обязательно. Разделитель — пробел. Порядок строго фиксирован.

• hostname — DNS-имя или IP-адрес сервера. CCcam резолвит его при подключении. Если сервер отдаёт несколько A-записей (round-robin DNS), CCcam выбирает первую — и если она нерабочая, подключение падает молча.
• port — TCP-порт. Целое число, 1–65535. Чаще всего 12000, но провайдеры используют любые из диапазона.
• username — имя пользователя, выданное провайдером. Case-sensitive: User1 и user1 — разные аккаунты.
• password — пароль. Тоже case-sensitive. Пробелы в пароле — нет, они разбивают строку.

Опциональные параметры: no { DES_KEY }

После пароля можно указать DES-ключ для шифрования трафика:

C: hostname port username password no { 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E }

DES_KEY — 14 байт, записанных как 14 пар hex-символов через пробел (28 символов плюс пробелы). Слово no перед фигурными скобками — часть синтаксиса, не «отключить». Без ключа трафик передаётся в незашифрованном виде (только обфускация на уровне протокола CCcam).

Частая ошибка: скопировать DES-ключ с переносом строки или лишними пробелами. CCcam молча игнорирует такую строку — подключения не будет, в лог ошибки нет. Всегда вставляйте ключ как одну строку.

Параметры wantemus, hop, reshare

Эти параметры задаются глобально в CCcam.cfg, не в самой C-line, но влияют на её поведение:

• WANTEMUS — запрашивать ли EMM с сервера (0 = нет, 1 = да). Большинство серверов EMM не передают, оставьте 0.
• HOP — максимальная глубина reshare-цепочки, которую принимать. HOP 1 = только карты непосредственно у сервера. Значение 3–4 означает, что вы получаете reshare от reshare от reshare — стабильность падает.
• RESHARE — насколько глубоко ваш CCcam-сервер раздаёт карты другим клиентам. Для чистого клиента — 0.

Пример минимальной C-line

C: example.server.tld 12000 myuser mypassword

Этого достаточно для подключения. Шифрование будет на уровне базовой обфускации CCcam.

Пример расширенной C-line с DES и hop

C: example.server.tld 25000 myuser mypassword no { 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E }
HOPS: 2
WANTEMUS: 0

Параметры HOPS и WANTEMUS идут отдельными строками в CCcam.cfg, не внутри C-line.

Отдельный случай — IPv6. Если сервер доступен по IPv6, адрес записывается без скобок: C: 2001:db8::1 12000 user pass. Но поддержка IPv6 в старых сборках CCcam (2.1.x) нестабильна — лучше использовать DNS-имя с AAAA-записью и проверять, что резолвер корректно работает.

Куда вставлять C-line и как применить изменения

Расположение CCcam.cfg на Enigma2, OpenATV, OpenPLi

На всех Enigma2-образах путь одинаковый: /var/etc/CCcam.cfg. Редактировать можно через FTP/SFTP или SSH. Если файла нет — создайте:

touch /var/etc/CCcam.cfg
echo "C: hostname 12000 user pass" >> /var/etc/CCcam.cfg

Расположение CCcam.cfg на Vu+, Dreambox, GigaBlue

На Dreambox DM500/DM800/DM8000 стоит искать /usr/keys/CCcam.cfg. На современных Dreambox с Enigma2 (DM900, DM920) — уже /var/etc/CCcam.cfg. GigaBlue и Vu+ — всегда /var/etc/CCcam.cfg.

Расположение на Linux x86/ARM серверах

На обычном Debian/Ubuntu или Raspberry Pi CCcam ищет конфиг в /etc/CCcam.cfg. Проверьте через:

strings /usr/local/bin/CCcam | grep -i cfg

Это покажет захардкоженные пути в бинарнике вашей версии.

Перезапуск CCcam: команды для systemd, init.d и Enigma2

# Enigma2 (жёсткий рестарт через init):
init 4 && init 3

# init.d (Debian/Ubuntu, старые системы):
/etc/init.d/cccam stop
/etc/init.d/cccam start

# systemd:
systemctl restart cccam

# Проверка статуса:
systemctl status cccam

На Enigma2 команда init 4 && init 3 перезапускает всё GUI включая CCcam-плагин. Если хотите перезапустить только CCcam-плагин, используйте Softcam Manager в меню ресивера.

Проверка применения через CCcam WebInfo (порт 16001)

CCcam запускает встроенный HTTP-сервер на порту 16001. Откройте в браузере:

http://IP_ресивера:16001

Раздел Servers показывает все C-line: статус (connected/not connected), echo-time в миллисекундах, количество карт от сервера. Если строка подключена, но карт 0 — это отдельная проблема (разберём ниже). Если строки нет в списке — CCcam не распарсил cccam line, скорее всего проблема с синтаксисом или кодировкой файла.

Важный момент: CCcam.cfg должен быть сохранён в Unix-формате (LF), не Windows (CRLF). Если редактировали файл на Windows в Notepad — строки могут не парситься. Исправляется командой:

sed -i 's/\r//' /etc/CCcam.cfg

Диагностика проблем с C-line

Сервер показывает offline: проверка DNS, ping, telnet на порт

Первый шаг — убедиться, что hostname вообще резолвится:

nslookup example.server.tld
# или
dig example.server.tld

Если DNS не отвечает — проблема на уровне сети, не C-line. Дальше — проверить доступность порта:

telnet example.server.tld 12000

Если соединение устанавливается (вы видите мусорные байты или пустой ответ) — TCP-уровень работает. Если Connection refused — порт закрыт или сервер упал. Если таймаут — файрвол или сервер недоступен.

Отдельный кейс: round-robin DNS. Сервер резолвится в 3 IP, одно из которых нерабочее. CCcam пробует первый адрес и зависает. Проверьте все A-записи через dig +noall +answer example.server.tld и пингуйте каждый IP.

Ещё один нетривиальный случай: сервер работает за CloudFlare TCP-proxy или требует SNI при TLS-обёртке. Стандартный CCcam не поддерживает TLS или SNI — такое соединение не установится вообще. Если провайдер перевёл инфраструктуру на проксирование — нужен VPN-туннель до сервера.

Connected но 0 карт: проблема с авторизацией или резервом

TCP-соединение установлено, WebInfo показывает "connected", но карт 0. Три причины:

1. Неверная пара username/password — CCcam устанавливает TCP-соединение, но сервер не авторизует аккаунт и не передаёт reshare. В логе сервера будет "authentication failed", но на клиенте это никак не отображается.
2. HOP 0 на сервере — сервер настроен не отдавать карты клиентам (reshare disabled). Редкость, но бывает при неправильной конфигурации.
3. Аккаунт деактивирован или просрочен — подключение принимается, но карт не передаётся.

Проверить: открыть WebInfo → Servers → кликнуть на сервер → посмотреть детали. Если CAID-список пустой — проблема на стороне сервера или авторизации.

Каналы не открываются (чёрный экран при правильном подключении)

Карты есть, подключение есть, но конкретные каналы не декодируются. Смотрите логи ECM-запросов:

tail -f /var/log/cccam.log | grep ECM

Если видите no card for CAID XXXX:YYYY — у сервера нет карты для этого провайдера. Либо карта есть, но с ограничениями по пакетам. В WebInfo → Cards проверьте список CAID и Provider ID — сравните с тем, что требует нужный канал.

Высокий echo-time (>500ms) и фризы

Echo-time в WebInfo — это Round-Trip Time ECM-запроса. Нормально: 50–200 мс. Критично: >500 мс, вы будете видеть фризы при переключении каналов или периодические паузы в картинке.

Причины высокого echo-time: географическая удалённость сервера (сервер в Азии, вы в Европе — легко 300+ мс только на RTT), перегрузка сервера в прайм-тайм, плохой транзитный канал у провайдера. Решение: попросить сервер в ближайшем к вам регионе или использовать VPN с выходом ближе к серверу.

Частые реконнекты каждые 30–60 секунд

Видите в логах бесконечный цикл disconnect/reconnect? Скорее всего дело в NAT с агрессивным connection tracking. Домашний роутер или ISP-NAT закрывает idle TCP-сессии через 30–60 секунд. CCcam не отправляет keepalive по умолчанию — сессия рвётся, и клиент переподключается.

Решение на уровне роутера: увеличить tcp timeout в conntrack до 300+ секунд. На Linux-клиенте можно включить TCP keepalive через sysctl:

net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 6

Конфликт нескольких C-line на одного провайдера

Две C-line на один hostname:port с разными username — нормально, CCcam управляет ими независимо. Проблема возникает когда один и тот же аккаунт (username/password) прописан в нескольких C-line или на нескольких ресиверах одновременно. Сервер видит два подключения от одного аккаунта и либо дропает старое, либо блокирует оба. В логе: бесконечные реконнекты без стабильного состояния.

Безопасность и приватность при использовании C-line

Пароли в открытом виде в CCcam.cfg

CCcam.cfg хранит username и password в открытом виде (plaintext). Никакого хэширования, никакого шифрования на диске. Если кто-то получит доступ к файлу — учётные данные скомпрометированы.

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

chmod 600 /etc/CCcam.cfg
chown root:root /etc/CCcam.cfg

На Enigma2: chmod 600 /var/etc/CCcam.cfg. Это стандартная Unix-гигиена, но о ней почему-то забывают.

Шифрование трафика через DES

DES-ключ в C-line шифрует тело трафика между клиентом и сервером. Но DES в 2026 — слабое шифрование, 56-битный ключ. Реальная защита здесь минимальна. DES скорее защищает от пассивного сниффинга нетехнического ISP, но не от целенаправленного анализа трафика.

Важно: DES шифрует трафик, но не аутентификацию в протоколе CCcam. Handshake при подключении защищён по-другому, и перехват рукопожатия теоретически позволяет извлечь учётные данные.

Запуск CCcam через VPN-туннель

Если ISP блокирует CCcam-трафик или вы не хотите, чтобы провайдер видел факт подключения к cardsharing-серверу — VPN-туннель решает обе проблемы. Поднимите WireGuard или OpenVPN на том же хосте, где работает CCcam, направьте трафик к серверу через туннель.

Простой вариант для Raspberry Pi или Linux-клиента — WireGuard с маршрутизацией только трафика на IP сервера через туннель (split tunneling). Так основной трафик не идёт через VPN, только CCcam-соединение.

Права доступа на файл CCcam.cfg (chmod 600)

Повторим отдельно, потому что это важно: chmod 600 на конфиг — не опция, а обязательство. На многопользовательских Linux-системах (VPS с несколькими пользователями) файл с правами 644 виден любому залогинившемуся пользователю.

Логи и утечка данных провайдеру

CCcam-сервер, к которому вы подключаетесь, видит: ваш IP-адрес, время подключений и отключений, все CAID-запросы (какие именно каналы вы смотрите), количество ECM-запросов в секунду. Это нормально и неизбежно — протокол не анонимный. Но понимать, что провайдер имеет полный лог вашей активности, стоит.

Критерии выбора надёжного CCcam-сервера

Стабильность uptime и заявленный SLA

Нормальный uptime для серьёзного сервера — 99%+. Это легко проверяется: возьмите тестовый период, запустите мониторинг (простой Bash-скрипт с ping или telnet каждые 5 минут в cron) и посмотрите реальные цифры за 72 часа. Заявления без доказательств не считаются.

Локальные карты vs reshare-цепочки

Сервер с локальными картами (физические смарт-карты в CAM-модуле) даёт ECM-ответ за 50–150 мс. Reshare hop 3–4 — это ECM идёт через цепочку из четырёх серверов, каждый добавляет свою задержку. Итоговый echo-time легко уходит за 400 мс, и вы получаете фризы в прайм-тайм.

Как проверить: после подключения в WebInfo → Cards посмотрите поле Hop для каждой карты. Hop 0 = локальная карта на этом сервере, Hop 1 = карта на сервере-родителе, и т.д.

Поддерживаемые CAID и пакеты

Перед оплатой уточните конкретные CAID и Provider ID, которые поддерживаются. "Тысячи каналов" без списка CAID — маркетинговая ерунда. Вам нужны конкретные цифры: CAID 0x0D97 (Viasat Nordic), CAID 0x1830 (Sky DE), и т.д. — зависит от вашего региона и интереса.

Тестовый период и возврат средств

Нормальный провайдер даёт тестовый период минимум 24–48 часов без оплаты. Это стандарт. Если тестового доступа нет вообще — красный флаг. Возврат средств за неработающий сервис — тоже признак серьёзного отношения к клиентам.

Техподдержка и отзывчивость

Минимум — тикетная система или Telegram. Время ответа на технический вопрос должно быть в пределах нескольких часов, не дней. Протестируйте до оплаты: задайте технический вопрос (например, какие CAID поддерживаются) и посмотрите на качество и скорость ответа.

Региональные сервера и echo-time

Физическое расстояние имеет значение. Сервер в той же стране или соседней даст echo-time 30–80 мс. Сервер на другом континенте — 200–500 мс. При прочих равных выбирайте провайдера с серверами в вашем регионе. Признаки ненадёжного провайдера: только криптооплата без альтернатив, обещание "всех пакетов мира" без конкретики по CAID, нет тестового периода.

Миграция с CCcam на OScam: эквивалент C-line

OScam reader-секция для CCcam-протокола

В OScam нет понятия "C-line" — вместо этого используется секция [reader] в файле /etc/oscam/oscam.server. Вот как выглядит эквивалент C-line:

[reader]
label         = myserver
protocol      = cccam
device        = example.server.tld,12000
user          = myuser
password      = mypassword
cccversion    = 2.3.0
cccmaxhops    = 2
group         = 1
reconnecttimeout = 30

Сопоставление параметров: C-line → oscam.server

CCcam C-line	OScam oscam.server
hostname	device = hostname,port
port	device = hostname,port
username	user = username
password	password = password
no { DES_KEY }	cccdeskey = 01 02 03 ... 0E
HOPS: N	cccmaxhops = N
WANTEMUS: 1	emmrequest = 1

Преимущества OScam над CCcam

OScam активно развивается в 2026, CCcam — нет. Последняя стабильная версия CCcam (2.3.x) не обновлялась годами. OScam поддерживает новые CAID, которые CCcam не умеет обрабатывать, имеет значительно лучшее логирование (видно каждый ECM-запрос с CAID, SID, временем ответа), нативный EMM-management для обновления ключей карт и гибкую настройку приоритетов между reader'ами.

Веб-интерфейс OScam на порту 8888 даёт несравнимо больше диагностической информации, чем CCcam WebInfo.

Когда оставаться на CCcam

Если у вас старый ресивер (DM500, ресиверы на MIPS с 64 МБ RAM) — OScam может не запуститься или работать нестабильно. В этом случае CCcam 2.3.x — разумный выбор. Также если провайдер явно выдаёт cccam line и не тестировался с OScam — начните с CCcam, убедитесь что всё работает, потом мигрируйте.