+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Рабочий пример маршрутизации DLNA (базовый)

Рабочий пример маршрутизации DLNA (базовый), RouterOS

Chiverel

Guest

07.06.2018 21:44:00

Привет! На этот раз я пытаюсь разобраться с реализацией PIM-SM на устройстве Mikrotik. Здесь выкладываю базовую рабочую конфигурацию. Для тех, кому интересно, позже поделюсь подробностями в следующих постах. Надеюсь, эта настройка сэкономит кому-то время. Я не смог сразу найти понятные для себя ответы в соответствующих темах и примерах в wiki.

Моя тестовая лаборатория выглядит так:
Qnap NAS — источник контента (Prod)
Map2nd Windows 10 1803 ноутбук — потребитель контента (Cons)
Схема (кликабельна)

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

```
/interface bridge
add arp=enabled fast-forward=no name=Cons-Br protocol-mode=none
add arp=enabled fast-forward=no name=Prod-Br protocol-mode=none

/ip pool
add name=dhcp_pool0 ranges=192.168.0.10-192.168.0.20
add name=dhcp_pool2 ranges=192.168.1.10-192.168.1.20

/ip dhcp-server
add address-pool=dhcp_pool0 dhcp-option-set=cons-br-opts disabled=no interface=Cons-Br lease-time=2m name=dhcp1
add address-pool=dhcp_pool2 dhcp-option-set=prod-br-opts disabled=no interface=Prod-Br lease-time=2m name=dhcp2

/interface bridge port
add bridge=Cons-Br hw=no interface=ether1
add bridge=Prod-Br hw=no interface=ether2

/ip address
add address=192.168.0.1/24 interface=Cons-Br network=192.168.0.0
add address=192.168.1.1/24 interface=Prod-Br network=192.168.1.0

/ip dhcp-server network
add address=192.168.0.0/24 dns-none=yes gateway=192.168.0.1 netmask=24
add address=192.168.1.0/24 dns-none=yes gateway=192.168.1.1 netmask=24

/ip firewall address-list
add address=192.168.0.1 list=Bridges
add address=192.168.1.1 list=Bridges

/ip firewall mangle
add action=change-ttl chain=prerouting dst-address-type="" log-prefix=TTL+ new-ttl=set:64 passthrough=yes port=1900 protocol=udp
add action=change-ttl chain=prerouting new-ttl=set:64 passthrough=yes protocol=igmp

/ip upnp
set enabled=yes

/ip upnp interfaces
add interface=Cons-Br type=internal
add interface=Prod-Br type=internal

/routing pim bsr-candidates
add interface=Cons-Br

/routing pim interface
add interface=Cons-Br
add interface=Prod-Br

/routing pim rp
add address=192.168.1.1

/routing pim rp-candidates
add interface=Prod-Br
```

Не забудьте добавить статический маршрут на вашем медиасервере (у меня это NAS):
route add -net 224.0.0.0 netmask 240.0.0.0 gw 192.168.1.1 dev eth0

Помните про безопасность — ограничивайте правила мэнгла только необходимыми интерфейсами.

Spartacus

Guest

05.07.2018 12:37:00

Привет, ок, давай попробуем по «Sniffer»-способу:
Тестовое окружение:
VLAN60: планшет на Android с Kodi (лучше, чем телевизор, потому что крепится к стене)
VLAN60: ноутбук на Windows со Sniffer
VLAN10: ПК на Windows со Sniffer

Я вижу в VLAN60 M-Search пакеты от планшета на 239.255.255.255:9000. Но как мне найти эти пакеты на сниффере в VLAN10? Это # после отметки времени — идентификатор пакета#, который был отправлен и должен быть таким же в VLAN10? Если да, то пакеты не доходят до VLAN10.

С другой стороны, в VLAN10 я вижу M-Search пакеты с планшета, когда запускаю Kodi:
M-SEARCH * HTTP/1.1
MX: 5
ST: upnp:rootdevice
MAN: "ssdp:discover"
User-Agent: UPnP/1.0 DLNADOC/1.50 Platinum/1.0.5.13
Connection: close
Host: 239.255.255.250:1900

