Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

IGMP-proxy на 8.2.13

Доброе время суток.

Имеются маршрутизатор SNR-CPE-W4N (Rev. M) и подключенная за ним (NAT) провайдерская STB.

При переходе с версии ПО 8.2.12 на 8.2.13 (07122019) IPTV-приставка перестала подключаться к мультикаст-группам. При выделении порта для STB телевидение работает штатно, при откате версии ПО проблема так же уходит. На снимке трафика между роутером и узлом доступа заметил, что SNR при "пересылке" igmp-report использует IGMPv3. При прямом подключении (или же через мост) используется IGMPv2, подключение к группам происходит без проблем.

Понимаю, что ветка потихоньку отмирает, но все же решил заявить о проблеме (или же особенности?). В  web-морде маршрутизатора разделов, связанных с версией IGMP не отыскал. Собственно вопрос: конвертация в IGMPv3 баг или фича?

Буду благодарен за любую обратную связь ^_^

Между 8.2.12 и 8.2.13 ничего относительно IGMP не менялось. Все правки есть в гите.

А точнее она одна:

init.d: set rp_filter = 1 (CVE-2019-14899).

Единственное предположение что приставка шлёт или провайдер отвечает с каких-то левых адресов и ответ отбрасывается rp_filter.

Для пробы сказать по ssh и посмотреть что будет. Не забыв по результату отписаться тут.

sysctl -wq net.ipv4.conf.br0.rp_filter=2

P.S. Учитывая что с момента выхода вы первый с жалобами то надо особенность не в прошивке искать.
PP.S. Данные что за приставка и кто провайдер тоже будут не лишними.

На сказанное по ssh sysctl "-wq net.ipv4.conf.br0.rp_filter=2" ноль эмоций.

Снял трафик между приставкой (01) и роутером (02), от роутера к провайдеру (03). Присутствует небольшое расхождение по времени, так как не было возможности одновременно снимать на обоих участках.

При изначальном обращении не обратил внимания на тот факт, что при использовании IGMPv3  report отправляется не на адрес группы, а на служебный адрес 224.0.0.22. Адрес самой группы спрятан внутри пакета.

Приставка TVIP S-410, провайдер небольшой: Redcom (г. Хабаровск). Полагаю, что провайдер не принимает запросы на 224.0.0.22 (т.е. не обрабатывает IGMPv3).

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Да не будет никто дампы анализировать чесслово. Смысла нет.

Вами сказано что на 8.2.12 работает, на 8.2.13 нет.  Если это так то смотрим разницу между 12 и 13 в гит.

Разница между ними в одном коммите меняющий работу rp_filter включающий более строгую проверку адреса источника/назначения. Ничего другого там нет.

sysctl "-wq net.ipv4.conf.br0.rp_filter=2"

Вообще не сработает ибо синтаксис не верный. Откуда тут какие кавычки?

Просто sysctl -wq net.ipv4.conf.br0.rp_filter=2  без всяких кавычек. Это переводит rp_filter на br0 смотрещий в сторону LAN в режим который был раньше у нас по дефолту. Но в этом режиме получаем уязвимость CVE-2019-14899 В описании там косяк и уязвимость будет не только внутри туннеля а между любой парой интерфейсов на которых отключен rp_filter или переведён в режим 2.

IGMP там 3 или 2 пофигу. До этого работало и по IGMP ничего не менялось. Значит не в этом дело. И смотреть надо в сторону того что менялось, а не заниматься гаданием на дампах.

Исходя из вышесказанного проверяем следующее:

  1. переводим rp_filter в 2 на LAN (br0) - не помогло?
  2. переводим rp_filter в 2 на WAN (eth2.2) - не помогло?

Ничего больше тут выдумывать не надо. Предполагаю что отключение rp_filter на WAN поможет. И если это так то только для WAN переключить rp_filter в 2 вполне безопасно.

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

Эт если совсем на пальцах.

Это же объясняет почему не было и репортов. Т.к. в большинстве случаев подобные городушки не встречаются.

9.0.0 доступна через систему on-line обновлений. Всё должно зажить. Проверяем.

Отвечаю по порядку:

Кавычки были использованы лишь при написании ответного сообщения для выделения команды в тексте (но, каюсь, открывающую случайно влепил после sysctl).  Само собой в консоли команда давалась без каких-либо кавычек или же иных спецсимволов. Повторюсь, что sysctl -wq net.ipv4.conf.br0.rp_filter=2 не помогло.

sysctl -wq net.ipv4.conf.eth2.2.rp_filter=2 через некоторое время "решает" проблему, и роутер чудесным образом начинает пересылать report'ы на адрес запрашиваемой мультикаст-группы.

Необходимо уточнить пару моментов: проблема действительно была обнаружена при переходе с 8.2.12 на 8.2.13, но для отката под рукой была версия постарше (8.2.7, если быть точнее). Файл с 8.2.12 у меня не сохранился, иные способы отката мне неизвестны (но не исключаю, что они есть и могут быть вполне доступны). Так вот, на 8.2.7 маршрутизатор не подменяет версию IGMP, и IPTV работает штатно.

При обновлении на 9.0.0 report'ы изначально улетают на 224.0.0.22 (IGMPv3), и только через какое-то время подменяется адрес назначения (т.е. осуществляется переход на IGMPv2). И только тогда появляется трафик от ISP: поток UDP запрашиваемой группы, при запросах 224.0.0.22 никакого ответного трафика я не фиксирую. Также заметил, что после загрузки роутера на версии 9.0.0 при переключении каналов все запросы продолжают пересылаться на 224.0.0.22. Если остановиться на одном канале на 30-60 секунд, роутер меняет адрес назначения, и "проблема" отступает до следующей перезагрузки. Но если же в самом начале "прыгать" по каналам, то смена адреса назначения может затянуться на неопределенный срок (на всякий случай пример "перехода" во вложении).

Сожалею, что получилось так много воды в тексте. Но если абстрагироваться от версий ПО и конкретного провайдера, у меня остается один вопрос:
"Почему и зачем маршрутизатор принудительно использует IGMPv3 при работе IGMP-proxy?"
Потому как именно это является для меня явным критерием того, заработает IPTV или нет. Следствием чего может быть подобное поведение, мне не ясно.

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Ну вот те здрасьте.

  1. никто ничего не подменяет
  2. 8.2.12 до вчерашнего дня лежала на sf.net

По порядку. Роутер (как и любой прокси) шлёт что либо выше от своего имени. Т.е. создаёт запросы заново. Логика выбора v2/v3 в ядре постая и понятная, не отвечают на v3 несколько раз - сползаем в v2. И этой логике лет 10ть.

Т.е. всё работает более чем штатно.

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

А т.к. показания путаются то это начинает занимать уже черезчур дофига времени.

То вообще не работает, то при переходе с 12 на 13 перестало, то уже может и не с 12 на 13.

Насколько я знаю всегда так было и это вообще-то норма. Авто выбор версии протокола в Linux всю жизнь работает именно так. И таймауты там фиксированные. И не 30-60с остановиться надо, а буквально 3 запроса и дальше оно само форсируется. Если не форсируется - значит кто-то что-то таки отвечает по v3.

В общем черезчур много угадайки и мало фактологии.

sysctl -wq net.ipv4.conf.eth2.2.force_igmp_version=2

В руки. Можно прописать в /etc/sysctl.conf просто net.ipv4.conf.eth2.2.force_igmp_version = 2 сказать fs save и забыть пока не будет репортов от кого-то ещё.

У меня тоже оператор v3 не умеет и не вижу проблемы от слова совсем. Ни с STB ни с VLC.

Switchback timeout регламентируется RFC  -  rfc3376

В общем посмотрел в гит коммит который приводит поведение к switchback RFC шному был в ноябре 2018.

Date:   Sat Nov 3 17:40:06 2018 +0500

    kernel: net: igmp: fix v1/v2 switchback timeout based on rfc3376, 8.12.

После этого поведение не менялось. От слова совсем. Потому точно ни на 8.2.7 ни на 9.0.0 разницы в поведении switchback нет.

Попозже перетащу с апстрима пару несущественных правок и добавлю переменную igmpVersion в nvram для форсирования выбора протокола. 0 - auto, 1/2/3.

В рожу выносить смысла оную не вижу, да и некогда. Массовых репортов нет, точнее их вообще нет кроме вашего. С ноября 18го точно.

Учитывая характер поведения описанный выше в части надо потыкать первый канал какое-то время и зная логику выбора могу предположить что кто-то из соседей по свитчу (на правах гадалки нет изоляции или снупинг на свитче не пашет домовом) отвечает на запросы причём по v3. Потому оно и пытается его использовать. Методов борьбы с этим кроме как форсировать выбор версии протокола я в лоб не придумаю.

Сделано. Доступно через on-line обнволения.

Что надо проверить. Просто обновиться и потыркать приставку. Маловероятно что что-то поменяется. Но всё же.

А что бы форсировать igmp v2 на WAN командуем nvram_set igmpVersion 2 && reboot. И усё.

 

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: