T_XPatchset v2 is out for the Linux bridge, to reduce checks in the #multicast fast path, and to later propagate a safety multicast (in)active state to #switchdev/#DSA:
https://patchwork.kernel.org/project/netdevbpf/cover/[email protected]/
Includes some fixes and got some nice Linux selftests: https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
This is also the version currently used in this OpenWrt draft PR for #realtek / #rtl83xx (v6 - v8): https://github.com/openwrt/openwrt/pull/18780
Finally got a v6, of a #multicast PR for #OpenWrt for the #Realtek / #rtl83xx target out: https://github.com/openwrt/openwrt/pull/18780
The whole thing, especially for the Linux bridge + DSA got bigger than expected (from ~4 patches to now 16...). But djfe was so kind to help with rebasing to 6.12 on OpenWrt. Then also got stuck on a regression in OpenWrt, but @cuechan's impartial view and technical expertise helped with that.
Next will need to circle back to upstream Linux for a new submission (after some sleep...)
The whole thing, especially for the Linux bridge + DSA got bigger than expected (from ~4 patches to now 16...). But djfe was so kind to help with rebasing to 6.12 on OpenWrt. Then also got stuck on a regression in OpenWrt, but @cuechan's impartial view and technical expertise helped with that.
Next will need to circle back to upstream Linux for a new submission (after some sleep...)
realtek: various multicast snooping fixes and improvements by T-X · Pull Request #18780 · openwrt/openwrt
The following patchset is to get the rtl83xx multicast snooping behaviour closer to the one of a pure software Linux bridge in the following ways and to fix a few issues: Firstly, a plain Linux bri...
This #rtl83xx switch is driving me crazy. I can't get it to work anymore with any #OpenWrt image I'm trying to throw at it. And it used to work in the past... However it likely isn't a hardware defect either, as booting the same thing with an old vendor image from its flash works fine...
I must be missing something obvious...
I must be missing something obvious...
I just wanted to make a little #multicast safety feature in the Linux bridge available to #switchdev + #DSA, too, to use it on #rtl83xx / #rtl93xx #Realtek drivers / switches later. One suggestion on the PR was like, maybe we could do the locking differently or use atomics. Me several hours later:
Interesting, the #XikeStor / #Seekswan SKS8300-12X switch seems to be rtl93xx based, too, with the most SFP ports I've seen for a #Realtek #rtl93xx or #rtl83xx device. According to this page it should be #rtl9313: http://visit.seekswan.com:6555/xksupport/SKS8300-12X.htm
And maybe it wouldn't be too hard to add to #OpenWrt as the smaller XikeStor SKS8300-8X is already supported there: https://openwrt.org/toh/hwdata/xikestor/xikestor_sks8300-8x
And maybe it wouldn't be too hard to add to #OpenWrt as the smaller XikeStor SKS8300-8X is already supported there: https://openwrt.org/toh/hwdata/xikestor/xikestor_sks8300-8x
@txt_file replaced the switches at the #Nobreakspace with a second hand 52 ports switch and a 24 ports PoE switch - both with a #Realtek / #rtl83xx chip and OpenWrt support, 50€ each on kleinanzeigen.de. But yeah, 10 and even 40 Gbit/s ports and 750W for PoE on this Mikrotik one sound nice :D.
Nice talk at the @battlemesh about #Realtek #switches running #OpenWrt. To get people even more excited about it this is how an OpenWrt #LuCI can look like with 52 ports :D. This D-Link DGS-1210-52 F1 was obtained for just 50€ on a German second hand online market place (kleinanzeigen.de) and is now running in the #Nobreakspace. Always make sure to pick the correct revision though, there are switches with very similar names but which don't use a Realtek chip.
#rtl83xx #rtl93xx
#rtl83xx #rtl93xx
Use #BSD for good networking, nuff said... Use #OPNsense for a firewall/router, nuff said...
Me trying to use #multicast snooping with this in our hackspace: After several hours of debugging, realizing it's not bc. of the #OpenWrt powered, #rtl83xx based switch I've added, nor the new patches I've made and added to it. But because of this two years old, ignored #OPNsense (or #FreeBSD?) bug with #MLD: https://github.com/opnsense/core/issues/6247
😒 😤
So, an #rtl83xx based switch, a ZyXEL GS1900-24HP v1, running #OpenWrt was now added to the rack of our hackspace. Some initial weirdness and confusion: PoE would not be enabled by default on boot. "/etc/init.d/poe restart" would until rebooted. Or manually populating /etc/config/poe with each PoE port seems to make it reboot safe...
Also PoE LEDs are not working yet.
The thing is, many crucial things in our space rely on PoE, like #VoIP phones, WiFi APs and the internet modem...
Also PoE LEDs are not working yet.
The thing is, many crucial things in our space rely on PoE, like #VoIP phones, WiFi APs and the internet modem...
#rtl83xx #multicast update, v2: added forwarding to multicast router support, which is required by #RFC4541. And one bugfix to my original PR:
https://github.com/openwrt/openwrt/pull/18780#issuecomment-2876333576
This should make multicast snooping with this device usable now.
https://github.com/openwrt/openwrt/pull/18780#issuecomment-2876333576
This should make multicast snooping with this device usable now.
realtek: various multicast snooping fixes and improvements by T-X · Pull Request #18780 · openwrt/openwrt
The following patchset is to get the rtl83xx multicast snooping behaviour closer to the one of a pure software Linux bridge in the following ways and to fix a few issues: Firstly, a plain Linux bri...