Можно ли сменить Source IP multicast пакета проходящего через Linux роутер?

minidlna сервер в одной сети, а телевизоры в другой.

с мультикастом не работал плотно, так что пальцем в небо: igmp-proxy/udp-proxy не пробовал?

iptables этот трафик в POSTROUTING не видят :(

Попробуйте

modprobe br-netfilter
sysctl net.bridge.bridge-nf-call-iptables=1

этот трафик в POSTROUTING не видят

Какой «этот», там же в начале SSDP, который по multicast?

Что в рамках multicast означает:

режет трафик не из своей сети (по маске)

Вы просто все пакеты от телика дампить пробовали?

Этот это ssdp. Да все уже пробовал. В одной сети 2 телика. Samsung и Android китайский. Android средствами VLC все прекрсно видит, это подтверждает рабочую настройку. Так же сниффером я вижу трафик SSDP от DLNA и к нему. Так вот Samsung телевизор это все игнорирует.

Да пробовал. Это в первую очередь сделал. Так вот пакеты SSDP проброшенные в рамках multicast route не видно :(

iptables -t nat -I POSTROUTING -p udp --dport 1900 ‐j LOG

Samsung телевизор это все игнорирует.

То есть он не отправляет M-SEARCH пакеты и игрорирует NOTIFY пакеты? Я, просто, пока не понимаю, что вы хотите исправлять с помощью NAT. ИМХО, если бы Samsung'е хотели ограничится только локалкой, то они бы по полю LOCATION: игнорировали NOTIFY пакеты...

Но тут приобрели «новый» телик Samsung, и он на отрез не хочет видеть DLNA, проброшенный таким образом.

А не проброшенный а запущенный DLNA из той-же сети видит?

Да. Внутри той же сети этот же физически dlna видит. Если кабель переткнуть и перенастроить.
Да и в целевой конфигурации в первой сети тоже есть телики и они видят dlna. И тоже самсунги есть.

Да игнорирует. И да отправляет M-SEARCH. Самое смешное, что например BubbleUpnp видит эти M-SEARCH и видит телик и может на него транслировать, будучи в другой сети.
Хотел попробовать сменить «отправителя» в пакетах. Начать с этого. Вдруг там фильтрация на уровне файрвола мультикаста из локалки.

В цепочку POSTROUTING попадает только первый пакет соединения. Для UDP, если ядро не понимает L4 протокол, соединения режутся по таймауту, 5 минут. То есть, если у вас там всё время летают SSDP пакеты, то ядро будет считать эти соединения установлеными и не будет пакетов в таблице nat. То есть, по идее, что ваш LOG сработал, нужно с помощью команды conntrack удалить запись для udp 1900. Это при условии, что в ядре ничего не добавили за последние много лет касатально обработки multicast пакетов. Может они вобще мимо nat идут.

Ещё, лет 10 назад был stateless NAT с помощю tc (tc ... action nat), не знаю, оставили ли его в ядре, включен ли он в вашем ядре и получится ли у вас составить правило. Но, этом NAT на всё фиолетово, он просто тупо поменяет src-адрес, чтобы протесировать.

Ну, и ещё есть SSDPy — библиотека на питоне, не знаю живая или нет. Но, вроде как, с помощью неё питоновским однострочником, с компа во второй сети, можно сформировать нужный NOTIFY-пакет (src от второй сети, а LOCATION: из первой).

igmp-proxy не пробовал ставить какой-нибудь? В openwrt он есть и можно посмотреть что именно используется.

Не удивлюсь, если в nat не не работает с адресами 224.0.0.0/4.

В nat не попадает трафик кторый отсутствует в conntrack (например -j CT --notrack).

Если трафик udp/1900 ненапряженный, то можно просмотреть трассировку через "-j TRACE", а если трафик адский, то сделать конструкцию:

ipset create trace hash:ip,port

iptables -t raw -A PREOUTING -m set --match-set trace src,src --packets-lt 2 -j TRACE
iptables -t raw -A PREOUTING -m set --match-set trace dst,dst --packets-lt 2 -j TRACE

Добавляешь в trace адрес и порт пакета трассировку которого ты хотел посмотреть

ipset add trace xxx.xxx.xxx.xxx,udp:1900

Трассу в dmesg лучше смотреть скриптом из Как сделать сервер маршрутизации? (комментарий)

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

Это все не меняет сути того, что пакеты отлично маршрутизируются и проходят «сквозь» роутер и появляются в целевой сети.
Никто из вышеперечисленного не меняет адрес источника (что как бы логично с их стороны).
Задача первоначально не сильно логична сменить отправителя для проверки теории.

И вообще меня всегда смущала мысль о применении igmp-proxy для работы с dlna трафиком.
Тут либо утиля названа не логично, либо люди путают кислое и шершавое. Ведь IGMP это отдельный протокол «организации» порядка в мультикаст трафике. В частности у меня телик Samsung не отправил ни одного IGMP пакета дабы заявить себя в какую то группу. Он просто шлёт и видимо принимает UDP трафик на порту 1900. При чем тут IGMP?

В частности у меня телик Samsung не отправил ни одного IGMP пакета дабы заявить себя в какую то группу. Он просто шлёт и видимо принимает UDP трафик на порту 1900. При чем тут IGMP?

Весь нормальный софт работающий с МС знает, что нужно использовать IGMP.
А пионеры из самсунга сказали: какой нафиг МС-роутер или управляемый коммутатор с igmp-snooping у хомячков?
igmpproxy было сказано в общем случае. Нужен посредник (proxy/relay) который слушает запросы на МС-адреса и ретранслирует их в соседние сети. При этом он может и адрес источника изменить.

Учти, что многие поделки использующие МС ставят TTL=1, т.ч. просто форвардинг таких пакетов требует доп. действия.

igmpproxy+smcroute это один из костылей.

Другой костыль https://github.com/alsmith/multicast-relay там и про ssdp есть.

PS есть еще один костыль против некоторых странных сетевых адаптеров и называется он

ip li set dev ethX allmulticast on

Ну фильтр tcpdump -i any -n igmp не видит ни одного пакета. Кстати как и в сети с minidlna...
Я проверил iptables - там сейчас пусто и все ACCEPT. Где этот IGMP трафик в контексте DLNA?