Но Twonky не отправляет ответ. Вот что я не понимаю.

И наоборот, никаких Notify пакетов от Twonky (они приходят в нерегулярных циклах) не поступает в VLAN60. Похоже, что Notify пакеты из VLAN10 не идут в VLAN60. Есть идеи, где это можно проверить?

Кристиан

Chiverel

Guest

05.07.2018 14:06:00

Это чертовски сложная часть. Вот как я это делаю: vlan10 с адресом 192.168.10.58 — это мой QNAP Ovpn-Bridge, к которому подключено Android-устройство через OpenVPN-TAP адаптер (L2) с активным IP 192.168.11.14.

Запускаю пакетный сниффер на vlan10:

/tool sniffer
set filter-interface=vid10-home-1G filter-ip-protocol=udp filter-operator-between-entries=and filter-port=1900 only-headers=yes

Или в WinBox (картинки кликабельны). Запускаю сниффинг (/tool sniffer start) или по кнопке в WinBox.

Запускаю на Android приложение “Slick Upnp” и нажимаю иконку «Обновить».
Жду несколько секунд.
Останавливаю сниффер на MikroTik.
Просматриваю пакеты (/tool sniffer packet print).

Можно увидеть 4 похожих пакета подряд. Это соответствует требованию UPnP несколько раз повторять M-SEARCH, потому что сообщение идет по UDP и доставка не гарантируется. Это значит, что мой vlan10 (но не целевой интерфейс с DLNA-сервером) получил Search сообщение от удалённого Android-устройства.

Дальше меняю интерфейс, чтобы посмотреть противоположную сторону настройки PIM. Здесь сниффлю интерфейс, который является членом моста (например, граничный интерфейс на моём роутере, думаю, на самом мосту будет похожая картина).

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

Spartacus

Guest

05.07.2018 15:01:00

Привет, большое спасибо за вашу поддержку, это действительно здорово! Вот результаты работы Sniffer Tool:

Sniffer в VLAN10 — вы можете видеть Notify-пакеты от DLNA-сервера, а также Search-пакеты из VLAN40 и VLAN60.

Sniffer в VLAN40 и VLAN50 — вы видите Search-пакеты, но Notify-пакеты из VLAN10 отсутствуют. Это значит, что Notify-пакеты не проходят из VLAN10 в VLAN40/VLAN60.

VLAN40

VLAN60

Это проблема с PIM или с Multicast в правилах файрвола?
Christian

Spartacus

Guest

05.07.2018 15:15:00

Привет, заметил кое-что интересное, может, у тебя есть идея, как это решить: я подключил андроид к VLAN10 — всё работает. Потом подключил планшет к VLAN60, не закрывая при этом приложение Slik UPnP, и смог получать потоки с DLNA. Но как только закрываешь приложение на планшете, DLNA-сервер уже не находится... ...и вот неожиданно! Иногда кажется, что всё работает, и DLNA находится и в VLAN60, и в VLAN40. Это занимает несколько минут, но потом всё начинает работать! Есть идеи, как это ускорить? Сейчас проверю с телевизором и потом вернусь к тебе. Кристиан

Spartacus

Guest

04.07.2018 19:45:00

Привет, нет, Windows ПК в VLAN40 не видит DLNA-сервер на QNAP. Я могу видеть только сам QNAP и веб-интерфейс Twonky. Но если пытаюсь открыть фильм, ничего не происходит. Пробовал также с Kodi на Android — DLNA-сервер найти не удаётся! Проблема не в телевизоре! Как только подключаю планшет к VLAN10, DLNA-сервер появляется. Christian

Spartacus

Guest

04.07.2018 10:55:00

