CCcam конфигурация: полное руководство по настройке 2026

Если вы ищете рабочий cccam configuration guide — вы на нужной странице. Я прошёл через все типичные грабли: демон не стартует, карта есть но каналы не открываются, пиры подключаются и тут же отваливаются. Здесь разберём всё — от структуры файлов до диагностики через tcpdump, без воды и без копипасты с форумов.

Этот cccam configuration guide рассчитан на тех, кто уже установил CCcam на Linux или Enigma2-ресивер и готов разобраться в деталях. Не для тех, кто только ищет готовый конфиг — скопировал и забыл.

Структура конфигурации CCcam и расположение файлов

Где лежит CCcam.cfg на разных платформах

Путь к главному конфигу зависит от платформы. На Enigma2-ресиверах (VU+, Dreambox, Zgemma) это /var/etc/CCcam.cfg. На сборках с Gemini или OpenPLi некоторые пакеты кладут его в /usr/keys/CCcam.cfg. На x86 Linux — чаще всего /etc/CCcam.cfg.

Если не знаете где у вас — проверяйте так:

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

Это найдёт файл где бы он ни лежал. Занимает секунды.

Назначение CCcam.cfg, CCcam.providers, CCcam.channelinfo

CCcam.cfg — главный файл. Здесь F-lines, C-lines и все основные параметры демона. Без него CCcam не стартует.

CCcam.providers — таблица провайдеров: соответствие CAID → имя оператора. Используется только для отображения в веб-интерфейсе и логах. Можно не трогать.

CCcam.channelinfo — список каналов с их SID и CAID. Тоже только для удобства отображения. Функционально не влияет на работу шаринга.

Права доступа и владелец файлов

CCcam.cfg должен читаться только root. Это не паранойя — в файле лежат логины и пароли ваших пиров в открытом виде.

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

Если демон запускается от другого пользователя (редко, но бывает) — chown cccam:cccam и chmod 640.

Перезапуск демона после правок

CCcam не поддерживает reload — конфиг читается только при старте. После каждой правки нужен полный рестарт.

На Enigma2:

killall -15 CCcam && sleep 2 && /usr/bin/CCcam -d

На systemd (x86 Linux):

systemctl restart cccam

Через init.d:

/etc/init.d/cccam restart

Флаг -15 в killall — это SIGTERM, даёт демону время закрыть соединения чисто. Не используйте -9 без крайней необходимости.

Базовые параметры CCcam.cfg — что включить и зачем

Вот минимальный рабочий CCcam.cfg с объяснением каждой строки:

SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
WEBINFO USER : admin
WEBINFO PASSWORD : StrongPass2026!
ALLOW TELNETINFO : 0
DEBUG : 0
EXTRA DEBUG : 0
SHOW TIMING : 0
ECM INFO : 1
NEWCAMD TIMEOUT : 5000
OSCAM REINIT TIMEOUT : 900
CACHEEX TIMEOUT : 5000

SERVER LISTEN PORT — выбор и проброс порта

По умолчанию CCcam слушает на порту 12000. Можно поставить любой TCP-порт выше 1024. Порт 12000 — неофициальный стандарт де-факто, большинство пиров ожидают именно его.

Если у вас несколько инстансов CCcam (редко, но бывает) — каждому нужен свой порт. Пример: 12000 для основного, 12001 для второго.

WEBINFO LISTEN PORT и логин/пароль для веб-интерфейса

Веб-интерфейс открывается по адресу http://IP:16001. Там видно подключённых пиров, карты, ECM time. Очень полезно при диагностике.

Важный момент: WEBINFO LISTEN PORT и SERVER LISTEN PORT не должны совпадать. Если поставить оба на 12000 — демон стартует, но веб-интерфейс не ответит. Это одна из самых частых ошибок начинающих.

Пароль в WEBINFO PASSWORD ставьте нормальный. Если интерфейс торчит в интернет — его найдут сканеры за часы.

ALLOW TELNETINFO и безопасность доступа

Telnet-интерфейс (порт 16000 по умолчанию) — это отладочный инструмент. В продакшне его нужно отключить: ALLOW TELNETINFO : 0. Он передаёт данные в открытом виде.

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

DEBUG, EXTRA DEBUG, SHOW TIMING — режимы логирования

Это та настройка, которую все включают при проблемах и забывают выключить. DEBUG : 1 генерирует несколько мегабайт лога в час при активном шаринге. На ресивере с SD-картой это убивает карту памяти за недели.

В продакшне — всё на 0. При отладке конкретной проблемы — включить, собрать лог, выключить.

