Перестал работать IPTV

[kosyak_kpol]

1. Последний лог не валидный, так как вы неправильно задали подсеть. У вас: 172.21.0.0/24 а нужно было: 172.21.0.0/16
Поэтому тут наблюдается отказ присоединения группы мультикаста от источника, например:

Sep/18/2020 18:42:09 igmp-proxy,debug ignoring request from unknown address - "alternative-subnets" configuration may be required:
Sep/18/2020 18:42:09 igmp-proxy,debug source=172.21.255.99
Sep/18/2020 18:42:09 igmp-proxy,debug destination=224.10.10.3

Этот лог рассматривать нет смысла.


2. Первый лог с альтернативной подсетью 0.0.0.0/0 . Смотрим:

Sep/18/2020 18:35:20 igmp-proxy,debug RECV IGMPv2 membership report from 192.168.88.32 to 224.10.10.4 on bridge
Sep/18/2020 18:35:20 igmp-proxy,debug adding multicast forwarding entry
Sep/18/2020 18:35:20 igmp-proxy,debug group: 224.10.10.4
Sep/18/2020 18:35:20 igmp-proxy,debug source: 172.21.255.99
Sep/18/2020 18:35:20 igmp-proxy,debug joining multicast group 224.10.10.4 on bridge1

Здесь, хост 192.168.88.32 запросил членство в группе 224.10.10.4 из локального бриджа bridge. На что, в итоге, добавилась запись на форвардинг и присоединение к этой мультикаст-группе (от источника 172.21.255.99) на вашем WAN-интерфейсе - bridge1. Прокси нормально отработал.

Sep/18/2020 18:35:20 igmp-proxy,debug RECV IGMPv2 membership report from 192.168.88.32 to 224.10.10.4 on bridge
Это, возможно, отчёт хоста 192.168.88.32 о продлении подписки на группу 224.10.10.4 из локального бриджа.

Через две секунды вы запросили другой канал:

Sep/18/2020 18:35:22 igmp-proxy,debug RECV IGMPv2 membership report from 192.168.88.32 to 224.10.10.1 on bridge
Sep/18/2020 18:35:22 igmp-proxy,debug adding multicast forwarding entry
Sep/18/2020 18:35:22 igmp-proxy,debug group: 224.10.10.1
Sep/18/2020 18:35:22 igmp-proxy,debug source: 172.21.255.99
Sep/18/2020 18:35:22 igmp-proxy,debug joining multicast group 224.10.10.1 on bridge1
и то же успешно.

Здесь, вероятно, завершение форвардинга канала 224.10.10.3 по тайм-ауту, с которого "ушёл" подписчик (ещё ранее):
Sep/18/2020 18:35:27 igmp-proxy,debug removing multicast forwarding entry
Sep/18/2020 18:35:27 igmp-proxy,debug group: 224.10.10.3
Sep/18/2020 18:35:27 igmp-proxy,debug source: 172.21.255.99

Остальные строки в этом логе - мусор, который IGMP-proxy игнорирует.
Первое впечатление такое, что с "альт-подсетью" 0.0.0.0/0 прокси работает нормально - всё что надо - проксирует. К группам мультикаста от источников присоединяется и разрешает их форвардинг.

3. Второй лог для 172.21.255.0/24

Sep/18/2020 18:40:27 igmp-proxy,debug RECV IGMPv2 membership report from 192.168.88.32 to 224.10.10.1 on bridge
Sep/18/2020 18:40:27 igmp-proxy,debug joining multicast group 224.10.10.1 on bridge1
.
Sep/18/2020 18:40:27 igmp-proxy,debug received notification:
Sep/18/2020 18:40:27 igmp-proxy,debug source=172.21.255.99
Sep/18/2020 18:40:27 igmp-proxy,debug destination=224.10.10.1
Sep/18/2020 18:40:27 igmp-proxy,debug adding multicast forwarding entry
Sep/18/2020 18:40:27 igmp-proxy,debug group: 224.10.10.1
Sep/18/2020 18:40:27 igmp-proxy,debug source: 172.21.255.99
Sep/18/2020 18:40:27 igmp-proxy,debug RECV IGMPv2 membership report from 192.168.88.32 to 224.10.10.1 on bridge
Sep/18/2020 18:40:28 igmp-proxy,debug sending IGMP query to 224.0.0.1 on bridge
Sep/18/2020 18:40:28 igmp-proxy,debug RECV IGMPv2 membership report from 192.168.88.35 to 239.255.255.250 on bridge
Sep/18/2020 18:40:28 igmp-proxy,debug RECV IGMPv2 membership report from 192.168.88.2 to 239.192.152.143 on bridge
Sep/18/2020 18:40:28 igmp-proxy,debug joining multicast group 239.192.152.143 on bridge1
Здесь тоже не вижу проблем - всё обычно.

