# первые две строки - стандартная настройка, трогать не нужно
CWS_KEEPALIVE = 300
CWS_INCOMING_PORT = 12000

# каждая последущая строка описывает ваш коннект на тот или иной пакет шаринга.
# если у вас несколько разных пакетов, на каждый пакет идет своя строчка конфигурации.
# даже если сервер один и тот же, на каждый пакет - свой отдельный порт, поэтому нужно
# прописать все отдельно. вся информация из биллинга. Формат строки следующий:
# CWS = адрес-сервера порт-сервера логин-биллинга пароль-биллинга строка-из-14-цифр-из-биллинга
# для примера, вы купили два пакета: НТВ и Platforma, значит у вас будет 2 строки
# (вcе параметры ниже ненастоящие, вам нужно взять вашу личную инфу из биллинга):

CWS = server1.com 1234 username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14 # это НТВ
CWS = server2.com 5678 username password 01 02 03 04 05 06 07 08 09 10 11 12 13 14 # это Platforma

В принципе - это всё. Минимум для шаринга осуществлен.
Перегружайте ресивер и если у вас правильно настроена домашняя сеть, выход в Интернет и настройки файлов приведенных выше совпадают с биллингом, то всё должно заработать.

Но... можно пойти дальше и настроить mgcamd самым оптимальным образом. Особенно, если вы заметите, что некоторые каналы открываются по несколько секунд. Для этого нам понадобятся файлы ignore.list и priority.list. Но для того, чтобы понять что туда писать, лучше сначала понять что именно происходит при работе mgcamd с сервером шары. Поэтому сначала запустим всё как есть без этих файлов, и посмотрим в лог, где мы найдем информацию, которая поможет нам создать эти два файла. Информация по просмотру лога также полезна даже если вы не хотите заморачиваться с этими файлами ignore и priority, в частности, если что-то не работает, то первым делом вам нужно просмотреть именно лог.

Как правильно читать лог mgcamd?

Как уже было написано в примере конфига mg_cfg выше - есть 2 способа. Либо заставить mgcamd писать лог файл прямо на самом ресивере, либо заставить mgcamd слать тот же лог по сети, скажем на ваш обычный компьютер.

В первом случае не понадобится никакого дополнительного софта, и для просмотра лога можно просто зайти на ресивер через Telnet и наблюдать за работой mgcamd в реальном времени, выводя содержимое файла на экран Linux командой tail -f <имя-лога>. Хотя это кажется самым логичным способом, это не совсем так. Это неудобно, потому как во-первых, нужно коннектиться к ресиверу и работать с командной строкой Linux, а во-вторых, лог будет все время расти (хотя и медленно). Если его своевременно не стирать, то в один день просто забъёт всю флеш-память, а это лишние хлопоты.

Гораздо более удобней просто напросто наблюдать за логом с компьютера, который находится в локальной сети с ресивером, без каких либо логинов в сам ресивер. Для этого нужно просто установить параметр L: { 01 } как показано выше в примере mg_cfg и запустить на вашем компьютере бесплатную программку (просмотрщик сообщений syslog), которая будет принимать сообщения от mgcamd и выводить их в виде лога на экране компьютера.

Бесплатных программ для этой цели есть по крайней мере 2. На большинстве сайтов рекомендуют древнюю программу 3CSyslog, которую можно взять здесь. Архив весит чуть меньше мегабайта и всё работает, в принципе ок. Хотя слишком уж эта программа древняя, без минимальных дополнительных функций. А самый главный её минус в том, что она показывает все сообщения "задом наперед", то есть самые новые сообщения всегда в самой верхней строке. Обычно это удобно, но вот в случае с mgcamd это как раз совсем неудобно (по крайней мере для тех, кто привык смотреть в обычный лог mgcamd). mgcamd выплёвывает в лог по нескольку сообщений на каждую смену CW/DW и этот "блок" сообщений отображается "задом наперед", что может затруднить понимание происходящего.

Рекомендую попробовать другую софтину, Kiwi Syslog Daemon. Бесплатная (урезанная) версия, которой полностью хватает для нормального просмотра лога, находится здесь. Весит софтинка чуть больше 7МБ, но и возможностей конфигурации у неё побольше. При установке выберите "Ставить как отдельный клиент (Install as an Application)", а не как сервис (хотя, кому как нужно). После запуска следует зайти в меню File -> Setup -> Display и убрать птицу с параметров "Reverse Scroll" и "Use MM/DD/YYYY" (потому что не американцы мы). Теперь сообщения будут отображаться сверху вниз. На экране показывается только
40 последних сообщений (этот параметр можно менять в той же самой панели настройки), но все сообщения можно писать в текстовый файл, если включена соответсвующая опция в File -> Setup -> Rules -> Actions -> Log to file.

Принцип действия всего этого очень простой. mgcamd посылает текстовые сообщения (используя протокол UDP) на IP адрес и порт 514 (стандартный порт для протокола Syslog), который вы установили в параметре L: { 01 } в файле /var/keys/mg_cfg. Программка на вашем компьютере принимает сообщения с этого порта и выводит на экран. Если Syslog не запущен, сообщения просто будут "растворяться" вникуда без побочных эффектов для ресивера или вашего компьютера. Так что такую настройку можно сделать постоянной и просто включать на компьютере Syslog Daemon, если понадобится посмотреть отчего там вдруг не работает шара или насколько хорошо работает шара.

Если вы только поменяли свой mg_cfg и прописали туда IP своего компьютера для отсылки лога, нужно перезапустить mgcamd. Это можно сделать перезагрузив ресивер или из панели NLB (зелёная кнопка, опция Restart EMU).

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

Увидеть можно очень много! Для начала, собственно, старт 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 (35ms):
Userid 72 caid 90F providers 1
Idents: 000000

[newcamd] Login to server2.com:5678 as username accepted (21ms)
[newcamd] Card data from server2.com:5678 (71ms):
Userid 189 caid 500 providers 5
Idents: 020910 025100 023b00 024400 021700

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

1xx=Seca
5xx=Viaccess
6xx=Irdeto
9xx=NDS/Videoguard
Bxx=Conax
Dxx=CryptoWorks
Exx=PowerVu
17xx=BetaCrypt
18xx=NagraVision
26xx=BISS
4Axx=DreCrypt

Из примера выше видно, что мы подключились к двум серверам. Первый шарит карточку с кодировкой NDS/Videoguard (потому что CAID начинается с 9), а второй сервер шарит карту в кодировке Viaccess (CAID начинается с 5). При чём, второй сервер шарит даже не одну, а "пять карточек" - это становится ясно из поля Idents. Посмотреть на все возможные CAID:Idents можно в ваших настройках в биллинге.

Получается, что при включении кодированного канала, у него должен совпасть CAID и IDENT с теми, что прислал сервер при подключении к нему. Только в этом случае на сервер пойдет запрос и mgcamd отошлёт на сервер так называемую последовательность Entitlement Control Message или ECM. Если на сервере всё впорядке, то он должен ответить на такой запрос последовательностью, которая называется Control Word или CW. Если вы получаете правильный код CW, то канал открывается. В зависимости от системы кодирования интервал между запросами на сервер может быть от 2-3 секунд до раза в минуту.

Посмотрим как это выглядит в логе:

[mg0] stoping camd..
[mg0] service 18A6 index 0 pmt pid 0 (65)
ECM: CaID: 0x090F -> CaPID: 0x18AF ProvID: 000000
[mg0] -> ECM to server1.com:1234
[mg0] <- CW from server1.com:1234 (23ms)
[mg0] 23 msec -- Sat Jan 31 15:09:42 2009
===== NDS ECM on CaID 0x090F, pid 0x18af ======
prov: 000000
cw0:0 09 8E E9 80 5E 2B 14 9D
cw1:0 CE 0A 98 70 66 C0 E9 0F

Пояснение к происходящему: первые две строки - это стандартное сообщение при переключении канала. Дальше имеем строку, начинающуюся с ECM. В ней информация о текущем канале. Из этого видно, что канал, который мы только что включили кодированный и открывается только одной картой, которая должна имеет пару CAID:ProvID = 090F:000000. Это как раз подходит по параметрам к тому, что нам ответил сервер server1.com при подключении к нему. По этому следующая строка - это посылка ECM-запроса на сервер server1.com. Далее виден ответ от сервера с кодом CW. Ответ пришел за 23мс, на что стоит обратить внимание (но об этом ниже, когда речь пойдёт о проблемах с шарингом). Последние 4 строки - подтверждение проделанной работы по запросу на сервер. Показаны кодиорвка, которая окрылась (NDS), идентификатор карты (CAID), идентификатор канала (PID), идентификатор провайдера (ProvID) и, наконец, сама последовательность CW0+CW1, то есть "ключик" к каналу, полученный от сервера. Дальше всё повторяется снова и снова, каждый раз когда меняется ECM.

Естетвенно, это всё лог "в идеале", то есть, когда всё правильно настроено, хорошо работает Инет и на сервере шары тоже всё ок. Проблемные ситуации рассмотрены ниже, а сейчас, поскольку вы умеете теперь читать лог, речь пойдет о настройке файлов priority.list и ignore.list.

Как настроить priority.list и ignore.list

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

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

Получается, что один и тот же канал в принципе можно открыть совершенно разными картами, но по шарингу, обычно, доступна одна виртуальная "карта", а не все возможные для этого канала. При включении канала mgcamd смотрит какими кодировками и провайдерами закодирован канал и начинает перебирать их по-порядку. Если получится так, что карта, которая открывает канал, последняя в этом списке, то возникает задержка, пока mgcamd доберётся до нужной карты и откроет канал. Для избежания такой ситуации служит файл ignore.list, где можно указать какие CAID и ProvID нужно игнорировать, чтобы нужная вам комбинация CAID:ProvID оказалась на первом месте в списке.

Ещё хуже, когда у вас коннект на несколько разных серверов (или портов) шары и из за того, что у некоторых провайдеров одинаковые ID для разных пакетов, запрос от вас может вообще пойти не на тот сервер, так как у канала на первом месте стоит не тот CAID:ProvID, что нужно. В таком случае каналы могут вообще открываться по 10 и 20 секунд и больше (смотря как настроены тайм-ауты mgcamd), пока от сервера куда пошёл запрос "не по теме" не прийдет тайм-аут. Для избежания такой ситуации используется файл priority.list.

Для более сложных ситуаций, иногда приходится использовать оба файла в комбинации друг с другом. Хотя это необязательно, вопреки тому, что иногда пишут на форумах. Оба файла не зависят друг от друга, но файл ignore.list берет верх над priority.list. Поэтому бессмысленно иметь в этих файлах одинаковые записи.