Всем привет! Я наткнулся на эту тему, потому что у меня похожая проблема. Может, кто-то поможет с такой конкретной настройкой, а то я слегка запутался. У меня на qnap в VLAN10 работает Twonky DLNA-сервер. Клиенты (например, Samsung TV) — в VLAN40. Оба VLAN находятся на одном мосту с фильтрацией VLAN. Всё работает, если оба устройства в одном VLAN-подсети. Я установил PIM и добавил интерфейсы VLAN10 (172.16.10.0/24) и VLAN40 (172.16.40.0/24), но ничего не меняется. Что нужно ещё сделать, чтобы Twonky DLNA-сервер в VLAN40 стал виден? Заранее спасибо, Кристиан.

Chiverel

Guest

04.07.2018 11:20:00

Привет, что показывает следующая команда? /routing pim mfc print detail Там должна быть запись со следующими значениями: правильная группа (я полагаю, это должна быть 239.255.255.250), VLAN10 как интерфейс вверх по потоку, VLAN40 как интерфейс вниз по потоку. У тебя задан RP? Видишь ли ты IP-адреса твоих устройств, которые присоединились к этому RP, в /routing pim join print? Есть ли у тебя правила фаервола? Позволяют ли они мультикаст-трафик? Можешь использовать Device Sniffer, как показано выше, чтобы проверить, получаешь ли ты пакеты Upnp в обеих VLAN. У меня похожая настройка, кроме того, что один интерфейс PIM — это VLAN, а другой — мост с VPN-интерфейсом. И я успешно принимаю DLNA через VPN-соединение.

Spartacus

Guest

04.07.2018 12:03:00

Привет, Chiverel, спасибо за быстрый ответ! Я тоже использую PIM для своей Sonos-сети, и всё работает. Плееры находятся в vlan30, контроллер — в vlan10 и vlan60 (но, похоже, vlan60 не нужен для PIM). Вот лог:

/routing pim mfc print detail
group=239.255.255.250 source=172.16.10.10 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40
group=239.255.255.250 source=172.16.10.20 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40
group=239.255.255.250 source=172.16.30.11 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40
group=239.255.255.250 source=172.16.30.34 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40
group=239.255.255.250 source=172.16.30.36 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40

####

/routing pim join print
Flags: RP - (*,*,RP), WC - (*,G), SG - (S,G), SG_rpt - (S,G,rpt)
GROUP SOURCE RP
WC 224.0.0.0 172.16.30.1 172.16.30.1
WC 224.0.0.0 172.16.40.1 172.16.40.1
SG 224.0.1.60 0.0.0.0 172.16.40.1
SG 239.255.255.246 0.0.0.0 172.16.40.1
SG 239.255.255.250 0.0.0.0 172.16.30.1
SG_rpt 239.255.255.250 172.16.10.10 172.16.30.1
SG_rpt 239.255.255.250 172.16.10.20 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.10 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.11 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.34 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.36 172.16.30.1

Interface-Lists:
/interface list member add interface=vlan10 list="Sonos Control" comment=SONOS
/interface list member add interface=vlan60 list="Sonos Control" comment=SONOS

Правила файрвола для Sonos:
/ip firewall filter add action=accept chain=forward dst-address=239.255.255.250 comment="SONOS: forward Multicast traffic"
/ip firewall filter add action=accept chain=forward dst-port=1400,4444,4070 in-interface-list="Sonos Control" out-interface=vlan30 protocol=tcp comment="SONOS: forward Controller events to Players"
/ip firewall filter add action=accept chain=forward dst-port=3400,3401,3500,4070 in-interface=vlan30 out-interface-list="Sonos Control" protocol=tcp comment="SONOS: Forward Controller events from Players"
/ip firewall filter add action=accept chain=forward dst-port=1900,1901,5353,6969 in-interface=vlan30 out-interface-list="Sonos Control" protocol=udp comment="SONOS: Forward UPnP Device Discovery events from Players"

По поводу Device sniffer: я не совсем понимаю, как его запускать, но, наверное, нужно включить UPnP на RB3011, так? Что ты имел в виду? Извини за глупые вопросы, я в этом не эксперт.

Огромное спасибо,
Christian

Chiverel

Guest

#10

04.07.2018 12:47:00

Я тоже не специалист, но немного изучал PIM. Вижу, что у тебя настроено 2 RP. Полагаю, что в твоей конфигурации должен быть только 1 RP — 172.16.30.1. Можешь выкладывать свой /routing pim export?