А тут - запрос членства в группе 224.0.0.1, пришедший от источника:
Sep/18/2020 18:40:30 igmp-proxy,debug RECV IGMP membership query from 172.21.0.14 to 224.0.0.1 on bridge1
Sep/18/2020 18:40:30 igmp-proxy,debug ignoring IGMP message: received on the upstream interface
..., который прокси проигнорировал? Но и источник "не помещается" в 172.21.255.0/24. Не знаю, как это трактовать.

В этом логе ещё наблюдаются:
Sep/18/2020 18:40:32 igmp-proxy,debug received notification:
Sep/18/2020 18:40:32 igmp-proxy,debug source=172.21.255.99
Sep/18/2020 18:40:32 igmp-proxy,debug destination=224.10.10.4

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

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

[kosyak_kpol]

Вангую - от провайдера вы ничего не добьётесь

[Chupaka]

Есть возможность проверить с собственным стримером (VLC)? А то у меня дома один ноутбук, и на телефоне VLC не хочет к udp://@-каналам даже пробовать подключаться...

[kosyak_kpol]

nefrid12, пока ждём ответа от провайдера, сделайте доброе дело, добавьте у себя:

/ip firewall raw add action=notrack chain=prerouting dst-address-type=multicast

Это - чтобы я уже "узбагоился". Правило гарантированно пустит входящий и транзитный мультик мимо вашего файервола. И посмотрите торчем, есть ли у вас трафик мультика в локальном бридже. Меня не покидает ощущение, что у вас нет форвардинга запрашиваемого потока именно в bridge. Ну, и пробовать с альт-подсетью: 0.0.0.0/0. В случае неудачи, - с 172.21.0.0/16

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

[kosyak_kpol]

И ещё, пожалуйста, сделайте с роутера traceroute до 172.21.255.99 и 172.21.0.14
Интересно, что покажет.

[nefrid12]

Есть возможность проверить с собственным стримером (VLC)? А то у меня дома один ноутбук, и на телефоне VLC не хочет к udp://@-каналам даже пробовать подключаться...

Имеется в виду локально запустить стрим и локально же просмотреть?

[nefrid12]

И ещё, пожалуйста, сделайте с роутера traceroute до 172.21.255.99 и 172.21.0.14
Интересно, что покажет.

Screenshot_8.png

Screenshot_9.png

/ip firewall raw add action=notrack chain=prerouting dst-address-type=multicast
добавил, не показывает.

Торч на бридже по 1234 порту ничего не показывает, по igmp
это во время переключение, потом ничего, пока не переключаешь канал.

Screenshot_10.png

[nefrid12]

Screenshot_11.png

А это на бридже с wan, к которому подключена приставка, по сути напрямую

[kosyak_kpol]

Торч на бридже по 1234 порту ничего не показывает, по igmp
это во время переключение, потом ничего, пока не переключаешь канал.
[/quote]

Не надо было фильтровать по igmp. Меня интересует udp-поток (ну, можно с фильтром по порту: 1234). IGMP-протокол там ходит нормально. Это понятно из отладочного лога по IGMP-proxy. Полагаю, что udp-потока на бридже нет. Это, с моей точки зрения, и есть "корень зла" - фактически нет форвардинга потока с WAN-интерфейса в локальный бридж. Причём, прокси говорит, что он его форвардит. Дропнуть поток может файервол. Потому и просил добавить правило, пускающее мультикаст мимо файервола. Правило не помогло, значит точно "дело не в бабине" (не в файерволе). К тому же, "мой" поток, который вы забирали через pptp, форвардится нормально.

Пока конструктивных предложений нет. Если ещё не надоело, можно пробовать добавить статический маршрут в igmp-proxy:

/routing igmp-proxy mfc add source=172.21.255.99 upstream-interface=bridge1 downstream-interface=bridge group=224.10.10.1 disabled=no

и запросить плейером "Первый канал". Но, - мало шансов.

[kosyak_kpol]

Что касается предложения ув. Chupaka, то здесь, наверное, такая идея:

нужно на отдельном компе или ноуте сконфигурировать VLC на вещание мультикастом в группе (например, 224.10.10.1:1234) какого-нибудь видеофайла. На этот комп навесить статический IP (например, 172.21.255.99/16) и воткнуть его на WAN-интерфейс роутера ВМЕСТО провайдера. С другого компа в локалке смотреть или тем же VLC по ссылке udp://@224.10.10.1:1234, или IPTV-плейером -> "Первый канал" (для адресов из примера) из вашего текущего плейлиста. Наверное, потребуется в роутер добавить статический маршрут к источнику 172.21.255.99 через bridge1.

Ещё есть утилитка mcast.exe, с помощью которой можно организовать вещание мультикастом в нужной группе (вместо VLC). Тут могут быть нюансы. Скорее всего, потребуется найти "киношку", записанную с постоянным битрейтом (см. можно Mediainfo), и в mcast.exe выставить этот битрейт.

Целью эксперимента является ответ на вопрос будет ли igmp-proxy форвардить udp-поток от этого "надёжного" источника.
Возможно, я не понял ни целей, ни средств - лучше подождать пояснений мэтра.

P.S. от 20/09/2020 чуток исправил адресок маршрута.

[kosyak_kpol]

Теперь, что касается трассировки источников мультикаста. У моего провайдера источники пингуются и, соответственно, трассируются. Первым хопом является провайдерский DHCP, вторым - некий "промежуточный" сервер (всегда один и тот же), а уже третьим - сам источник. То есть, с трассировкой моя и ваша ситуация отличаются кардинально. Здесь я ничего не могу предположить дельного, кроме как - поставить тот D-Link, что работает и пробовать с него трассировать. Если трассировка и/или пингу пойдут, то смотреть его маршруты. И сравнивать.

P.S. от 20.09.2020. В аспекте "разборок" с трассировкой, можно добавить в роуты (основную таблицу) статический маршрут до источника мультикаста, например, до 172.21.255.99/32 через bridge1 и посмотреть, начнёт ли трассироваться\пинговаться этот источник. А если начнёт, то проверить, пошла ли "картинка" от какого-нибудь канала этого источника. Например, "Первого канала". Это я уже гадаю "на кофейной гуще"

[Chupaka]

Да, именно так, цель моего предложения - именно проверить, что IGMP Proxy нормально работает с таким Src-адресом. Ведь объективно, это - всё, что принципиально поменялось в сравнении со старой схемой...

А вот трассировка вообще не имеет значения, она ж юникастом идёт, а нас мультикаст интересует. Более того, на роутер-то он приходит, так что проблема определённо локальная.

[kosyak_kpol]

Собрал я макет по проверочной схеме, предложенной ув. Chupaka.

Кстати, роутер взял точно такой же, как ваш... И, в итоге, получил точно такую же "картину маслом", как и у вас. На WAN udp-поток приходит, динамический маршрут в IGMP-proxy появляется, а в бридже: "тишина... и мёртвые с косами стоят".

Из того, что уже опробовано вами, так же ничего не помогло. Пришлось подумать и .... добавить в Мангл правило:

chain=prerouting action=change-ttl new-ttl=increment:1 passthrough=yes dst-address=224.0.0.0/4 log=no log-prefix=""

После этого, давно известного "колдовства" от "жадных провайдеров", в моём макете всё "заколосилось". Попробуйте и вы у себя.

P.S. Спасибо мэтру за хорошую "проверочную" идею. Я, по крайней мере, кое-что переосмыслил.
PP.SS. Достаточно инкрементировать TTL на единицу - исправил правило.

[Chupaka]

Семён Семёнович, ну!..

Вот что значит уже три года как из провайдинга ушёл... TTL - первое, на что надо было обратить внимание!

kosyak_kpol, спасибо за расследование (как хорошо совпало, что у VLC по умолчанию TTL единичка)

[kosyak_kpol]

.. как хорошо совпало, что у VLC по умолчанию TTL единичка

Верно, - я тоже об этом сразу подумал. Очень удачно...

[nefrid12]

Ну точно, я думал что можно через mangle, но не знал как. kosyak_kpol, Chupaka спасибо огромное за помощь. Заработало в общем.

[sugar]

Столкнулся со сложностями настройки iptv вроде всё просто на словах и по ютубу.

Подскажите в чем дело:
правила файрвола настроены.
на порт приходит iptv трафик, torch видит все мультикастовые группы на порту.
порт не входит ни в какой бридж, порт сам по себе.
Я настраиваю IGMP Proxy апстрим этот самый порт, даунстрим бридж локальной сети (192.168.0.0/24)
нет возможности проверить работу из бриджа прям на месте, роутер в другом городе у родственников.
дальше я подключаюсь к роутеру по l2tp/ipsec в настройках указываю бридж локальной сети и ожидаю, что мультикаст будет ходить.

и как то можно проверить мультикаст с роутера ?
есть ли какие нибудь особенности с l2tp и мультикастом?

[Chupaka]

Вы бридж в настройках профиля l2tp указываете? Подключаетесь другим микротиком?

[sugar]

да, бридж указываю.
подключаюсь не микротиком, а ПК с windows 10.

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

на соседнем форуме ответили, что Multicast doesn't transit a routing layer (as needed with L2TP) without help.
а помощь, это igmp proxy или pim sm.

[Chupaka]

Что-то помнится мне, что Windows не очень-то поддерживает BCP, нужный для такого бриджа: https://wiki.mikrotik.com/wiki/Manual:B ... _bridging)

Ну и тут вот https://wiki.mikrotik.com/wiki/Manual:P ... r_Profiles написано, что оба конца L2TP-тоннеля должны быть в бриджах, чтобы схема заработала.

[sugar]

хм, спасибо за инфу.
Интересно а в linux можно создать l2tp в bcp режиме ?
я тестирую в windows но хочу записывать трансляции в линукс, каких нибудь программ, чтобы потом смотреть.

т.е. поток мультикаст мне нужно забрать в линукс через l2tp ( ну или любой другой впн )

и ещё один момент. после подключения по l2tp у бриджа адрес 192.168.88.1 и он пингуется с клиента l2tp из windows т.е.
а вот если запустить tools-ping и выбрать интерфейс как бридж и пинговать ип клиента l2tp (192.168.88.100) то пинг не работает...

[Chupaka]

А этот клиент вообще в бридж добавляется? В Bridge -> Ports

[sugar]

нет, после подключения появляется новый интерфейс <l2tp-user1> и на этом всё. внутри бриджа ничего нет.

Сейчас попробую настроить l2tp так, чтобы обе точки были в бридже. т.е. с микротика chr в виртуалке настрою подключение к этому микротику. посмотрю как сработает настройка бриджа в l2tp (l2 transport protocol, который блин этот самый l2 и не пробрасывает ... капец, у меня разрыв шаблона, я свято верил в то, что он сможет это сделать при выборе стека технологий)

[sugar]

проверил теорию с пробросом мультикаста когда оба пира в бридже.
да! именно так!
когда l2tp в бридже на сервере и l2tp в бридже на клиенте, мультикаст доставляется без проблем. только весь канал забивает.

Можно же фильтровать мультикастовые группы и отправить в l2tp только пару каналов ?

[sugar]

а что может не нравится igmp proxy.
на вкладке mfc она видит группу и источник сигнала, а апстрим и даунстрим unknown ? это на том роутере куда приходит мультикаст.