We'll, when you enable Igmp snooping on Luci it was applying it to the bridge correctly, but the switch swconfig driver didn't support Igmp snooping so it wasn't applying it on the switch, I hope I'm explaining myself correctly 
I can't make blogics patch work under 4.19
As I understand with this patch all slave devices should carry over the mac from their master device.
I modified the patch and it does compile but doesn't work.
Does it work for you under 4.14?
With only the patch (when it works) will result in all interfaces wan+lan1+4 will have the same mac address.
So modifying 06_set_iface_mac is still needed.
Hmmm fascinating... I could probably get networkd to do something similar. Note that the Omnia is not on that list.
I would like to highlight the fact that Homeware, commercial fork of Openwrt, has DSA in force over broadcom drivers, so if you need some point of reference on how uci switch configs works on such devices take it into account.
Where can I find it? Been searching but found nothing
Hey guys can you show me links to you patches? I'd like to use them but have no idea where to find them
What are you looking for exactly? There are plenty of firmware filesystem dumps, most is done in lua Here are some: https://github.com/FrancYescO/tch_firmware_extracted
Here is an interesting network setting scenario you could use as benchmark:
config switch 'bcmsw_int'
option reset '1'
option type 'bcmsw'
option qosimppauseenable '0'
option jumbo '1'
option unit '0'
option enable_vlan '0'
config switch 'bcmsw_ext'
option reset '1'
option type 'bcmsw'
option qosimppauseenable '0'
option jumbo '1'
option unit '1'
option enable_vlan '1'
config switch_vlan 'lan_switch_A'
option device 'bcmsw_ext'
option vlan '1'
option ports '1* 2* 4* 8t'
config switch_vlan 'lan_switch_B'
option device 'bcmsw_ext'
option vlan '835'
option ports '3* 8t'
config device 'eth0'
option mtu '1500'
option name 'eth0'
config device 'eth1'
option mtu '1500'
option name 'eth1'
config device 'eth2'
option mtu '1500'
option name 'eth2'
config device 'eth3'
option mtu '1500'
option name 'eth3'
config device 'vlan_eth0'
option type '8021q'
option ifname 'eth0'
option name 'vlan_eth0'
option mtu '1500'
option vid '1'
config device 'vlan_eth1'
option type '8021q'
option ifname 'eth1'
option name 'vlan_eth1'
option mtu '1500'
option vid '1'
config device 'vlan_eth2'
option type '8021q'
option ifname 'eth2'
option name 'vlan_eth2'
option mtu '1500'
option vid '1'
config device 'vlan_eth3'
option type '8021q'
option ifname 'eth3'
option name 'vlan_eth3'
option mtu '1500'
option vid '1'
config globals 'globals'
option ula_prefix 'auto'
option default_ps '0'
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option force_link '0'
option igmp_snooping '1'
option ipv6 '0'
option ip6assign '0'
option ipaddr '192.168.44.1'
list ifname 'vlan_eth3'
config device 'eth4'
option name 'eth4'
option mtu '1508'
config device 'ptm0'
option name 'ptm0'
option mtu '1500'
config interface 'bridgedmode'
option release '1'
option iface6rd '0'
option auto '1'
option ipv6 '0'
option mtu '1500'
option proto 'bridge'
option type 'bridge'
list ifname 'vlan_eth0'
list ifname 'vlan_eth1'
list ifname 'eth2'
list ifname 'ptm0'
config interface 'wan'
...
This one implements switch to modem bridging over three eth ports leaving one switch port enabled for local management. The first two bridged ports gets traffic bridged preserving original tagging, the third one gets tagging applied by the switch to allow traffic exiting as tagged out of the modem. Both eth4 and ptm0 are WAN ports, not being part of the main switch, unused eth4 setup is omitted here.
1 Like
bridge fdb
I guess the performance hit is because the MAC driver (mvneta) or the hardware of mvebu does not support DSA tag offloading.
But the marvell 88f6281+ marvell 88e6171r device get the normal performance with DSA driver. Maybe it's a bug of mvneta driver or DSA driver?
So, how's everything going?
Can you guys tell me which patches you made?
@ParanoidZoid have you tried to make a pull request o merge your patches with OpenWRT?
Still working on it. I still need to understand DSA better. I find it really difficult to move away from the ease of use of swconfig right now, especially since it has so many easy to access and centralised documentation in the OpenWrt wiki/forums. I also need to stop playing around with the singular router in the household, lest I incur the greater wrath of my family.
I still don't have a transition script in the works and for reasons with regards to work, I'll be extremely busy for the following two weeks. I'll try and make some progress this weekend, but it's probably best if you (or someone else) work with what I have with the branch in my fork and tidying it up for submission as a pull request.
I believe what still needs to be done is:
- Fix assigning the MAC address properly instead of using a random one every single boot (I've already modified it in my branch but have not tested it yet).
- Make a transition script for all use cases esp. w.r.t. VLANs.
- Investigate what is going on with the 1900ACv1 Mamba's mv88e6171r + DSA.
- More tests required - iperf, netperf, flent. What happens with bufferbloat? What happens with throughput? Can we stress test & enable/disable various physical switch options and invoke a warning/failure?
With your current approach (using blogic's patch),
wan and lan1-4 will end up with the same mac address.
Can you actually confirm that the patch does work?
Since i can't get blogics patch working i used the following approach:
mac=$(mtd_get_mac_ascii devinfo hw_mac_addr)
mac_wan=$(macaddr_setbit_la "$mac")
ip link set dev eth1 address $mac_wan 2>/dev/null
ip link set dev eth0 address $mac 2>/dev/null
ip link set dev lan1 address $mac 2>/dev/null
ip link set dev lan2 address $mac 2>/dev/null
ip link set dev lan3 address $mac 2>/dev/null
ip link set dev lan4 address $mac 2>/dev/null
ip link set dev wan address $mac_wan 2>/dev/null
Performance-wise. i can't see any difference, atleast on wrt1200.
But i can only test speeds up to ~400 Mbit/s.
Some other question i have...
dsa was developed by marvell and was first introduced like over 10y ago?
How is it possible that there is only support for one cpu port?
Yeah I've just tested it and it doesn't work. I guess your approach is good for now - until someone who knows more than us does a cleaner approach with an in-driver solution.
Tested on 4.19
Maybe this can help (?)
https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
I really get you ahahaha
I'll try to work on it too, my teachers are really good at scripting so they can help me
That's a really good question, I was faced with that issue, so I had to improvise and made a bridge between the WAN/WAN6 interfaces and enabled SQM in there, and it worked ahahahah
I've made tests between my server and my laptop, the bridge is actually offloaded to the switch and the one CPU port isn't used at all, so it woeks perfectly!
Now, between the WAN and the LAN the CPU port is used as expected, but you can fully do downloads at gigabit speed without performance losses.
What I'm thinking is, this is supported upstream, so, supposedly this issue with the MAC's can't happen upstream right?
Your patch works on the latest trunk? And with kernel 4.19?
Also, on another not @ParanoidZoid your patch no longer works since changes were made to the mvebu tree(or whatever it's called) I tried to fix it but got nowhere. cries
1 Like
I've had a look at @LGA1150's branch and it should be easily adopted into 4.14. I'll rebase and merge his/her edits into mine. Still a bit busy - but I should be able to find the time to do it. However, I won't be able to compile/run-test it. And yeah, you'll still need to develop a transition script to run on sysupgrade.
Here's my take with @LGA1150's additional edits for MAC address preservation, adapted for the current master (0111b86), kernel 4.14. Not compile nor runtime tested. Patch version here: https://github.com/jeolives/openwrt/commit/e73361b7afb6ac68ebc4bd670a82aa67a93d2582.patch
Ok, I'll compile it to see if it works, I'll get back to you with some news.
1 Like
A sysupgrade whilst saving settings from a build will result in a soft-brick.
Not really. Even if the ethernet is unavailable after sysupgrade, one can use WiFi or UART to log in and change the network settings 
1 Like
another way would be to manually add the interface before flash... (in the network config have in br-lan both eth0 and lan1 lan2 lan3 lan4)
The router won't complain about missing interface