Кроме того, нужно разрешить трафик SSDP из VLAN40, как ты сделал для VLAN30. Верю, что DLNA использует хотя бы SSDP udp/1900 для обнаружения устройств. Значит, этот трафик должен доходить до интерфейса VLAN40 (я так понимаю, 172.16.40.1).

Что касается устройства sniffer — тебе нужно скачать эту программу, запустить её на каком-то ПК/виртуальной машине/чём угодно с подключением к VLAN40. Так ты сможешь посмотреть, какие UPnP сообщения появляются в этой сети. Потом сделай то же самое на VLAN30.

Можно запустить процесс поиска устройств через меню Search: поиск всех устройств, поиск по конкретному типу → AV media servers. Со временем появятся разные UPnP сообщения и ответы на них. Обрати внимание, с какого IP приходят эти сообщения. В итоге ты должен увидеть сообщения из диапазона IP VLAN30, когда подключён к VLAN40, и наоборот.

Особенно внимательно смотри на сообщения NOTIFY с заголовками NT. Если этого не происходит, возможно, проблема в фаерволе или TTL. Можно использовать рабочую настройку VLAN30, чтобы понять, какие сообщения должны появляться.

Spartacus

Guest

#11

04.07.2018 18:23:00

Привет, это снова я. Немного расстроен, потому что ничего не работает. Телевизор и «Сетевое окружение» Windows не видят Twonky-сервер на QNAP. Я могу зайти в веб-интерфейс Twonky с Windows (172.16.10.10:9000).

Что я сделал:
- Добавил правило в цепочку forward с дополнительными UDP-портами (похоже, это нужно для Twonky; пробовал правило и в цепочке input, но без успеха, думаю, это мне не нужно).
- Также разрешил полную коммуникацию между vlan10 и vlan40 (vlan10 и vlan40 входят в VlanFriends).

Экспорт маршрутизации/pim:
DeviceSniffer на Windows в vlan40 показывает, что я получаю UPnP-пакеты, но я не понимаю, что именно вижу.

Правила фаервола:
/ip firewall filter add action=passthrough chain=forward dst-address-type=multicast port=1900,1080,9080 protocol=udp
/ip firewall filter add action=accept chain=forward dst-address-list=VlanFriends in-interface-list=LAN src-address-list=VlanFriends comment="Allow inter VLAN communication with VLAN friends"

Экспорт PIM:
/routing pim interface
add comment="Sonos player" interface=vlan30
add comment=IPTV interface=vlan40
add interface=vlan10

/routing pim rp
add address=172.16.30.1

Лог Device Sniffer:

Может, у вас есть идея, что еще я могу попробовать?
Кристиан

Chiverel

Guest

#12

04.07.2018 18:52:00

Хорошее замечание. Когда вы подключаете ваш Windows-хост к VLAN40, видит ли он ваш Qnap NAS? Например, если запустить стандартный Windows Media Player, появляется ли Twonky? Обычно он отображается как запись «HDHome…» на изображении ниже. Я просто интересуюсь, может ли проблема быть в самом телевизоре. Работает ли он, если подключить его напрямую к VLAN30? Судя по изображению, которое вы показываете, IP-адрес Twonky — 172.16.10.10, и он отображается как медиасервер. Значит, по моему пониманию, настройка PIM работает правильно. Что еще можно проверить? Как ваш телевизор подключен к VLAN40? Это проводное или беспроводное соединение? Вы настроили этот порт как access-порт в VLAN?

Chiverel

Guest

#13

04.07.2018 21:20:00

Ты можешь использовать приложение «slick upnp» на Android, чтобы видеть DLNA-устройства. Работает супер. У меня наоборот вопрос. Когда ты запускаешь этот сниффер в vlan10, видишь ли ты сообщения из vlan40? Есть ли какие-то ошибки или предупреждения в логе Mikrotik по теме PIM? Не мог бы ты снова поделиться деталями по PIM после внесённых изменений? Мне бы хотелось проверить интерфейсы, mrib, mfc, joins и igmp-группы.

