Почему приложение не получает видеопоток, поступающий на сетевой интерфейс?

Question

[V Oz]

Дома стоит комп под linux (OpenSUSE) с двумя сетевыми интерфейсами. Один (eth3) для просто выхода в сеть (локалку и инет). Второй (eth2) - для подключения к мультикасту через туннель в удаленной локалке. Оба подключены к роутеру под RouterOS.
Маршрутизация настроена, всё работает, пакеты мультикаст-потока приходят на eth2 - tcpdump показывает активность на этом интерфейсе с правильных адресов сразу после запроса приложением (ffmpeg, mplayer, VLC) потока с
сервера по UDP. То есть запрос уходит в правильный интерфейс, в ответ на него сыплется поток через правильные мосты в роутере, в правильный интерфейс, но .. собственно приложение этого потока не получает. Например, в ffmpeg (ffplay) просто тишина, вместо обычного вывода в консоль характеристик потока и пр. Причем приложение толкает периодические пакеты присутствия, что поддерживает трансляцию с сервера. И когда жму "стоп", трансляция обрывается через сколько-то секунд - то есть всё правильно с мультикастом и маршрутами.
Причем незадолго до этого как-то работало, но криво - поток заходил в комп не через выделенный для него eth2, а через eth3. Перенастроил роутер и поток пошел правильным руслом, но видео работать перестало.

Куда, чем копать на уровне системы, чтобы понять где заблудился этот поток?

Answer 1

[V Oz]

Доктор ЛОР прописал вписать маршрут не только в широковещательную сеть, но и до точек рандеву (RP) провайдера IPTV.
Видимо плохо прочитал матчасть про мультикаст, если забыл об этом. Хорошо хоть вспомнил сразу, как прочел рецепт.
Если коротко, то клиент шлёт запрос на сервер группы, там выбирается какой сервак будет вещать. Этот сервер шлёт трафик в точку встречи клиента и сервера для подсети клиента. Клиент забирает поток из точки рандеву. Этих точек может быть несколько.

Как определить RP - включаем плеер и просматриваем все ссылки на потоки параллельно снимаем дамп с интерфейса и смотрим откуда идет трафик на адреса указанные в ссылках:

21:14:15.446253 IP (tos 0xb8, ttl 53, id 0, offset 0, flags [none], proto UDP (17), length 1344)
198.18.20.5.50201 > 225.33.23.48.commplex-main: [no cksum] UDP, length 1316

добавляем маршруты

ip route add -net 224.0.0.0/4 via dev eth2
route add -net 198.18.0.0/16 gw 192.168.222.110

где 192.168.222.110 - IP адрес интерфейса маршрутизатора, к которому подключен интерфейс нашего клиента. Маршрут до него также должен быть определен.
В принципе, если в системе только один интерфейс, то всё как-то само должно разрулиться. А вот в случае как у меня или на ЛОРе, интерфейс не по умолчанию для доступа к потоку приходится указывать руками. И надеяться, на то, что провайдер не часто будет менять топологию своей сети.

ЗЫ. это всё коротко и наверняка где-то чуток ошибочно и потому не отменяет усвоения матчасти про мультикаст и маршрутизацию.

Answer 2

[Алексей Черемисин]

Пропишите на нужный интерфейс роутинг на адреса мультикаста
Например
ip route add 224.0.0.0/4 via dev eth2
Ну и для того, чтобы мультикаст маршрутизовался с интернфейса на интерфейс, нужно ставить специального демона, иначе маршрутизации мультикаста не будет!
smcroute и igmproute.
Ну и статья на всякий случай - https://www.altlinux.org/Static_Multicast_Routing
ну и - http://xgu.ru/wiki/Multicast_в_Linux

Comments

[V Oz]

роутинг на адреса мультикаста именно так и сделан. Иначе бы не бегало.
про мультикаст я читал в "Сети для самых маленьких". Ваши тоже почитаю, спасибо.
У меня мультикаст УЖЕ ПРИШЁЛ на интерфейс. Я его вижу tcpdump'ом. его приложение, отправившее запрос не видит.
Причем приложение толкает периодические пакеты присутствия, что поддерживает трансляцию с сервера. И когда жму "стоп", трансляция обрывается через сколько-то секунд - то есть всё правильно с мультикастом и маршрутами. Какой-то косяк в самой системе, что она не заводит поток с этого интерфейса в приложение

[Алексей Черемисин]

V Oz: так, а у интерфейса флаг MULTUCAST установлен?

[V Oz]

Алексей Черемисин: да
3: enp2s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:1b:21:39:da:78 brd ff:ff:ff:ff:ff:ff
inet 192.168.222.111/24 brd 192.168.222.255 scope global enp2s0
valid_lft forever preferred_lft forever

вынашивалась мысль, что это из-за PMTU, но пакеты сыплются длиной 1316 (согласно RFC4821 в части мультикаста)
да и если бы из-за MTU туннеля была фрагментация, то пакеты просто не доходили бы до интерфейса компа, так ведь?

[V Oz]

Ещё одна мысль нашлась в гугле - нужно добавить маршрут до точки рандеву (RP) через нужный интерфейс (eth2). Поток же с неё забирается, а приложение лезет в интерфейс по умолчанию (eth3). Запросы приложение куда надо шлет, а ответы забираются с другого хоста - RP. Блин. И как я сам не допёр? Вечерком попробую.
Ещё бы выковырять её и знать бы сколько их у провайдера и надеяться, что они все в одной сети.