Транслировать multicast как unicast wifi что это

Юникастовая маршрутизация мультикаст-трафика

Предисловие

Недавно мною было замечено, что при просмотре мультикастового IPTV через Wi-Fi часть трафика теряется. После детального изучения проблемы было выяснено, что такое поведение объясняется природой мультикаст-трафика, а именно – MAC-адрес получателя пакета. Он не зависит от получателя и формируется из адреса мультикаст-группы. Соответственно, на такие пакеты претендуют все клиенты, подключенные к беспроводной точке доступа. Вследствие этого нам достается лишь часть пакетов и мы видим обрывистую картинку.

Штатными средствами проблема решается либо созданием отдельной точки доступа для клиента, либо созданием статического маршрута для определенных мультикаст-групп, или же выведением клиента в отдельный VLAN. Вся “сила” таких решений проявится, когда в сети будет несколько IPTV-приставок, желающих посмотреть один и тот же канал, плюс необходимость их в интернете добавит сложность к настройке роутера. Свое решение данной проблемы предлагаю ниже.

Программы типа udpxy здесь не подходят, так как они меняют полную структуру пакета. А нам необходимо лишь установить необходимый MAC-адрес, при этом сохраняя сетевую и транспортную части, чтобы клиентское ПО не заметило никаких изменений.

Немного теории

Схематическое представление mfc_cache-списка:

Изображение взято из книги “Linux Networking Architecture”

Разработка

За основу было взято ядро Linux 3.18. Для хранения IP-адресов клиентов для каждой мультикаст-группы расширяем mfc_cache связанным списком:

Вводим новую функцию ipmr_unicast_xmit. В ней будет генерироваться юникастовый rtable, но передавать при этом будем мультикастовый sk_buff. Таким образом мы выбираем необходимый интерфейс для будущей отправки.

Теперь для того, чтобы в дальнейшем был создан neighbour для нашего получателя, а не для мультикаст-группы, в rtable указываем шлюз. За это отвечает поле rt_gateway:

Вводим sysctl-переменную /proc/sys/net/ipv4/mut. Она даст возможность смены режима работы ядра “на лету”.

Как и раньше можно посмотреть список маршрутов, теперь еще и unicast:

# cat /proc/net/ip_mr_cache
Group Origin Iif Pkts Bytes Wrong Dsts
0520C3EF 2 18842 25323648 0 01000A0A

Подробнее со всеми изменениями можно ознакомиться в репозитории. Ссылка в конце статьи.

Наглядное представление работы (изменения в колонке с MAC-адресом):

Маршрутизатор

За основу взята программа IGMPProxy. Можно было взять любую другую, тот же mrouted. Очень важно, что все IGMP-сообщения отправляются от IP-адреса запрашивающего интерфейса, и нам ни что не мешает его использовать. Подробности изменений описывать смысла нет, их также можно найти в соответствующем репозитории. Главное то, что в управлении ядра появляются две новые команды, которые должна поддерживать программа:

Предупреждение

Стоит заметить, что такой подход не дает возможности отключать клиентов от групп за отсутствие от них Membership Report-запросов, так как, исходя из протокола IGMP, клиент, получивший от другого клиента такой запрос с той же группой, сам не отправляет аналогичный. Поэтому отключение возможно только после получения явного Leave Group-пакета.

Использование

Для включения новой возможности необходимо скомпилировать ядро с опцией CONFIG_IP_MUT=y
Для полноценной работы измененной IGMPProxy также необходимо включить CONFIG_SYSCTL_SYSCALL=y

Ссылки

Использованная литература

Rami Rosen «Linux Kernel Networking. Implementation and Theory»
Christian Benvenuti «Understanding Linux Network Internals»
Klaus Wehrle and Frank Pahlke «Linux Networking Architecture»

Если у кого-нибудь есть иной способ решения проблемы, прошу поделиться в комментариях.

Источник

Multicast routing для IPTV

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.

Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.

И вот незадача. Обычно в документации выкладывают все и сразу и для человека, впервые столкнувшегося с этой темой, не понятно с чего начать. Во время чтения pdf’ок я ловила себя на мысли, что было бы неплохо наткнуться где-нибудь на статью, которая могла бы коротким путем провести от теории к практике, чтобы понять с чего стоит начать и где заострить внимание.

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.

Введение

Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.

Какой вид трафика использовать для IPTV?

Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255.

Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.

Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).

Немного о том, как работает IGMP.

Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:

Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1”.

Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1”. А затем повторяет аналогичный запрос JOIN для нужного канала.

MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE. Для этого MR использует запрос QUERY.

Ответ абонента на этот запрос это MEMBERSHIP REPORT, который содержит список всех групп, в которых состоит клиент.

Настройка multicast routing.

Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.

Пример настройки роутеров MR1 и MR2.

Команда «ip multicast-routing» включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.

Остановимся чуть поподробнее на команде «ip pim sparse-mode«.

Про режимы протокола PIM и сам протокол.

PIM (Protocol Independent Multicast) — протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute” и “sh ip route” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений.

У протокола PIM существует два основных режима: разряженный (sparse mode) и плотный (dense mode). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы — PIM-SM и PIM-DM.

В нашей конфигурации на интерфейсах мы указали режим «ip pim sparse-mode«.

dense-mode Enable PIM dense-mode operation
sparse-dense-mode Enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………

В чем же разница?

PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.

PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.

Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.

Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.

Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S — source, G — group.

У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP — rendezvous point) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).

Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) — «*» символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.

Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.

Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):

Все остальные роутеры должны знать маршрут до RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1

Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста)?

Посмотрим, что будет происходить после настройки роутеров.

Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения

Для MR1:
%PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3

Для MR2:
%PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0

Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:

MR1#sh ip pim neighbor

PIM Neighbor Table
Mode: B — Bidir Capable, DR — Designated Router, N — Default DR Priority, S — State Refresh Capable

Не забываем про TTL.

В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.

Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.

Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.

MR2#sh ip traffic

IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………

Если этот счетчик быстро увеличивается, значит — проблема в TTL.

Show ip mroute

После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:

MR1# sh ip mroute