SHOW TIMING : 1 добавляет в лог время обработки каждого ECM. Полезно когда нужно понять где именно тормоза — на вашей стороне или у пира.

OSCAM REINIT TIMEOUT, NEWCAMD TIMEOUT — таймауты

NEWCAMD TIMEOUT : 5000 — таймаут ответа от newcamd-пира в миллисекундах. Для спутниковых ресиверов с нестабильным интернетом можно поднять до 7000-8000.

OSCAM REINIT TIMEOUT : 900 — через сколько секунд переинициализировать соединение с OScam. Значение 900 (15 минут) нормальное для большинства случаев.

F-line: настройка приёма шар от пиров

Синтаксис F-line: F: username password hops downhops

F-line определяет кто может подключиться к вашему CCcam-серверу. Вы — сервер, они — клиенты.

F: username1 Passw0rd!2026 1 0
F: username2 AnotherPass 2 1

Разбор: F: [логин] [пароль] [hops] [downhops].

Что такое hops, uphops и downhops — пошагово

hops — сколько уровней reshare клиент может видеть от вас. Hop 0 = только ваши локальные карты. Hop 1 = ваши карты + карты ваших пиров. Hop 2 = и пиры пиров тоже.

downhops — сколько hop-уровней клиент может пересдавать дальше. Если поставить 0 — клиент видит ваши карты но не может их reshare своим клиентам.

Для надёжной схемы рекомендую: F: user pass 1 0. Клиент видит прямые карты, пересдавать не может.

Параметры reshare и emm

После downhops можно добавить параметры reshare и emm:

F: username1 password 1 0 { reshare: 0, emm: 0 }

reshare: 0 — отключить пересдачу карт для этого пользователя независимо от downhops.

emm: 1 — разрешить этому клиенту слать EMM (Entitlement Management Messages) через ваш сервер. Это опасно: если провайдер карты отслеживает EMM — карта может быть забанена. По умолчанию держите emm: 0.

Несколько F-line от разных провайдеров

F-lines для разных пользователей просто перечисляются одна за другой:

F: peer1 Pass1!2026 1 0
F: peer2 Pass2!2026 1 0
F: testuser TestPass123 0 0

Пользователь testuser с hop 0 видит только локальные карты — удобно для тестирования не открывая полный доступ.

Типовые ошибки: лишние пробелы, неверный регистр

CCcam очень чувствителен к синтаксису F-line. Лишний пробел в конце строки — и демон не распарсит строку. Регистр логина и пароля — регистрозависимый. "User1" и "user1" — разные аккаунты.

Ещё одна ловушка: если редактировали CCcam.cfg в Windows Notepad или другом редакторе с UTF-8 BOM — демон молча падает при старте. Всегда редактируйте в nano или vi прямо на ресивере.

C-line: подключение к удалённым серверам как клиент

Синтаксис C-line: C: host port username password

C-line — это противоположность F-line. Здесь вы клиент, подключаетесь к чужому серверу.

C: server.example.tld 12000 myuser mypassword
C: backup.example2.tld 12000 myuser2 mypass2

Синтаксис: C: [хост или IP] [порт] [логин] [пароль].

Параметр no { } и фильтрация CAID/Provider ID

Если сервер пира отдаёт много карт которые вам не нужны — можно отфильтровать лишние CAID. Это снижает шум в логах и нагрузку на сеть:

C: server.example.tld 12000 myuser mypassword
no {
  0500 : 000000
  0604 : 000000
}

CAID 0500 — Viacess, 0604 — Irdeto. Если вы смотрите только Nagravision (CAID 1801) — всё остальное можно заблокировать.

Несколько C-line и приоритет (order of cards)

CCcam пробует C-lines сверху вниз. Первая C-line в файле имеет наивысший приоритет. Если один и тот же CAID доступен через несколько C-lines — используется та, что выше.

Так что если у вас есть основной пир и резервный — основной ставьте первым.

DNS vs IP — какие подводные камни

DNS-имя в C-line резолвится только при старте CCcam. Если пир сменил IP — CCcam продолжает стучаться по старому адресу до следующего рестарта. Автоматического failover нет.

Именно поэтому пиры с динамическим IP должны использовать DDNS-имена — и вы тоже должны рестартовать CCcam когда знаете что пир сменил адрес. Это ручная операция.

Проверка статуса: CCcam -s и веб-интерфейс

Быстрая проверка что C-line подключилась:

CCcam -s

Или через telnet (если включён):

telnet localhost 16001

Веб-интерфейс по адресу http://IP:16001 показывает статус каждой C-line: подключена, сколько карт, ECM time. Если статус "not connected" — проблема в сети или учётных данных.

Сетевые требования: порты, NAT, firewall

Какой порт открыть для входящих пиров (по умолчанию 12000)

CCcam использует TCP. Не UDP — это частая ошибка при настройке проброса портов. Если открыть UDP 12000 вместо TCP 12000 — пиры не подключатся, и вы долго будете чесать затылок.

Порт по умолчанию — 12000 (задаётся параметром SERVER LISTEN PORT). Можно поменять на любой, но пирам нужно сообщать актуальный порт.

Port forwarding на роутере: TCP, не UDP

В интерфейсе роутера: External Port 12000 → Internal IP вашего ресивера → Internal Port 12000 → Protocol: TCP.

Если за двойным NAT (CGNAT от провайдера) — порт пробросить невозможно в принципе. CGNAT прячет ваш IP за общим провайдерским адресом. В этом случае единственные варианты: VPS с туннелем (WireGuard или SSH tunnel), или подключаться только как клиент (только C-lines, без F-lines).

Динамический IP и DDNS — как пиры находят вас

Если у вас динамический IP — нужен DDNS-сервис. Клиент (небольшая программа или встроенный в роутер) обновляет DNS-запись при смене IP. Пиры подключаются по имени типа yourhostname.duckdns.org вместо сырого IP.

Большинство современных роутеров (TP-Link, Asus, Mikrotik) имеют встроенного DDNS-клиента. Настраивается в веб-интерфейсе роутера.

iptables/ufw — пример правила для CCcam порта

На Linux x86 с iptables:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j ACCEPT

С ufw:

ufw allow 12000/tcp
ufw allow 16001/tcp

Веб-интерфейс (16001) лучше открывать только для конкретного IP, а не для всего интернета:

ufw allow from 192.168.1.0/24 to any port 16001 proto tcp

MTU и фрагментация при PPPoE

PPPoE соединения имеют MTU 1492 вместо стандартных 1500. ECM-пакеты CCcam иногда фрагментируются, что приводит к эффекту "каналы открываются через раз". Решение — установить MSS clamp:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Или вручную задать MTU на интерфейсе PPPoE: ip link set ppp0 mtu 1492.

Совместимость CCcam с OScam: cs378x и newcamd мосты

Когда нужен мост CCcam ↔ OScam

OScam сейчас активно развивается, CCcam — нет. Многие переходят на OScam для управления физическими смарт-картами, но сохраняют CCcam-совместимость для старых пиров. Решение: OScam и CCcam работают одновременно на разных портах, соединённые через локальный мост.

Настройка cs378x reader в oscam.server для приёма из CCcam

В файле /etc/oscam/oscam.server добавляем reader для CCcam-протокола:

[reader]
label         = cccam_main
protocol      = cccam
device        = localhost,12000
user          = oscam_user
password      = oscam_pass
cccversion    = 2.3.0
cccmaxhops    = 2
reconnecttimeout = 15

Здесь oscam_user / oscam_pass — это F-line которую вы прописали в CCcam.cfg. OScam подключается к CCcam как обычный клиент.

Настройка newcamd reader: ключ DES, CAID

Если нужен newcamd-мост (для совместимости со старым оборудованием):

[reader]
label        = newcamd_bridge
protocol     = newcamd
device       = localhost,15050
user         = nm_user
password     = nm_pass
key          = 0102030405060708091011121314
caid         = 1801

DES-ключ (14 байт в hex) должен совпадать с тем что прописан в CCcam.cfg на стороне newcamd-сервера.

Отдача CCcam-шар через OScam как cccam-протокол

Обратная схема: OScam управляет физической картой, CCcam получает от него шары. В oscam.conf настраиваем cs378x-сервис:

[cs378x]
port = 12010

Затем в CCcam.cfg добавляем C-line на этот порт:

C: localhost 12010 cccam_from_oscam password

Логи: какие сообщения смотреть в oscam.log

Ключевые строки в oscam.log при диагностике моста:

  • reader cccam_main: card added — соединение установлено, карта получена
  • reader cccam_main: connection established — мост поднят
  • no card in reader — CCcam не отдаёт карту (проблема на стороне CCcam)
  • rate-limit, ecm dropped — слишком много ECM запросов, провайдер карты блокирует

Rate-limit — распространённая проблема при работе через reshare цепочки. Решение: ограничить количество одновременных запросов в oscam.conf параметром maxecmcount.

Отладка и решение типовых проблем

Карта есть, но каналы не открываются — алгоритм проверки

Пошаговый алгоритм когда всё выглядит нормально но каналы не идут:

  1. Проверить что F-line подключилась: CCcam -s или веб-интерфейс → список клиентов
  2. Убедиться что карта видна: в веб-интерфейсе раздел "cards" — CAID должен быть там
  3. CAID канала совпадает с CAID карты? Например Nagravision (1801) vs Viaccess (0500) — разные карты
  4. ECM time в норме? Если ecm avg > 1500ms — таймаут, каналы будут зависать
  5. Включить DEBUG : 1, переключить канал, смотреть лог

Status 'CARD NOT FOUND' — что значит и как искать

"CARD NOT FOUND" в логе означает что CCcam не нашёл карту с нужным CAID для пришедшего ECM. Причины: карта ещё не подгрузилась после рестарта (подождите 30 секунд), или CAID в C-line не совпадает с тем что отдаёт пир.

Проверяем CAID карты через веб-интерфейс или CCcam -s. Сравниваем с CAID нужного канала (можно посмотреть в настройках CI или через Enigma2 channel info).

FREEZE при переключении каналов: ECM timeout

Зависание 3-5 секунд при переключении — это высокий ECM time. Норма до 500ms, плохо от 1500ms, критично от 3000ms.

Причины: hop > 1 (длинная цепочка reshare), высокая сетевая латентность, или перегруженная карта на стороне пира. Смотреть ecm avg в веб-интерфейсе. Решение — найти пира с hop 1 и низкой латентностью.

Логи: tail -f /tmp/CCcam.log и расшифровка строк

tail -f /tmp/CCcam.log

Ключевые строки лога:

  • card added [CAID:xxxx/IDENT:xxxxxx] — карта от пира получена
  • card removed — пир отключился или отозвал карту
  • ecm too late — ECM пришёл позже таймаута, канал не открылся
  • login failed: invalid password — неверный пароль в F-line клиента
  • connected to [server] — C-line успешно подключилась

Wireshark на CCcam порту — что искать в дампе

Снять дамп для анализа в Wireshark:

tcpdump -i any -w /tmp/cccam.pcap port 12000

Дамп покажет: устанавливается ли TCP-соединение (SYN/SYN-ACK), идут ли данные после хендшейка. Если TCP SYN есть а SYN-ACK нет — проблема в firewall или port forwarding. Если соединение устанавливается но данные не идут — проблема аутентификации (неверный логин/пароль).

Безопасность конфигурации

Сложные пароли в F-line и C-line

Слабый пароль в F-line — это раздача вашей карты всем желающим. Сканеры перебирают стандартные пароли (pass, 12345, cccam) за считанные часы. Минимальные требования: 12+ символов, цифры, заглавные буквы, спецсимволы.

Пример нормального пароля: Xk7!mP2vQr9#. Да, неудобно вводить вручную. Зато карту не угонят.

Отключение TELNETINFO в проде

Повторю отдельно потому что это часто игнорируют. Telnet передаёт всё в открытом виде. Если ALLOW TELNETINFO : 1 в продакшн конфиге — любой кто в вашей сети или на пути между вами и пиром может перехватить данные. Держите выключенным.

fail2ban правило для CCcam порта

Создаём фильтр /etc/fail2ban/filter.d/cccam.conf:

[Definition]
failregex = .*login failed.*from\s+.*
            .*invalid password.*.*
ignoreregex =

Добавляем в /etc/fail2ban/jail.local:

[cccam]
enabled  = true
port     = 12000
protocol = tcp
filter   = cccam
logpath  = /tmp/CCcam.log
maxretry = 5
bantime  = 3600
findtime = 600

После 5 неудачных логинов за 10 минут — IP банится на час.

Логи в tmpfs чтобы не убивать SD-карту ресивера

На Enigma2-ресиверах с SD-картой активные логи убивают её за месяцы. Переносим логи в RAM:

mount -t tmpfs tmpfs /var/log -o size=10M

Добавить в /etc/fstab для автомонтирования при загрузке:

tmpfs /var/log tmpfs defaults,size=10M 0 0

При перезагрузке логи теряются — это нормально для продакшна где DEBUG выключен.

Резервное копирование CCcam.cfg перед каждой правкой

Правило которое кажется очевидным, но нарушается постоянно. Перед любой правкой:

cp /var/etc/CCcam.cfg /var/etc/CCcam.cfg.bak.$(date +%Y%m%d_%H%M%S)

Если что-то пошло не так — восстановление за секунду:

cp /var/etc/CCcam.cfg.bak.20260523_143022 /var/etc/CCcam.cfg && killall -15 CCcam && /usr/bin/CCcam -d

Этот полный cccam configuration guide охватывает большинство реальных сценариев. Теперь ответы на самые частые вопросы.

Где находится файл CCcam.cfg?

Стандартные пути: /var/etc/CCcam.cfg (Enigma2-ресиверы VU+, Dreambox, Zgemma), /usr/keys/CCcam.cfg (некоторые Enigma2-сборки), /etc/CCcam.cfg (Linux x86). Если не знаете точного пути — выполните find / -name CCcam.cfg 2>/dev/null прямо на ресивере.

Какой порт открыть на роутере для CCcam?

По умолчанию TCP 12000 — задаётся параметром SERVER LISTEN PORT в CCcam.cfg. Протокол строго TCP, не UDP. Если ваш провайдер использует CGNAT — открыть входящий порт невозможно. В этом случае принимать входящих пиров нельзя, нужен VPS с туннелем или подключение только через C-lines.

В чём разница между F-line и C-line?

F-line — кто может подключиться к вам (вы сервер, они клиенты). C-line — куда подключаетесь вы (вы клиент чужого сервера). Оба типа можно использовать одновременно: вы принимаете шары по C-lines и отдаёте их своим пирам по F-lines.

Что значит hop 1, hop 2 в выводе CCcam -s?

Hop 0 — карта физически вставлена в ридер вашего ресивера. Hop 1 — прямой пир, карта у него в ридере. Hop 2 — пир вашего пира (reshare). Чем больше hop, тем выше ECM time и нестабильнее открытие каналов. Оптимально работать с hop 1.

Почему каналы открываются с задержкой 3-5 секунд?

Высокий ECM time — обычно из-за hop > 1, высокой сетевой латентности или перегруженной карты на стороне пира. Проверьте колонку ecm avg в веб-интерфейсе или через CCcam -s. Норма — до 500ms, плохо — от 1500ms. Решение: найти пира с hop 1 и убрать длинные reshare цепочки.

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

Да, на разных портах. Типичная схема: OScam управляет физическими смарт-картами и принимает ECM запросы, CCcam подключается к OScam через cccam-протокол как reader. Или наоборот: CCcam-сервер с пирами, OScam как client для управления локальными картами. Главное — порты SERVER LISTEN PORT у CCcam и cs378x.port у OScam не должны совпадать.

Что делать если после правки CCcam.cfg демон не стартует?

Первым делом — восстановить из бэкапа: cp CCcam.cfg.bak CCcam.cfg. Потом найти проблему: проверить лишние пробелы в конце строк, неверные символы (двоеточие вместо пробела), BOM-символы если редактировали в Windows. Правильный инструмент для правки — nano или vi прямо на ресивере, не SFTP-редакторы с Windows. После исправления — снова рестарт и смотреть лог запуска.

```

Практические советы для стабильного просмотра

Даже самая стабильная линия CCCam или OSCam требует пары простых подготовительных шагов. Обновляйте прошивку ресивера, раз в неделю очищайте ECM‑кеш и держите 15–20% свободного места на USB‑накопителе или во встроенной памяти, чтобы кардридер записывал ключи без задержек.

При настройке антенны оставляйте запас по MER/BER: смещение на два градуса или ослабленный F‑коннектор чаще становится причиной “фризов”, чем сам кардшаринг. Держите под рукой короткий патч‑корд для проверки другого роутера и сохраните два профиля в OSCam — под TCP и под UDP — чтобы мгновенно переключиться, если провайдер начнёт фильтровать протокол.

Utgard.tv следит за каждым хабом 24/7, однако вы можете ускорить диагностику, если будете вести небольшой журнал действий. Записывайте время переключения канала, активный CAID и то, использовали ли вы Wi‑Fi или Ethernet. Такой мини‑отчёт позволит инженерам воспроизвести вашу конфигурацию в лаборатории и предложить решение не за часы, а за минуты.

  • Держите активными две линии: если первый сервер уходит на обслуживание, второй тут же подхватывает поток без повторного ввода логина.
  • Раз в месяц делайте замер скорости и задержек. Стабильных 1–2 Мбит/с при пинге до 80 мс достаточно для SD/HD, но если джиттер превышает 20 мс — переведите роутер на провод.
  • Сохраните в закладки страницу статуса Utgard.tv и Telegram‑бота @utgard_tv_bot — там появляются уведомления о работах раньше, чем успеют среагировать SEMrush или внешние мониторы.