(And would also be worth checking if maybe #Realtek #rtl83xx might be buggy here. I'm having a hunch that maybe with the different MLD/IGMP trapping method on #rtl83xx that reports might not be forwarded to other multicast routers.)

Alternatively, I'd need to use a different PIE action, there is one which allows trapping to a set of ports (including CPU) instead of a single port. Which would also mean I'd have to always update these installed PIE rules when multicast routers appear or disappear behind any ports. Which would be quite a bit more work then toggling one bit in one place. Also would consume/dedicate one more multicast port mask entry for this special purpose. Hm... 2/2

#realtek #openwrt

#Realtek / #OpenWrt / #switchdev: So I can trap packets, like MLD, to the CPU via the packet inspection engine now. Now I want the Linux bridge to (potentially) forward MLD in accordance to #RFC4541, that is to all mc router ports. However the bridge will last-minute bail out bc. nbp_switchdev_allowed_egress() is false bc. it came from an offloaded port.
Changing skb->offload_fwd_mark to 0 somewhere would be the easiest. But not quite sure where and if that'd be too hacky. 1/2

#multicast

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.
Yaiy, I think I found a way now to fix the #multicast snooping on #Realtek #rtl9300 switches! The way trapping of MLD reports was "enabled" in #OpenWrt does not work on #rtl9300 / #longan. It was also removed in newer datasheet versions.
The 2nd option is Realtek's Packet Inspection Engine. In its templates, MLD checking seems broken, too. But I can use the PIE to semi-manually construct a parser for an ICMPv6 packet with an ICMPv6 type of 131 (MLDv1 reports) via its pre-defined templates!
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)
У меня опять сломались проводные наушники.
Перегнулся / расшатался кабель прямо у джека.
В принципе, могу и перепаять на другой джек с иным куском кабеля, ибо умею - найти бы время... и паяльник...
Но, как сказал диснеевский Гуфи:
> ВО ВСЁМ нужно искать свои ПОЛОЖИТЕЛЬНЫЕ СТОРОНЫ!!!
Ведь теперь у меня появился караоке-фильтр в наушниках!
(я решил добить их окончательно, ибо я из династии советских меломанов - и к неудобствам мне не привыкать)
Как известно, большая часть профессионального вокала в коммерческих треках записывается в стерео. Караоке фильтры каким-то образом обрабатывают стерео-сигнал, при этом, вокал *на некоторых треках* пропадает (не на всех + реверберация от вокала остаётся)! Это древнейший метод вырезания вокала, его можно найти даже в Realtek-аппаратных чипах и в списке эффектов "Adobe Audition". Он старше, чем Spleeter, хотя, конечно, принцип у Spleeter и Vocal Remover у AA примерно такой же: преобразование Фурье (я тыкал их оба, и я знаю точно)
Сегодня лучше использовать UVR, она работает даже на ЦП и у неё куча дополнительных режимов. Самый крутой вырезальщик вокала в UVR - это модели в разделе "VR ARCHITECTURE" - только вчера через них кучу чужих треков гонял, работает лучше обычного "DEMUX" режима!!
#наушники #контакт #кабель #музыка #вокал #удаление #караоке #Realtek #UVR #VR
#Haikuos's May report is full of great stuff: AVX-512 in the kernel, first steps on the #RaspberryPi5, old #Realtek WiFi dongles brought back to life. Then you count the signatures on the foundations and it is always the same person. An entire OS with a bus factor of one. I wrote about it: https://www.desktoponfire.com/haiku_inc/856/haiku-in-may-avx-512-a-raspberry-pi-5-that-almost-boots-and-the-same-old-uncomfortable-truth/
#Haikuos's May report is full of great stuff: AVX-512 in the kernel, first steps on the #RaspberryPi5, old #Realtek WiFi dongles brought back to life. Then you count the signatures on the foundations and it is always the same person. An entire OS with a bus factor of one. I wrote about it: https://www.desktoponfire.com/haiku_inc/856/haiku-in-may-avx-512-a-raspberry-pi-5-that-almost-boots-and-the-same-old-uncomfortable-truth/