(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.

Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:

MR1#sh ip mroute

…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53

(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53

Стало видно, что приходят запросы на эту группу с порта Ethernet3.

RPF проверка

Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?

Для этого он выполняет проверку RPF (Reverse Path Forwarding) — проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.

Отследить, как источник проходит проверку RPF можно с помощью команды:

MR2#sh ip rpf 10.0.0.2

RPF information for? (10.0.0.2)
RPF interface: Ethernet0
RPF neighbor:? (10.10.10.1)
RPF route/mask: 10.0.0.0/24
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables

Ну, вот и появилась та статейка, которую я бы с удовольствием нашла, на начальном этапе изучения multicast routing’а для IPTV. Я не волшебник, я только учусь… Потому, с радостью выслушаю все пожелания, замечания и советы. А так же, очень надеюсь, что для кого-то она окажется полезной. =)

UPD: Разрешите представить ее. Елена Сахно — lena_sakhno

Источник

Транслировать multicast как unicast wifi что это

Многие интернет-провайдеры предоставляют услугу IPTV. А наши пользователи часто задают нам вопрос – как настроить IPTV телевидение для роутеров D-Link DIR или как включить в Wi-Fi маршрутизаторе D-Link DIR функцию мультикаст, благодаря которой вы сможете смотреть IPTV на своем домашнем компьютере.

Настроить IPTV для роутеров D-Link DIR с Windows 8, Windows 7, Windows XP и других операционных систем, очень просто. Достаточно выполнить несколько простых шагов, которые позволят вам настроить интернет телевидение.

Настройки, которые указаны в этой статье, подойдут для следующих интернет провайдеров:

Итак, в этой статье мы расскажем, как настроить IPTV телевидение для роутеров D-Link DIR.

Чтобы включить функцию multicast (ФйПиТиВи) в вашем роутере, необходимо через web-интерфейс роутера (ввести в окне браузера 192.168.0.1), зайти в меню: Home (Главная)> Wan и выбрать «IGMP Enabled». После чего следует нажать на кнопку/ссылку «Apply».

Затем, следует зайти в Advanced(Расширенные)> AdvancedNetwork (Дополнительные настройки) и нажать«EnableMulticastStream».
Затем нажмите на кнопку «Save Settings» (Сохранить настройки).

Вот и все, теперь вы знаете, как включить в Wi-Fi маршрутизаторе D-Link DIR функцию мультикаст и сможете наслаждаться просмотром телевизионных программ используя функцию IPTV. Приятного просмотра.

Мультикаст-рассылка — технология, позволяющая передавать одинаковый трафик группе хостов, тем самымм экономя пропускную способность канала. Например, в IPTv есть 3 потока для 100 хостов — канал СТС, ТНТ и МузТВ. Без мультикаст пришлось бы передавать каждому получателю отдельный поток трафика, что загрузило бы канал. С мультикаст мы передаем по одному уникальному потоку, в данном случае 3 потока.

Делиться на L3 Routing и L2 Multicast. На L3 работают PIM и ряд других (MOSPF, DVMRP…). На L2 работает IGMP.
PIM работает между маршрутизаторами.

Каждому каналу присваивается свой IP из диапазона Multicast-адресов 224.0.0.0/4. Когда один их хостов запускает ПО для просмотра каналов, то это ПО начинает прослушивать какой-то из этих IP-адресов, например 239.1.1.10. Другие хосты, которые хотят смотреть тот же канал, например, СТС, также начинают прослушивать этот IP. Также данное ПО назначает виртуальный Multicast MAC-адрес на всех этих хостах, который генерируется из данного multicast-адреса. Они всегда начинаются на 01-00-5E-xx-xx-xx.

Когда хост запускает приложение (например, плеер), IGMP формирует сообщение маршрутизатору.
— Membership Query
— Membership Report
— Leave / Join

IGMP Join. Пример: Хост 1 запускает VLC Player и говорит, что он хочет прослушивать мультикаст-трафик, который вещается на 239.1.1.10. Далее на сетевую карточку вешается multicast-макадрес как secondary и высылается сообщение IGMP Join. Высылается оно на адрес группы.

На данный момент маршрутизатор знает, что за интерфейсом е0/0 находится клиенты, которые слушают мультикаст-трафик 239.1.1.10.

Membership Query Маршрутизатор высылает IGMP Query для 239.1.1.10 на 224.0.0.1. «Есть ли кто живой в сети, кто прослушивает этот адрес 239.1.1.10?» Если никто не отвечает, то маршрутизатор прекращает передавать трафик на интерфейс, за которым были клиенты 239.1.1.10.
Если же клиенты ответили есть, то они отвечают на query сообщением IGMP Report. Хосты не отвечают на Query одновременно, а делают это по истечении таймера, который разный на всех хостах. Если маршрутизатор получил хоть один Report, то он продолжает отсылать трафик. Остальные хосты не отсылают Report в таком случае, потому как незачем это делать. Они просто сбрасывают свои таймеры.

Настройка IPTV через роутер | IPTV по Wi-Fi и проводное подключение

Выход хоста из группы Предположим, что на одном их хостов закрывают VLC Player, данный хост генерирует IGMP Leave и отсылает его на 224.0.0.1.
Получая такое сообщение, маршрутизатор высылает внутрь сети Query 239.1.1.10 чтобы узнать, есть ли активные клиенты. На хостах, которые получили этот Query, и какой-то хостс наименьшим таймером вышлет Report.

Есть аналоги IGMP — CGMP (Cisco Group Management Protocol) и RGMP (Router-port Group Management Protocol)

Если маршрутизатор не один, а несколько, то обработкой IGMP будет заниматься тот, у кого наименьший IP.

R7# ip multicast-routing //включаем глобальную поддержку Multicast R7# int e0/1.79 R7# ip pim dense-mode //включаем PIM на интерфейсе в сторону хостов

Просмотр таблицы Multicast — show ip mroute
ip igmp access-group позволяет ограничивать с помощью access-list группы, к которым возможно подключаться.

Format ЗаметкаAuthor rootCategories IGMP, Multicast, PIM

Проблема

Многоадресный трафик не проходит через коммутаторы Catalyst, даже внутри одной VLAN. На Рис.1 изображен типичный сценарий:

Рис. 1. Настройка сети с многоадресным источником и получателями

В данной настройке можно заметить, что получатель 1, который находится на одном коммутаторе с источником, получает многоадресный поток без затруднений. Однако получатель 2 не получает многоадресного трафика. Цель данного документа – устранить данную проблему.

Повторный обзор некоторый ключевых принципов многоадресной рассылки

До получения различных вариантов решения данной проблемы, вы должны четко представлять себе определенные принципы многоадресной рассылки уровня 2.

Настройка IP-TV на роутерах

В данном разделе описаны эти принципы.

Примечание. Если вы не хотите заниматься этим самостоятельно, передайте компьютерную сеть на ИТ аутсорсинг В данном разделе приведено простое и четкое объяснение, касающееся данной конкретной проблемы. Подробное объяснение этих терминов см. в разделе Дополнительные сведения данного документа.

Протокол IGMP

IGMP – это протокол, который обязывает конечные хосты (получатели) сообщить многоадресному маршрутизатору (опросчику IGMP) о намерении конечного хоста получать определенный многоадресный трафик. То есть, это протокол, использующийся между маршрутизатором и конечными хостами и позволяющий:

Маршрутизаторам запрашивать конечные хосты о потребности в определенном многоадресном потоке (запрос IGMP)

Конечным хостам сообщать и отвечать маршрутизатору о потребности в определенном многоадресном потоке (отчеты IGMP)

Функция отслеживания IGMP

Функция отслеживания IGMP – это механизм посылки многоадресного трафика только на те порты, к которым подключены получатели. Данный механизм увеличивает эффективность, так как он позволяет коммутатору уровня 2 избирательно рассылать многоадресные пакеты только на те порты, которые в них нуждаются. Без функции отслеживания IGMP маршрутизатор отправляет пакеты на каждый порт. Коммутатор следит за обменом сообщениями IGMP между маршрутизатором и конечными хостами. В данном случае коммутатор создает таблицу отслеживания IGMP, в которой присутствует список всех портов, которые запросили определенную группу многоадресной передачи.

Порт Mrouter

Порт mrouter – это порт с точки зрения коммутатора, который подключается к многоадресному маршрутизатору. Необходимо присутствие, по крайней мере, одного порта mrouter для работы коммутаторов по отслеживанию IGMP. Это требование подробно описано в разделе Общие сведения о проблеме и ее решения данного документа.

Многоадресная рассылка на L2

Любой IP-трафик версии 4 (IPv4) с IP-адресом назначения в диапазоне от 224.0.0.0 до 239.255.255.255 является многоадресным потоком. Все многоадресные пакеты IPv4 соответствуют предварительно определенному MAC-адресу IEEE с форматом 01.00.5e.xx.xx.xx.

Примечание. Функция отслеживания IGMP действует в случае, если MAC-адреса многоадресной рассылки соответствуют IEEE-совместимому MAC-диапазону. Согласно разработке данной функции, отслеживание некоторых зарезервированных диапазонов многоадресной рассылки не предполагается. Если не соответствующий критериям многоадресный пакет исходит из коммутируемой сети, он отправляется через эту VLAN, где расценивается как широковещательный трафик.

Wireless Multicast Forwarding — настройка WMF на ASUS

В тех случаях, когда необходимо подключить ТВ-приставку IPTV через беспроводную сеть WiFi и нет возможности настроить функцию udpxy — на помощью пользователям приходит функция Wireless Multicast Forwarding или сокращенно WMF.

Как включить функцию мультикаст в маршрутизаторах tp link

Смысл работы этой функции в том, что настройка multicast делается таким образом, что ТВ-поток транслируется по Wi-Fi с подменой аппаратного MAC-адреса на канальном уровне сети.
В беспроводных роутерах ASUS так же есть возможность настроить Wireless Multicast Forwarding на маршрутизаторе.

Для этого надо зайти в веб-интерфейс маршрутизатора. Затем, в главном меню выбираем раздел Беспроводная сеть, закладка Профессионально:

Прокручиваем страничку практически в самый конец и находим искомую строчку «​Wireless Multicast Forwarding» — в выпадающем списке значений параметра выбираем вариант Включить. Сохраняем настройки роутера ASUS и проверяем работу IPTV по беспроводной сети Вай-Фай.

Замечание: Если у Вас для работы цифрового интерактивного телевидения надо выделять отдельный LAN-порт или поток мультикаст подаётся на роутер в тегированном виде и надо дополнительно указывать VLAN ID — этот способ не подойдёт и для работы ТВ по Wi-Fi придётся покупать отдельное устройство — беспроводной мост.

Инструкции и советы:

Полезная информация:

Other versions:

Настройка IPTV на ASUS RT-N12, RT-N11P и RT-N10

&nbsp Asus | Билайн | Ростелеком

На сегодняшний день многие пользователи используют не только домашний Интернет от своего провайдера, но и телевидение IPTV.

Как настроить мультикаст

Эта инструкция предназначена для тех, кто разобрался с настройкой Wi-Fi роутера ASUS RT-N12, RT-N11P или RT-N10, но пока не настроил работу ТВ (впрочем, для других моделей маршрутизаторов ASUS путь будет тем же).

Перед настройкой подключите ТВ приставку к одному из разъемов LAN на тыльной стороне вашего роутера, после чего выполните следующие простые шаги.

Примечание: для некоторых популярных провайдеров, в частности для Ростелеком и Билайн для работы телевидения IPTV также может потребоваться включить опции:

Сделать это можно на той же странице настроек Wi-Fi роутера ASUS.

Возможно, вам также пригодятся полные инструкции:

Возможные проблемы при настройке Wi-Fi роутера

Udpxy — серверное приложение для передачи данных из сетевого потока мультикаст канала (вещаемого по UDP) в HTTP-соединение запрашивающего клиента.

Основная задача udpxy заключается в передаче данных, считанных из мультикаст-канала (рассылающего данные подписчикам по протоколу UDP), в клиентское соединение, работающее в протоколе TCP. Таким образом, клиент, не имея возможности работать с протоколом UDP, может послать запрос udpxy, установить TCP соединение и работать с данными, полученными из указанного (в изначальном запросе) мультикаст-канала. Такая возможность востребована при просмотре IPTV на мобильных устройствах, телевизорах с функциональностью SmartTV и игровых консолях.

Функция Udp Proxy на роутерах Keenetic II реализована в качестве отдельного компонента микропрограммы. Для установки данного компонента необходимо:

Обратите внимание!

Это конец? WiFi и IP-телевидение в multicast-потоке не совместимы?

Для корректной работы UDP Proxy необходимо отключить IGMP Proxy. Одновременная работа двух этих функций невозможна!Для этого проделываем следующее:

В случае использования настроек по умолчанию, udpxy-сервер будет работать в локальной сети по порту 4022, т.е. все клиенты должны обращаться по этому номеру TCP-порта.

Источник