Инструкция по прошивке и настройке DreamBox 800 HD

[Admin]

Снятие лога работы эмулятора

Для снятия лога работы эмулятора нам нужна будет прога 3CSyslog
После установки проги на компьютер, прога в дополнительных настройках не нуждается.
Только в файле mg_cfg который находится в папке keys (естественно что это в папке дрима) нужно прописать IP - компьютера и порт:
L: { 07 } 192.168.1.2 514 /tmp/mgcamd.log это как пример, у вас может быть свой IP - компьютера.



Как правильно читать лог mgcamd и распознавать проблемы?

Авторский материал uncle.f (дядя Федор)

Что можно увидеть из лога?

Увидеть можно очень много! Для начала, собственно, старт mgcamd. В этом примере мы сделаем вид, что у нас прописано два разных сервера шары в newcamd.list. Первый сервер называется server1.com и у него порт 1234, второй - server2.com с портом 5678. Для логина на оба сервера используется имя username (пароль в логе не отображается). Итак, пример лога:

tuxbox mgcamd v1.31 by mixvt (compiled Oct 27 2008 23:09:59)
[mg] Net:1:7:2:2s Show ecm:1, emm:0 Up:0 Au:0 Dir:0 Osd:no:80:0 Cache:7 Log:1:192.168.1.1:514 Reread:0
[mg] Ecm cache time: 36000
Box type: ipbox9000
Conax.Key error 2: No such file or directory
Keys readed
[config] newcamd route = username:server1.com:1234
[config] newcamd route = username:server2.com:5678
newcamd keep alive: 300, incoming port: 12000
[mgcam] emm thread started
[mgcamd] tps update started.
/var/keys/tps.bin error 2: No such file or directory

[newcamd] Connecting to server1.com:1234...
[newcamd] Connecting to server2.com:5678...

[newcamd] Login to server1.com:1234 as username accepted (19ms)
[newcamd] Card data from server1.com:1234 (171ms):
Userid 189 caid 500 providers 4
Idents: 020910 023b00 024400 021700

[newcamd] Login to server2.com:5678 as username accepted (21ms)
[newcamd] Card data from server2.com:5678 (123ms):
Userid 137 caid 654 providers 4
Idents: 000000 000001 000002 000003

Отсюда уже сразу видно много интересного.
Во-первых, видны карты, которые шарятся (число сразу за "caid").
Вот список наиболее часто используемых кодировок:

01xx = Mediaguard/Seca
05xx = Viaccess
06xx = Irdeto
09xx = NDS Videoguard
0Bxx = Conax
0Dxx = CryptoWorks
17xx = BetaCrypt
18xx = NagraVision
26xx = BISS
4Axx = DreCrypt  (который mgcamd обзывает как @Sky в своих логах)

Из примера выше видно, что мы подключились к двум серверам. Первый шарит несколько карточек с кодировкой Viaccess (потому что CaID начинается с 5..). Также видно какие именно провайдеры карт шарятся - их 4 штуки. Это становится ясно из поля Idents, которое перечисляет все идентификаторы провайдеров Viaccess.

Второй сервер шарит карту в кодировке Irdeto (CaID начинается с 6..) На втором сервере выглядит так, что как будто бы тоже несколько провайдеров с идентами 0, 1, 2 и 3, но это только одна карта. Это особенность кодировки Irdeto (и Betacrypt, которая основана на Irdeto). Эти иденты называются чидами (ChID) и действуют также как и ProvID у других кодировок. Разница лишь только в том, что одна и та же Irdeto карта может иметь несколько ChID, а другие кодировки обычно имеют только один ProvID.

Итак, чтобы подвести предварительный итог, получается, что при включении кодированного канала, у него должен совпасть CaID:ProvID (или CaID:ChID для Irdeto) с теми, что прислал сервер при подключении к нему. Только в этом случае на сервер пойдет запрос "ключа". В такой ситуации mgcamd отошлёт на сервер так называемую последовательность Entitlement Control Message или ECM. Если на сервере всё впорядке, то он должен ответить на такой запрос последовательностью, которая называется Control Word или CW. Если вы получаете правильный код CW, то канал открывается. В зависимости от системы кодирования интервал смены ECM (живучесть ключа) может быть от 2-3 секунд до целой минуты. После чего повторяется ECM запрос и ответ CW и так далее.

Посмотрим как это выглядит в логе (важные цифры выделены):

[mg0] stoping camd..
[mg0] service 2EA index 0 pmt pid 0 (253)
ECM: CaID: 0x0500 -> CaPID: 0x040C ProvID: 022B00
ECM: CaID: 0x0654 -> CaPID: 0x07F4 ProvID: 000000
[mg1] service 2EA already started with index 0
[mg1] service 2EA index 1 pmt pid 0 (254)
[mg0] No viaccess key(s) found for id 22B00 keynr 08
[mg0] network can't decode
[mg0] pid 0x040C failed to decode.
[mg0] No irdeto key(s) found for id 0 keynr 00
[mg0] -> ECM to newcamd server2.com:5678
[mg0] <- CW from newcamd server2.com:5678 (481ms)
[mg0] 481 msec -- Wed Jun 10 01:32:49 2009
===== Irdeto ECM on CaID 0x0654, pid 0x07f4 ======
prov: 000000
cw0:0 A6 1E D2 96 57 62 A4 5D
cw1:0 32 2C 22 80 FA AB BA 5F
[mg0] irdeto using chid 0001 version C3

Пояснение к происходящему, где важна практически каждая строка.
Первые две строки - это стандартное сообщение при переключении канала. У каждого канала есть свой Service ID (SID), который уникален в пакете каналов. Из второй строки видно, что мы включили канал, у которого SID равен 2EA.
Дальше имеем две строки, начинающихся с ECM. В этих строках информация о кодировании канала (если канал открыт, то вы никаких ECM не увидите). В нашем примере мы включили кодированный канал, и открывается он либо картой Viaccess (CaID:500, ProvID:022B00) либо картой Irdeto (CaID:654, ProvID:000000). Каждой комбинации CaID и ProvID присваевается свой уникальный идентификатор PID. В нашем случае это PID 040C для 0500:022B00 и PID 07F4 для 0654:000000.

Посмотрим теперь в начало лога, где перечислены все CaID и ProvID, которые нам предлагают оба сервера. Есть ли там хотя бы одна из двух комбинаций CaID:ProvID, которая подходит ко включенному каналу? Есть одна, это - 654:000000, то есть то, что ответил нам server2.com при подключении к нему. К сожалению, у нас нет доступной карты Viaccess 0500:022B00, но mgcamd этого (ещё) не знает, поэтому он будет идти по списку кодировок, пока не наткнется на ту, которая подходит.

Из чего следует, что сначала мы смотрим, нет ли у нас уже ключа Viaccess (в кэше или в локальном файле SoftCam.Key): "No viaccess key(s) found for id 22B00 keynr 08". То есть, ключа нет. Дальше мы смотрим, не доступен ли ключ по сети. К сожалению, как мы уже установили, для Viaccess - у нас нет подходящего сервера. Поэтому мы получаем сообщение в логе "network can't decode". Теперь, когда все попытки исчерпаны mgcamd рапортует о том, что нам не удалось открыть канал, используя PID 040С (то есть комбинацию 0500:022B00). Это сообщение "pid 0x040C failed to decode", то есть канал не удалось открыть по кодировке Viaccess.

Переходим ко второму PID. Опять смотрим, нет ли у нас уже ключа Irdeto (в кэше или в локальном файле SoftCam.Key): "No irdeto key(s) found for id 0 keynr 00" - ключа нет. Теперь мы смотрим, доступен ли ключ по сети. У нас есть подходящая комбинация, объявленная сервером sever2.com при логине. Поэтому, следующая строка - это посылка ECM-запроса на сервер server2.com. Далее виден ответ от сервера с кодом CW. Ответ пришел за 481мс, на что стоит обратить внимание при проблемах с шарингом (но об этом ниже). Последние 5 строк - подтверждение проделанной работы по запросу на сервер. Показаны кодировка, которая окрылась (Irdeto), идентификатор карты (CaID), идентификатор кодировки (PID), идентификатор провайдера (ProvID), сама последовательность CW0+CW1, то есть "ключик" к каналу, полученный от сервера и (только для Irdeto) используемый этим каналом ChID. Дальше всё повторяется снова и снова, каждый раз когда меняется ECM.

Как увидеть и распознать проблему, используя лог

Рассмотрим теперь проблемные ситуации, когда все должно вроде бы работать, но не работает или работает, но не так как хотелось бы. Во первых, нужно убедиться, что mgcamd вообще для начала пытается подсоединиться к серверу. Это должно выглядеть так:

[config] newcamd route = login:server1.com:1234
[newcamd] Connecting to server1.com:1234...

Этих строк должно быть по две на каждую строку "CWS=" из newcamd.list. Если таких строк нет, то проверяйте ваш файл newcamd.list. Проверьте, чтобы файл находился там, где ему положено и имел правильный формат.

Во-вторых, по какой угодно причине может отсутствовать доступ к серверу. Либо из-за проблем с Интернетом (включая неверные настройки вашей домашней сети), либо из-за глобальных проблем на сервере, либо из-за проблем лично с вашим логином (не на тот сервер или порт коннектитесь, отключены за неуплату или по причине бана из-за нарушения правил пользования). Во всех этих случаях вы получите в логе нечто вроде такого:

[config] newcamd route = login:server1.com:1234
[newcamd] Connecting to server1.com:1234...
[newcamd] Connection to server1.com:1234 failed (47ms)

Чтобы убедиться, что связь с сервером есть, нужно зайти на ресивер по Telnet и дать команду ping server1.com, где server1.com нужно поменять на имя или IP адрес вашего сервера. Остановить команду можно, нажав CTRL+C. Если ответа не придет, то нужно смотреть что у вас с коннектом к Интернету (в крайнем случае, если пингуются другие адреса, кроме вашего сервера, то скорее всего сервер мертв). Если ответ есть, то нужно выяснить почему вас сервер не пускает (не тот логин или пароль; не тот сервер, если их несколько у провайдера; бан на сервере и т.д.)

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

===== @Sky ECM on CaID 0x4AE1, pid 0x0078 ======
prov: 000000
cw0:0 0F 8B 67 01 27 0D 9E D2
cw1:0 58 07 6F CE 63 E3 2F 75
[mg0] -> ECM to newcamd server1.com:1234
[mg0] -> ECM to newcamd server1.com:1234
[mg0] -> ECM to newcamd server1.com:1234
[mg0] -> ECM to newcamd server1.com:1234
[mg0] <- CW from newcamd server1.com:1234 (1116ms)
[mg0] WARNING, both cws changed !
[mg0] 1116 msec -- Thu Jun 11 13:30:00 2009
===== @Sky ECM on CaID 0x4AE1, pid 0x0078 ======
prov: 000000
cw0:0 D6 2E 1E 22 23 0D E5 15
cw1:0 D8 9C 5E D2 2F 21 FE 4E

Здесь приведено классическое определение "затыка". Это когда либо по причине плохого качества связи, либо по причине проблем на сервере вам не приходит во время или вообще не приходит ответ на ECM-запрос. В здешнем примере мы видим, что сервер ответил только с 4-го раза, при этом ключ поменялся уже два раза (или больше): "WARNING, both cws changed !". Бороться с затыками можно только двумя способами: улучшать качество Интернет коннекта или (если вы уверены, что с Интернетом у вас все впорядке) менять провайдера шары. Простейший тест на предмет "где затык: на сервере или в Интернете?" состоит в запуске команды (из ресивера) ping server1.com, или (из Windows) ping -t server1.com, где server1.com нужно поменять на имя или IP адрес вашего сервера (остановить команду можно, нажав CTRL+C). Нужно, следить за результатами ping во время просмотра канала и одновременно смотреть лог mgcamd. Как только вы увидите в логе mgcamd, что на запрос ECM нет ответа нужно сразу же смотреть на результаты ping, есть ли потери и там. При этом картинка на экране ТВ - это не показатель затыка, так как изображение продолжается еще некоторое время, даже без ответа от сервера. Если есть потери данных в ping (команда перестает выдавать информацию в этот момент в Linux или выдает "Request timed out" в Windows), и, особенно, если это происходит в момент затыка, то, скорее всего, сервер тут ни при чем - улучшайте свой Интернет коннект. Если же ping идеальный, без потерь и с более-менее одинаковым временем отклика при каждом запросе, то у вашего шаровика проблемы (перегруз карты, криво настроен софт, и т.д.).
Так выглядит идеальный ping c 0% потерь:

# ping server.com
PING server.com (x.x.x.x): 56 data bytes
64 bytes from x.x.x.x: icmp_seq=0 ttl=56 time=8.7 ms
64 bytes from x.x.x.x: icmp_seq=1 ttl=56 time=8.8 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=56 time=7.7 ms
..... здесь пропущено 994 строки ....
64 bytes from x.x.x.x: icmp_seq=997 ttl=56 time=7.9 ms
64 bytes from x.x.x.x: icmp_seq=998 ttl=56 time=8.9 ms
64 bytes from x.x.x.x: icmp_seq=999 ttl=56 time=8.0 ms

--- server.com ping statistics ---
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max = 7.3/8.1/8.9 ms

Так выглядит плохой ping с потерями и плохим коннектом:

# ping server.com
PING server.com (x.x.x.x): 56 data bytes
64 bytes from x.x.x.x: icmp_seq=0 ttl=56 time=7.5 ms
64 bytes from x.x.x.x: icmp_seq=1 ttl=56 time=7.9 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=56 time=8.0 ms
..... здесь НЕ пропущено ничего, просто не пришел ответ на ping ....
64 bytes from x.x.x.x: icmp_seq=20 ttl=56 time=7.2 ms
64 bytes from x.x.x.x: icmp_seq=21 ttl=56 time=8.0 ms
64 bytes from x.x.x.x: icmp_seq=22 ttl=56 time=9.0 ms

--- server.com ping statistics ---
23 packets transmitted, 17 packets received, 26% packet loss
round-trip min/avg/max = 6.9/8.6/30.1 ms

Когда возникает затык, подобный описанному выше, два параметра настройки mgcamd являются очень важными в плане того, как mgcamd будет реагировать на затыки (что по сути дела значит, как скоро можно ожидать возвращение картинки на экран). Это параметры K:{} и N:{} из файла mg_cfg.

Параметр K:{} описывает какое максимальное количество времени (в секундах) нужно ждать ответа от сервера на ECM запрос, по истечении которого mgcamd решает, что ответа нет. Чем больше это число, тем больше шансов получить ответ, если у вас плохой Интернет или глюкавый сервер шары. Кроме того, еще зависит от того, какие пакеты вы смотрите. Большинство карт обычно отвечают меньше, чем за 1 секунду. Но есть некоторые карты, где нормальное время отклика 1-2 секунды. В экстремальных случаях (известный пример - пакет Nova), ответ может приходить и за 3-5 секунд. Естественно, если вы установите K:{} равным 1 секунде, а сервер будет пытаться вам ответить через 2-3 секунды, то ничего хорошего из этого не выйдет. mgcamd все время будет думать, что сервер не ответил (по истечении секунды) и слать запросы повторно. От этого будет плохо всем, в основном, конечно, серверу, который будет завален запросами, ну и ресиверу тоже, который будет работать в таком случае неоптимально.

С другой стороны если взять и увеличить параметр K:{} на неразумно большую величину, типа 5 или больше секунд, то возникнет совершенно неблагоприятный эффект для вас. Представьте, что обычно вам ответы приходят за 0,5 секунды, и один раз ответ по какой-то причине не пришел. Теперь вы будете ждать целых 5 секунд, до тех пор, пока mgcamd не попытается снова послать запрос. За это время на некоторых каналах уже может случиться и затык, в то время, как если бы у вас повторный запрос пошел через, скажем, 2 секунды и пришел бы успешный ответ, никто бы ничего (на экране ТВ) не заметил!

Грубо говоря, когда есть проблемы с ответами от сервера, то чем меньше K:{}, тем хуже серверу шары из-за большего количества запросов, и чем больше K:{}, тем вероятнее вы получите затык. Хотя это все очень относительно и сильно зависит от конкретных пакетов. Есть пакеты (Премьера HD, Скай Италия и т.д.), где время ответа от карты критично. Для таких пакетов с кодировкой Videoguard, если вы не получите ключ за 0.6сек, то будет однозначный затык. Здесь можно спокойно ставить единицу в значение K:{}. С другой стороны, для таких пакетов, как Премьера SD или Nova и 2х секунд иногда недостаточно, и правильным значением должно быть 3.

Ценный совет:

Лучше всего пронаблюдать насколько быстро вам приходят ответы в целом на интересующие пакеты (выставив K:{} в большое значение, типа 5). После этого нужно брать для K:{} значение чуть больше того, где самые долгие ответы (в среднем).

Дальше, параметр N:{7} X Y влияет на то, как mgcamd ведет себя когда понимает, что ответ от сервера все же не пришел. Число X устанавливает количество неуспешных запросов на сервер (каждый из них длиной в K:{} секунд), после чего mgcamd отваливается от сервера и пытается к нему приконнектиться заново. Эта процедура нередко помогает, когда на сервере какие-то глюки, хотя конечно, постоянно это недолжно происходить. Параметр Y говорит mgcamd о том, что нужно отваливаться и реконнектиться заново, если не было никаких признаков жизни у сервера в течение Y секунд. Обычно до Y доходит дело крайне редко, потому как реконнект обычно происходит из за параметра X (в комбинации с K:{}).

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