Chiverel

Guest

#14

04.07.2018 21:25:00

Кстати, когда я подключаюсь через VPN, мой NAS тоже не отображается в сетевом окружении. Но он появляется в Windows Media Player спустя какое-то время, когда заканчивается период обновления. Это может занять пару минут. То же самое с VLC. Очень важно установить соединение как приватное, чтобы использовать DLNA в Windows.

Spartacus

Guest

#15

05.07.2018 05:34:00

Привет, сегодня я проверю Sniffer в vlan10. Кстати, Android-планшет в VLAN60. Подробности PIM: Флаги: RP - (*,*,RP), WC - (*,G), SG - (S,G), SG_rpt - (S,G,rpt)
ГРУППА ИСТОЧНИК RP
WC 224.0.0.0 172.16.30.1 172.16.30.1
SG 224.0.1.1 0.0.0.0 172.16.30.1
SG 224.0.1.60 0.0.0.0 172.16.30.1
SG 239.255.255.250 0.0.0.0 172.16.30.1
SG_rpt 239.255.255.250 172.16.10.10 172.16.30.1
SG_rpt 239.255.255.250 172.16.10.20 172.16.30.1
SG_rpt 239.255.255.250 172.16.10.30 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.11 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.21 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.22 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.31 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.33 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.34 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.35 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.36 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.41 172.16.30.1
SG_rpt 239.255.255.250 172.16.30.50 172.16.30.1
SG_rpt 239.255.255.250 172.16.40.100 172.16.30.1
SG_rpt 239.255.255.250 172.16.60.198 172.16.30.1

/routing pim mfc print detail
group=239.255.255.250 source=172.16.10.10 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40,vlan60
group=239.255.255.250 source=172.16.10.20 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40,vlan60
group=239.255.255.250 source=172.16.10.30 rp=172.16.30.1 upstream-interface=vlan10 downstream-interfaces=vlan30,vlan40,vlan60
group=239.255.255.250 source=172.16.30.12 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60
group=239.255.255.250 source=172.16.30.21 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60
group=239.255.255.250 source=172.16.30.31 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60
group=239.255.255.250 source=172.16.30.33 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60
group=239.255.255.250 source=172.16.30.35 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60
group=239.255.255.250 source=172.16.30.36 rp=172.16.30.1 upstream-interface=vlan30 downstream-interfaces=vlan10,vlan40,vlan60
group=239.255.255.250 source=172.16.40.100 rp=172.16.30.1 upstream-interface=vlan40 downstream-interfaces=vlan10,vlan30,vlan60
group=239.255.255.250 source=172.16.60.198 rp=172.16.30.1 upstream-interface=vlan60 downstream-interfaces=vlan10,vlan30,vlan40

Но что ты имеешь в виду под: «Важно установить соединение как приватное, чтобы использовать DLNA в Windows.»? У меня с Windows-клиентами в VLAN10 проблем нет, DLNA работает отлично. Трудности только в разных подсетях. Спасибо, Christian

Chiverel

Guest

#16

05.07.2018 06:42:00

Хорошо, теперь я вижу, что ваше устройство с IP 172.16.40.100 подключено к тому же RP и группе 239.255.255.250, что и ваш медиасервер и другие работающие клиенты. Апстрим и даунстрим тоже определяются корректно. Это позволяет предположить, что PIM настроен правильно, и проблема может быть в другом месте, если только лог не подскажет нам, в чём дело. Есть ли какие-нибудь записи по PIM? Под "другим местом" мы можем проверить, получает ли VLAN10 сообщения из VLAN40. Даже если вы разрешили весь трафик между этими VLAN, могут быть проблемы в зависимости от топологии.

Spartacus

Guest

#17

05.07.2018 08:50:00

Привет, я проверил Sniffer в VLAN10:
Ты можешь увидеть запрос с моего Android-планшета в vlan60 (172.16.60.199), и, похоже, что соединение разрывается. Не знаю, правильно ли это, но, кажется, есть какая-то проблема.

