IPtv multicast
-
с первой строчкой?
-
Копался вот что вышло
Debu: Aging Origin 192.168.0.99 Dst 239.255.255.250 PktCnt 1 -> 1
Debu: Origin 192.168.0.99 Vif bits : 0x00000000
Debu: Identified Input VIF #0 as DOWNSTREAM.
Debu: Setting TTL for UPSTREAM Vif 1 to 1
Note: Removing MFC: 192.168.0.99 -> 239.255.255.250, InpVIf: 0
Debu: Removing group 239.255.255.250. Died of old age.
Debu: Removed route entry for 239.255.255.250 from table.
Note: Route is not active. No kernel updates done.
Debu:
Current routing table (Remove route); -
На внешнем интерфейсе появилось вот это
14:13:09.750924 IP 10.255.189.193 > 239.255.0.133: igmp query v2 [max resp time 10] [gaddr 239.255.0.133]
14:13:10.750688 IP 10.255.189.193 > 239.255.0.133: igmp query v2 [max resp time 10] [gaddr 239.255.0.133]
14:13:11.749474 IP 10.255.189.193 > 239.255.0.133: igmp query v2 [max resp time 10] [gaddr 239.255.0.133] -
Вообще что я понял
1. на внутренний интерфейс пакеты приходят:
14:39:15.816624 IP 192.168.0.98 > 239.255.0.146: igmp v2 report 239.255.0.146
14:39:16.034333 IP 192.168.0.99 > 239.192.152.143: igmp v2 report 239.192.152.143
14:39:18.034329 IP 192.168.0.99 > 239.255.0.143: igmp v2 report 239.255.0.143
14:39:28.733350 IP 192.168.0.98 > 224.0.0.2: igmp leave 239.255.0.1462. Прокси их видит:
Note: New origin for route 239.192.152.143 is 192.168.0.99, flood 0
Debu: Origin 192.168.0.99 Vif bits : 0x00000000
Debu: Identified Input VIF #0 as DOWNSTREAM.
Debu: Setting TTL for UPSTREAM Vif 1 to 1
Note: Adding MFC: 192.168.0.99 -> 239.192.152.143, InpVIf: 0
Debu:
Current routing table (Activate Route);
–---------------------------------------------------Debu: #0: Dst: 239.192.152.143, Age:2, St: A, OutVifs: 0x00000000
Debu: #0: Origin: 192.168.0.99 floodIf 0 pktcnt 0
Debu:3. Но на внешнем интерфейсе ничего нет
14:37:36.341589 IP 10.255.189.193 > 224.0.0.1: igmp query v2
14:38:36.469784 IP 10.255.189.193 > 224.0.0.1: igmp query v2
14:39:36.471234 IP 10.255.189.193 > 224.0.0.1: igmp query v2
14:40:36.588887 IP 10.255.189.193 > 224.0.0.1: igmp query v2 -
А почему multicast address всегда меняется?
Замаршрутизируй тогда весь multicast range на upstream interface.
route add -net 224.0.0.0/4 10.255.189.193Здесь же видишь multicast на WAN:
14:13:09.750924 IP 10.255.189.193 > 239.255.0.133: igmp query v2 [max resp time 10] [gaddr 239.255.0.133]
14:13:10.750688 IP 10.255.189.193 > 239.255.0.133: igmp query v2 [max resp time 10] [gaddr 239.255.0.133]
14:13:11.749474 IP 10.255.189.193 > 239.255.0.133: igmp query v2 [max resp time 10] [gaddr 239.255.0.133] -
Маршрутизацию уже делал …
Адреса меняются в зависимости от канала
239.255.0.0/24
239.255.1.0/24провайдер пишет что достаточно написать
altnet 212.49.127.0/24
-
altnet сейчас вообще ни на что не влияет. Это дело присутствует в коде, но до ума его не довели. Можно не париться и вообще в конфиге не указывать.
Давай ещё раз к твоему случаю.
1. Upstream и downstream должны быть правильно присвоены.
2. Маршрутизация должна вести на upstream.
У меня это работает. Должно работать и у тебя.
Теперь что должно работать: IGMP пакеты, принятые на downstream interface, должны быть странслированы на upstream interface. -
Как то еще странно ведет себя прокси проходит наружу только 3 пакета и все.
Потом только переустановка прокси и еще 3 пакета пройдетПрокси жадный по поводу железа?
Машинка П-133
-
Нет, совсем не жадный.
Я тебе отправил новый бинарник для 1.2.2. В нём igmp шлётся строго с upstream, не обращая внимания на маршрутизацию.
Запусти его пожалуйста с -d и весь debug зашли мне обратно.
Похоже мы тут спамим с тобой, может лучше по почте продолжим? -
ок
-
После получения net dump'ов от filosoff96 и немерянного числа безуспешных попыток понять что же происходит я похоже набрёл на правду. Все IGMP пакеты, генерируемые его проигрывателем имеют IP Router Alert Option в IP-заголовке, а pf на данный момент такие пакеты тупо молча игнорирует. Вобщем они даже не доходят до демона igmpproxy.
Пока выхода два:- найти плэйер, который не вставляет это дело в IP (
Edited: например, http://www.nsplayer.org/Download-4.html) - запретить pf (но это не опция, это так - для теста)…
Вопрос задан разработчикам, посмотрим, что ответят. (Edited: в 2.0 решено http://redmine.pfsense.org/issues/show/54 )
Вот такая фикня -((((
PS: filosoff, если не жалко пришли пожалуйста дамп того, что шлёт твой хост 192.168.0.99 - очень интересно. - найти плэйер, который не вставляет это дело в IP (
-
-
В pfSense 2.0 есть галочка "разрешать IP options", т.е. pf не будет отфильтровывать эти пакеты.
Как ведёт себя igmpproxy в 2.0 я понятия не имею. -
К своему великому удивлению я обнаружил эту опцию в своём 1.2.2
Идём на downstream interface в Rules, кликаем Edit и в Advanced options есть галочка "This allows packets with ip options to pass otherwise they are blocked by default i.e. with multicast routing/proxing." Отмечаем её, сохранить, применить и всё. Работает. -
Теперь бы еще резюме с полным процессом настройки. Мне например не понятно чего указывать в настройках igmpproxy в параметрах downstream и upstream.
-
Процесс очень прост. Upstream - это тот нитерфейс, на котором к тебе приходит мультикаст (провайдер я предполагаю, т.е. WAN).
Downstream - интерфейсы где хочешь видеть этот multicast трафик. На счёт altnet можно не заморачиваться, этот параметр сейчас игнорируется. Что в правилах будет разрешено, то и будет проходить. -
Что в правилах будет разрешено, то и будет проходить.
И чего в правилах нужно добавить для воркания ИП-ТВ? Типа фром 239.0.2.17 ту эни локал?
-
На LAN нужно прежде всего разрешить IGMP c LAN на Multicast address (типа 239.0.2.17) и указать вышеупомянутую опция в Advanced Options.
На WAN нужно разрешить с (кто вещает) на 239.0.2.17 -
Если на интерфейсе LAN Везде Any, этого достаточно?
На WAN нужно разрешить с 239.0.2.17 (он вещает) на 192.168.1.0/24 ? -
На LAN any to any достаточно (хоть это и самое идиотское правило), только флажок Options нужен для некоторых плэйеров.
На WAN "кто вещает" будет какой-то НЕмультикаст адрес от провайдера, destination будет как раз 239.0.2.17. Можно для теста попробовать from any to 224.0.0.0/4 - это охватит всех потенциальных "вещателей"