Ещё одна мысль нашлась в гугле - нужно добавить маршрут до точки рандеву (RP) через нужный интерфейс (eth2). Поток же с неё забирается, а приложение лезет в интерфейс по умолчанию (eth3). Запросы приложение куда надо шлет, а ответы забираются с другого хоста - RP. Блин. И как я сам не допёр? Вечерком попробую.
Ещё бы выковырять её и знать бы сколько их у провайдера и надеяться, что они все в одной сети.
Алексей Черемисин: да
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 туннеля была фрагментация, то пакеты просто не доходили бы до интерфейса компа, так ведь?
роутинг на адреса мультикаста именно так и сделан. Иначе бы не бегало.
про мультикаст я читал в "Сети для самых маленьких". Ваши тоже почитаю, спасибо.
У меня мультикаст УЖЕ ПРИШЁЛ на интерфейс. Я его вижу tcpdump'ом. его приложение, отправившее запрос не видит.
Причем приложение толкает периодические пакеты присутствия, что поддерживает трансляцию с сервера. И когда жму "стоп", трансляция обрывается через сколько-то секунд - то есть всё правильно с мультикастом и маршрутами. Какой-то косяк в самой системе, что она не заводит поток с этого интерфейса в приложение
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Ещё бы выковырять её и знать бы сколько их у провайдера и надеяться, что они все в одной сети.