Я также отключил роутер от WAN и выключил все правила фаервола, кроме DLNA-Multicast passthrough… и это не работает! В логах никаких проблем тоже не видно.

Похоже, что проблема в самой конфигурации vlan, но почему тогда мой Sonos играет через подсети?

Christian

Chiverel Guest	#18 0 05.07.2018 11:06:00 Я не совсем уверен, но это может быть проблема с TTL у некоторых пакетов. Sonos может отправлять пакеты с большим TTL, чем другие устройства, поэтому именно его пакеты действительно проходят дальше. Это не те правила mangle, которые я выкладывал в первых сообщениях. Подкорректируйте их и убедитесь, что они применяются только к нужным интерфейсам. /ip firewall mangle add action=change-ttl chain=prerouting dst-address-type="" log-prefix=TTL+ new-ttl=set:64 passthrough=yes port=1900 protocol=udp add action=change-ttl chain=prerouting new-ttl=set:64 passthrough=yes protocol=igmp Если это тоже не поможет, то другого варианта, кроме как детально исследовать проблему с помощью сниффера устройства, нет. Вот информация для изучения: Глава «Upnp discovery» Discovery Когда устройство с поддержкой UPnP подключается к сети и хочет узнать, какие UPnP-сервисы доступны, оно отправляет сообщение обнаружения на мультикаст-адрес 239.255.255.250 через порт 1900 по UDP. Это сообщение содержит заголовок, похожий на HTTP-запрос. Этот протокол иногда называют HTTPU (HTTP поверх UDP): M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: ssdp:discover MX: 10 ST: ssdp:all Все остальные UPnP-устройства или программы должны ответить на это сообщение, отправив похожее сообщение обратно устройству, используя UDP unicast, сообщая, какие UPnP-профили оно поддерживает. Интересная особенность: ответ идет по UDP unicast на тот же порт, с которого пришло сообщение обнаружения. Для каждого профиля отправляется отдельное сообщение вида: HTTP/1.1 200 OK CACHE-CONTROL:max-age=1800 EXT: LOCATION: http://10.0.0.138:80/IGD.xml SERVER: SpeedTouch 510 4.0.0.9.0 UPnP/1.0 (DG233B00011961) ST: urn:schemas-upnp-org:service:WANPPPConnection:1 USN: uuid:UPnP-SpeedTouch510::urn:schemas-upnp-org:service:WANPPPConnection:1 Выше пример чуть подправленного ответа, который отправляет модем Alcatel/Thomson Speedtouch ADSL, поддерживающий профиль WANPPPConnection. С определенной периодичностью устройства и программы с поддержкой UPnP обязаны отправлять сообщения для объявления своих сервисов. Нотификационное сообщение по сути похоже на ответ на запрос обнаружения, но отправляется на UPnP-мультикаст 239.255.255.250 по порту 1900 по UDP, и заголовок ST заменен на похожий заголовок под названием NT. Далее идет понятная схема. Источник — или настоящий продвинутый документ, в котором стоит прочитать, как минимум, главы 1.3.2 «Запрос поиска M-SEARCH» и 1.3.3 «Ответ на поиск». Вам нужно убедиться, что эти M-SEARCH сообщения генерируются в исходной сети, где находится DLNA-приемник (VLAN40), проходят через роутер и видны в вашей сети с DLNA-сервером (VLAN10). Затем проверить, что ответы от VLAN10 видны также в VLAN40. Я использовал сниффер, чтобы понять, какой участок отсутствует и где именно. Если сниффер не показывает никаких сообщений, зайдите в роутер и с помощью torch (монитора трафика) на входных и выходных портах/VLAN определите, где теряются пакеты. Затем примените свои знания, чтобы исправить потерю, если потребуется. Для упрощения расследования отключите или выключите ненужные устройства с UPnP во время проверки, чтобы не завалиться сообщениями, которые вам не нужны. Боюсь, это всё, чем могу помочь. У меня не так много опыта и уловок, чтобы подсказать, как сузить круг поиска проблемы.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры