GBox ECM Timeout: причины и решение в OScam 2026

Если у вас в логе OScam мелькает строка с ECM timeout, а каналы открываются через раз или вовсе замирают — это не случайный сбой, а симптом конкретной проблемы в цепочке от ресивера до карты. Статья про gbox: ECM timeout решение именно в таком контексте: система уже запущена, пиры онлайн, но что-то в декодировании идёт не так. Разберём всё по порядку — от чтения лога до тонкой настройки loadbalancer.

Что означает ECM timeout в логе GBox и где его искать

ECM timeout — это превышение времени ожидания ответа на ECM-запрос. OScam отправляет ECM (Entitlement Control Message) ридеру или пиру, и если ответ не приходит в течение заданного времени (по умолчанию 5000 мс, параметр clienttimeout в oscam.conf), запись в лог идёт как timeout.

Основной лог лежит по пути /var/log/oscam.log или в каталоге, заданном параметром logfile в секции [global]. Веб-интерфейс OScam доступен по адресу http://IP:8888/ (порт задаётся параметром httpport в секции [webif]). Там же в разделе ECM History видно время ответа в миллисекундах, hop и слот карты.

Для GBox в /usr/local/etc/oscam.conf есть отдельная секция [gbox], где можно задать уровень собственного лога через параметр logfile внутри секции. Отдельный файл gbox.log пишется при наличии соответствующей директивы сборки.

Как читать строку ECM в логе OScam

Типичная строка выглядит так:

2026/03/15 14:22:31 c [gbox] ECM 0963/000000/01 from user1 — timeout (4987 ms, hop 2, slot 3)

Здесь 0963 — CAID, 000000 — провайдер ID, 01 — сервисный ID. Время 4987 мс говорит, что ответ почти пришёл, но не уложился. Hop 2 значит, что запрос прошёл через два узла — уже на грани.

Разница между timeout, no card и rejected

Timeout — карта или пир есть, маршрут построен, но ответ не пришёл вовремя. Лечится таймаутами, сетью, hop-ограничением.

No card — ни один ридер не имеет нужного CAID/ProvID. OScam даже не ждёт, сразу пишет отказ. Здесь нужна другая карта или правка ident в oscam.server.

Rejected / ECM dropped — запрос отфильтрован по правилам услуг, services, class или настройкам пира. Причина не в скорости, а в логике маршрутизации.

Включение детального лога: debug level и cs_loglevel

В секции [global] файла oscam.conf поставьте:

logfile = /var/log/oscam.log
maxlogsize = 512
cs_loglevel = 255

Значение 255 — это побитовая маска, включающая все уровни, включая отладку ECM и loadbalancer. После диагностики лучше снизить до 4 или 12, иначе лог забивается моментально. debug = 1 в той же секции добавляет ещё больше деталей по GBox-пирам.

Главные причины ECM timeout в кардшаринге через GBox

GBox работает поверх UDP, а UDP — это «выстрелил и забыл». Нет гарантии доставки, нет автоматической ретрансмиссии. Даже 2–3% потерь пакетов дают ощутимый процент timeout на ECM-ответах, особенно если сеть и без того нестабильна.

Большое количество hop и медленные пиры

Каждый hop — это ещё один узел в цепочке, ещё одна задержка. Hop 1 — прямая карта, ответ обычно приходит за 100–400 мс. Hop 2 — уже 400–900 мс. При hop 3 и выше ответ легко выходит за 1500 мс, и при clienttimeout = 3000 любой сетевой чих даёт timeout.

Параметр maxdist в секции [gbox] ограничивает, с какого расстояния OScam принимает карты от GBox-пиров. Значение maxdist = 2 отсекает решары третьего уровня и дальше. В CCcam-совместимом режиме аналогичная роль у cccmaxhops.

Перегрузка карты: лимит ECM в секунду

Один смарткарт-ридер физически обрабатывает ограниченное число ECM-запросов в секунду — обычно 4–8, в зависимости от карты и ридера. При нескольких клиентах, смотрящих разные каналы, запросы выстраиваются в очередь. ECM, дождавшийся своей очереди слишком поздно, отправляется, но ответ уже просрочен.

Это особенно заметно на HD-каналах с коротким ECM-интервалом (некоторые провайдеры меняют ключ каждые 10 секунд) и при ECM-burst — массовой смене ключей по расписанию. В этот момент пик нагрузки на карту может дать сразу несколько timeout подряд, даже если в обычное время всё работает нормально.

Сетевые потери и нестабильный UDP-канал GBox

Высокий пинг сам по себе не критичен — 80–100 мс вполне жизнеспособно. Критичны потери (packet loss). При 5% потерь каждый двадцатый ECM-запрос или ответ теряется, а OScam ждёт до таймаута. Проверить просто: ping -c 100 IP_пира и смотреть на packet loss.

Фрагментация UDP — отдельная история. Если MTU на пути к пиру меньше, чем GBox ожидает, пакеты фрагментируются, и часть фрагментов теряется. Лечится снижением MTU на интерфейсе: ip link set eth0 mtu 1400.

Несовпадение caid/provid и неправильные маршруты

OScam может отправить ECM-запрос пиру, у которого нужного provid нет. Пир молчит, OScam ждёт до clienttimeout, потом пробует следующий ридер — или сдаётся. Итог: timeout, хотя на самом деле это маршрутинг, а не скорость.

После того как провайдер меняет ProvID (это случается при обновлении условного доступа), старый ident в oscam.server начинает слать запросы в никуда. OScam честно ждёт до таймаута. Обновить ident в oscam.server — первое, что нужно проверить при внезапно появившихся таймаутах после работавшей конфигурации.

Настройка таймаутов и маршрутов в oscam.server и oscam.conf

Вот где происходит большая часть тонкой настройки. Файлы лежат в /usr/local/etc/ или /etc/oscam/ в зависимости от сборки. Пути проверяются командой oscam --help | grep config.

Параметр clienttimeout и его адекватные значения

В секции [global] файла oscam.conf:

[global]
clienttimeout = 3000
fallbacktimeout = 2500
clientmaxidle = 120

clienttimeout — максимальное время ожидания ECM-ответа от любого ридера. fallbacktimeout — время, после которого OScam начинает параллельно слать запрос на следующий ридер (фолбэк), не дожидаясь первого.

Ставить clienttimeout = 8000 «на всякий случай» — плохая идея. При зеппинге ресивер ждёт ответа перед показом канала, и 8 секунд ожидания превращают смену канала в пытку. Рабочий диапазон — 2500–4000 мс. Подбирать под реальный ECM time из лога: если типичный ответ 600 мс, достаточно 2500 мс с запасом.

Секция [gbox]: maxdist, ignored caid, port

В oscam.conf:

[gbox]
port = 19000
maxdist = 2
ignorelist = /usr/local/etc/oscam.ignore
nodeid = AABBCCDD

maxdist = 2 — принимаем карты только до hop 2 включительно. port = 19000 — стандартный порт GBox, убедитесь, что он открыт на firewall (UDP). nodeid — уникальный идентификатор ноды, должен быть уникальным в сети пиров.

Если нужно игнорировать определённые CAID из GBox-сети (например, те, что у вас есть локально), используйте файл ignorelist — туда вносят CAID в hex-формате построчно.

Приоритеты карт через oscam.services и caidtab

Локальная карта должна иметь приоритет над сетевыми пирами. В oscam.server для локального ридера:

[reader]
label = local_card
protocol = mouse
device = /dev/ttyUSB0
caid = 0963
ident = 0963:000000
group = 1
services = local_services

Файл /usr/local/etc/oscam.services задаёт именованные группы сервисов. Параметр services = в ридере и у клиента позволяет направить конкретные каналы на конкретный ридер, не полагаясь на автоматику loadbalancer. Локальный ридер ставьте в group = 1, сетевых пиров — в group = 2 или выше.

Ограничение hop: cccmaxhops и reshare

Для CCcam-совместимого режима в /etc/CCcam.cfg:

CCCAM RESHARE = 1
CCCAM MAXHOPS = 2

В OScam параметр cccmaxhops задаётся в секции ридера типа cccam. reshare = 0 в описании клиента запрещает клиенту реширить полученные карты дальше — снижает нагрузку на карту и уменьшает вероятность перегрузки.

Пошаговая диагностика: от ресивера до карты

Хаотичная диагностика "поменял одно, поменял другое" только запутывает. Вот последовательность, которая работает.

Шаг 1: проверка статуса пиров в веб-интерфейсе

Открываем http://IP:8888/, вкладка Status. Смотрим на GBox-пиров: статус должен быть online, и рядом должно быть ненулевое число карт (Cards). Если пир онлайн, но Cards = 0 — у него нет нужного CAID или он ничего не реширит.

Запомните: online — это только наличие UDP-соединения на уровне хэндшейка. Карты при этом могут не соответствовать тому, что вам нужно. Это один из самых частых источников путаницы при поиске gbox: ECM timeout решение.

Шаг 2: тест времени ответа ECM по конкретному каналу

Переключитесь на проблемный канал и в веб-интерфейсе смотрите раздел ECM History. Ищите строки с нужным CAID. Время ответа до 600 мс — хорошо. 600–1500 мс — терпимо, но риск при нагрузке. Выше 1500 мс — проблема, timeout неизбежен при малейшей нестабильности.

Особо обратите внимание на HD-каналы. У некоторых провайдеров интервал смены ключа на HD составляет 8–10 секунд, и при медленном ответе карта успевает ответить только со второй-третьей попытки — картинка замерзает на секунду.

Шаг 3: проверка сети — ping, потери пакетов, MTU

Базовая проверка:

ping -c 200 -i 0.2 IP_пира

Смотрим на packet loss. Больше 1% — уже повод насторожиться. Больше 3% — явная проблема. Для проверки MTU:

ping -M do -s 1400 IP_пира

Если пакет 1400 байт не проходит без фрагментации — снижаем MTU на интерфейсе. Для GBox через VPN особенно актуально, там overhead от туннеля съедает 20–40 байт.

Шаг 4: изоляция проблемного ридера через group

В oscam.server каждый ридер имеет параметр group. Временно меняем group подозрительного пира на значение, которое не входит в group ни одного клиента — и он выпадает из ротации. Если timeout исчезают — источник найден.

[reader]
label = gbox_peer1
protocol = gbox
device = 192.168.1.10,19000
group = 99
# временно отключён из группы клиентов

После изоляции проверяем параметры lb_log_only = 1 и saveinit = 1 в секции [global] — это позволяет видеть, как loadbalancer принимает решения, без реального влияния на маршрутизацию.

Балансировка нагрузки (loadbalancer) против ECM timeout

Loadbalancer в OScam — это механизм, который запоминает, какой ридер отвечает быстрее всего для данного CAID/ProvID/ServiceID, и в следующий раз отправляет запрос сразу туда. Звучит хорошо, но с накопленной плохой статистикой превращается в проблему.

Режимы lb_mode и какой выбрать против таймаутов

В секции [global]:

lb_mode = 1
lb_save = 100
lb_retrylimit = 800
lb_reopen_seconds = 900
lb_nbest_readers = 2
lb_nfb_readers = 1

lb_mode = 1 — режим "fastest reader", OScam всегда выбирает ридер с лучшей исторической статистикой для данного запроса. lb_mode = 0 — без балансировки, запросы идут по порядку. Для борьбы с timeout предпочтителен режим 1.

lb_nbest_readers = 2 — держать в активной ротации двух лучших ридеров для каждого сервиса. При падении первого второй уже разогрет.

lb_retrylimit, lb_reopen_seconds, lb_nbest_readers

lb_retrylimit = 800 — если ответ от ридера превышает 800 мс, OScam не ждёт полного clienttimeout, а параллельно пробует следующий ридер. Это ключевой параметр против таймаутов: он срабатывает раньше, чем ECM успевает просрочиться.

lb_reopen_seconds = 900 — через 900 секунд OScam снова пробует ридеры, которые раньше давали плохую статистику. Это страховка на случай, если пир восстановился.

Очистка и пересборка статистики loadbalancer

Stat-файл лежит в директории, заданной параметром tmpdir в oscam.conf (обычно /tmp/oscam). Файл называется stat или oscam.stat. Если после смены пиров или изменения конфига timeout вернулись — сначала удалите этот файл и перезапустите OScam:

service oscam stop
rm /tmp/oscam/stat
service oscam start

Первые несколько минут после очистки OScam работает вслепую, накапливая новую статистику — в это время возможны замедления. Потом выравнивается. Если проблема возвращается через несколько часов — значит, loadbalancer снова накапливает плохую статистику по одному из ридеров и перестаёт его обходить. Ищите ридер с хронически высоким временем ответа и либо чините его, либо удаляйте из конфига.

На что смотреть при выборе источника карт (без привязки к конкретным сервисам)

Хороший источник карт — половина решения. Никакая настройка OScam не вытащит стабильный декодинг из медленного или перегруженного пира. Вот на что реально смотреть.

Стабильность пинга и аптайма пира

Пинг до пира должен быть стабильным и предсказуемым. Не обязательно низким — 60–80 мс приемлемо, если без джиттера. Плохой вариант: пинг 20 мс, но с размахом 5–200 мс и 2% потерь. Хороший: 70 мс с отклонением ±5 мс и нулевыми потерями.

Аптайм пира важен не меньше. Пир, который перезапускается раз в несколько часов, каждый раз роняет статистику loadbalancer и провоцирует временные таймауты. Смотрите на uptime в веб-интерфейсе OScam в колонке Connected.

Заявленный hop и реальная дистанция

Пир может показывать в интерфейсе много карт с hop 1, но реально реширить чужое с hop 2–3 и высокой латентностью. Как это проверить: сравните ECM time с тем, что вы ожидаете от hop 1 (обычно до 400 мс). Если ECM time 1200 мс при "hop 1" — это явно решара с маскировкой hop.

Чек-лист по дистанции:

• ECM time в норме для заявленного hop (до 400 мс для hop 1, до 900 мс для hop 2)
• Время ответа стабильно, без всплесков в часы пик
• Пир географически близок к вам — это снижает базовую задержку

Поддержка нужных caid/provid и локальность карты

Перед подключением пира убедитесь, что у него есть именно нужный CAID и ProvID. В веб-интерфейсе OScam в разделе Reader смотрите на список CAID/ProvID для каждого ридера.

Локальная карта (физическая, в ридере на вашем сервере) всегда лучше любой сетевой. Если есть возможность использовать собственный ридер хотя бы для части каналов — настройте приоритет через oscam.services и группы, как описано выше. gbox: ECM timeout решение часто сводится именно к тому, чтобы как можно больше запросов закрывалось локально, а не уходило в сеть.