Show threadT_X1d ago
We also initially tried having #ClaudeCode implement the #IGMP / #MLD snooping, but it made several mistakes for one thing. And for another, of course doesn't know what was still broken on the chip. So from all that tinkering and digging into the #Realtek #PIE I think I know enough now to do a cleanroom implementation.
T_X2d ago
I seemingly was able to trap some packets with the #Realtek #ACL engine. Could even trap #MLDv1 packets to the CPU when trapping all #IPv6 packets with it. The #IGMP / #MLD fixed field in the #PIE (packet inspection engine) did not seem to work though, nor using one for the (final) #IPv6 next header. Might need to try creating a custom template instead of trying to use a pre-defined one.
(and using the VLAN application trap did not work either, because it seemingly got removed for #rtl9300)
Habr4d ago

История о том, как мультикаст IGMP‑запрос перестал быть запросом и стал broadcast‑штормом

Иногда сетевой инцидент выглядит как проблема маршрутизации, коммутатора или IPTV‑сервиса, но на деле трафик умирает раньше — внутри сетевой карты. В этой истории разберём, как Intel X710 научилась отбрасывать корректный multicast, почему IGMP‑запросы не спасали ситуацию и как одна правка в драйвере превратила редкий баг в массовую головную боль для инженеров. Читать кейс

https://habr.com/ru/companies/otus/articles/1047406/

#мультикаст #IGMP #Intel_X710 #сетевая_карта #аппаратная_фильтрация #broadcastшторм #FreeBSD #драйверы #диагностика_сети #сетевые_сбои

История о том, как мультикаст IGMP‑запрос перестал быть запросом и стал broadcast‑штормом

Привет, Хабр! Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги. Наш сегодняшний рассказ мы начнем с небольшой...

Хабр
Show threadT_XApr 4
The #rtl9300 datasheets also read as if they had planned to provide some easy, built-in trapping options for #IGMP / #MLD reports, as they had for #rtl83xx, based on their new ACL / packet inspection engine. But that they had scraped that and postponed that to their bigger #rtl9310 chips.
#multicast
T_XApr 4
For the #Realtek #rtl9300 (excluding #rtl9310) switch chips for #OpenWrt further datasheet readings and bit fumbling brought me to the conclusion (for now) that it seems that there is no easy way for #IGMP / #MLD report trapping anymore. Hence #multicast snooping support for #rtl9300 on OpenWrt will be more tricky...
For #rtl93xx they introduced a new, powerful ACL / packet inspection system. And trapping has been changed quite a bit compared to #rtl83xx.
T_XMar 31
Also finally found some combination of register setups and diffs for this #Xikestor #Realtek #rtl9300 based chip which correctly traps #MLD packets to the CPU / Linux kernel/bridge, which is necessary to fix #multicast snooping with it.
The combination doesn't fully make sense to me yet though, will need to play around a little more to hopefully get a better understanding. But at least that seems like some progress. Will also need to check #IGMP later.
HabrFeb 24

Как я победил «замирающее» IPTV на MikroTik с двумя провайдерами (MultiWan) и DoH

История одной диагностики, которая затянулась, но закончилась хеппи-эндом Если у вас MikroTik, два провайдера, настроена балансировка (PCC), вы включили DNS-over-HTTPS (DoH) для безопасности, а IPTV на Android-приставке работает с перебоями или замирает при включении второго WAN канала — эта статья для вас. Я прошёл этот путь от начала до конца и хочу поделиться готовым решением. Проблема: IPTV на Android-приставке работало стабильно только при отключённом одном из провайдеров. При двух активных каналах видео начинало "замирать" через некоторое время после переключения каналов.

https://habr.com/ru/articles/1002988/

#mikrotik #multiwan #doh #dns #ip_tv #udp #igmpproxy #igmp

Как я победил «замирающее» IPTV на MikroTik с двумя провайдерами (MultiWan) и DoH

История одной диагностики, которая затянулась, но закончилась хеппи-эндом Если у вас MikroTik, два провайдера, настроена балансировка (PCC), вы включили DNS-over-HTTPS (DoH) для безопасности, а IPTV...

Хабр
Show threadT_XMar 11, 2025
In the classic, non-DSA #Linux bridge the philosophy so far is: No matter in what combination you enable/disable multicast_snooping+ multicast_querier: The bridge ensures you don't break any network protocol, it detects per protocol family if #multicast snooping is applicable. That together with #RFC4541 I think is the only way to regain trust for #IGMP / #MLD snooping imo.
And now things like #DSA or #switchdev come along with non-foolproof solutions, diverging between each driver...
Show threadT_XMar 11, 2025
...and even this mrouter exists #switchdev event is a quite incomplete approach. What if you multicast router somehow #IGMP / #MLD querying disabled -> would break any #IPv6, even if you're not using multicast routing. What if you only have an IGMP querier? Would notify an mrouter-exists, but there's no MLD querier, so again IPv6 would be broken...
Show threadT_XMar 11, 2025
Neither #switchdev nor #DSA really check if an IGMP/MLD querier exists. So if you enable #multicast snooping on these you currently also need to make sure to have an #IGMP / #MLD querier somewhere. Which is different to a classic Linux bridge, which will stop snooping optimizations if there is none, to avoid packet loss. Only for Marvell Prestera I found some mrouter-exists check via an according switchdev event. Which no other driver uses. And...