Tested on v22.03.4
Honestly I have found this behavior starting from a more specific issue, because I am using "ebtables" as L2 firewall. I have configured ebtables in a way that the IEEE1905 multicast is only forwarded to a virtual ethernet interface (veth) which is listened by a daemon made by myself. The WAN port is bridged to br-lan also, as the device is working on L2 mode. A diagraman of this could be:
The ebtables config is:
root@OpenWrt:~# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 11, policy: ACCEPT
-p 0x893a -d 01:80:C2:00:00:13 -i lan1 -j mark --mark-set 0xa --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i lan2 -j mark --mark-set 0xb --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i lan3 -j mark --mark-set 0xc --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i lan4 -j mark --mark-set 0xd --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i wan -j mark --mark-set 0xe --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i bss0 -j mark --mark-set 0xf --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i bss1 -j mark --mark-set 0x10 --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i bss2 -j mark --mark-set 0x11 --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i bss2.sta2 -j mark --mark-set 0x12 --mark-target CONTINUE
-p 0x893a -d 01:80:C2:00:00:13 -i p-1905 -j ACCEPT
-p 0x893a -d 01:80:C2:00:00:13 -o ! p-1905 -j DROP
root@OpenWrt:~# ebtables -t nat -L
Bridge table: nat
Bridge chain: PREROUTING, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Bridge chain: POSTROUTING, entries: 9, policy: ACCEPT
-p 0x893a --mark 0xa -j snat --to-src 34:60:F9:22:6D:F5 --snat-target CONTINUE
-p 0x893a --mark 0xb -j snat --to-src 34:60:F9:22:6D:F6 --snat-target CONTINUE
-p 0x893a --mark 0xc -j snat --to-src 34:60:F9:22:6D:F7 --snat-target CONTINUE
-p 0x893a --mark 0xd -j snat --to-src 34:60:F9:22:6D:F8 --snat-target CONTINUE
-p 0x893a --mark 0xe -j snat --to-src 34:60:F9:22:6D:F0 --snat-target CONTINUE
-p 0x893a --mark 0xf -j snat --to-src 34:60:F9:22:6D:F1 --snat-target CONTINUE
-p 0x893a --mark 0x10 -j snat --to-src 34:60:F9:22:6D:F2 --snat-target CONTINUE
-p 0x893a --mark 0x11 -j snat --to-src 34:60:F9:22:6D:F4 --snat-target CONTINUE
-p 0x893a --mark 0x12 -j snat --to-src 34:60:F9:22:6D:F4 --snat-target CONTINUE
So, with this, I am marking and changing the source MAC address in relationship which the input port, and also all the ingress of IEEE1905 multicast traffic (dest 01:80:C2:00:00:13 , ethertype 0x893a ) will be dropped with exception of the veth interface. But this does not happen. For example, via de WDS the IEEE1905 multicast can be sniffed in any ethernet port, while in the rest of the wireless interfaces this not happens (works as expected).
To clarify any doubt I tested this with the daemon stopped, only with the firewall configured statically, and the behavior was the same. So my first assumption was that the L2 firewall was not working properly.
But the root cause seems to be more basic. Casually today I wanted to sniff some HTTP traffic with wireshark, traffic between my PC which is connected wired, and internet. And I found that I was able to sniff traffic of each device connected to the network. Also traffic between the other LAN devices and internet (wired and wireless LAN devices)
For example, if a wireless device sends upstream traffic from bss1, the traffic is replicated in lan1 to lan4, when it should only be forwarded via WAN interface (which is connected to the internet router)
The bridge table seems not to be indicated this behavior as expected, the mac addresses of the devices appears and only one time:
root@OpenWrt:~# brctl showmacs br-lan
port no mac addr is local? ageing timer
7 00:31:92:04:14:e4 no 2.76
2 04:ed:33:5d:66:3c no 1.81
2 24:46:c8:bb:08:5f no 2.69
2 2c:db:07:54:47:7d no 0.55
10 34:60:f9:22:6d:f0 yes 0.00
10 34:60:f9:22:6d:f0 yes 0.00
1 34:60:f9:22:6d:f1 yes 0.00
1 34:60:f9:22:6d:f1 yes 0.00
2 34:60:f9:22:6d:f2 yes 0.00
2 34:60:f9:22:6d:f2 yes 0.00
3 34:60:f9:22:6d:f4 yes 0.00
3 34:60:f9:22:6d:f4 yes 0.00
5 34:60:f9:22:6d:f5 yes 0.00
5 34:60:f9:22:6d:f5 yes 0.00
6 34:60:f9:22:6d:f6 yes 0.00
6 34:60:f9:22:6d:f6 yes 0.00
7 34:60:f9:22:6d:f7 yes 0.00
7 34:60:f9:22:6d:f7 yes 0.00
8 34:60:f9:22:6d:f8 yes 0.00
8 34:60:f9:22:6d:f8 yes 0.00
9 34:60:f9:22:6d:f9 no 3.22
9 34:60:f9:22:6d:fa yes 0.00
9 34:60:f9:22:6d:fa yes 0.00
4 38:1f:8d:a0:f4:33 no 0.29
10 44:d4:54:a0:0c:f1 no 0.11
4 60:a4:b7:7c:6c:8c no 24.68
4 60:a4:b7:7c:6c:8e no 0.77
4 60:a4:b7:7c:6c:92 no 2.90
5 d4:3d:7e:bc:ec:cf no 0.01
This behavior occurps independently of ebtables, with ebtables cleared this happens in the same way.
So, in short, I think that maybe all the L2 frames, or al least a big part of them, are being broadcasted on all the ethernet interfaces.
I hope that someone has a clue to abord this.
Thanks in advance.
