kernel: add a bridge feature for filtering BPDU packets on ports

[Andre Heider]

On 27/09/2021 22:25, Martin Blumenstingl wrote:
> On Sat, Sep 25, 2021 at 6:53 PM Martin Blumenstingl
> <martin.blumenstingl at googlemail.com> wrote:
>>
>> Hi Andre,
>>
>> On Sat, Sep 25, 2021 at 1:17 PM Andre Heider <a.heider at gmail.com> wrote:
>> [...]
>>> With these 3 reverted (on top of da5bb885 "toolchain/gcc: switch to
>>> version 11 by default") it works again:
>>> Revert "hostapd: let netifd set bridge port attributes for snooping"
>>> Revert "netifd: update to the latest version"
>>> Revert "kernel: add a bridge feature for filtering BPDU packets on ports"
>> thanks for investigating this!
>>
>>> With just the first 2 reverts it's still broken.
>> I can confirm that reverting all three fixes communication between
>> clients on the ath10k 802.11ac card on Home Hub 5A
>> communication between a client connected to the ath9k 802.11bgn card
>> and ath10k worked fine even without the revert on the Home Hub 5A.
> it seems that commit 6cd54254e4bbe7ed2b71c17cb2d54ad7b0bc2991
> ("netifd: update to the latest version") fixed this issue for me

Thanks, but unfortunately it doesn't for me.

And it would have been surprising, since my last reverts hinted that not 
enabling bpdu is the problem, but maybe the kernel patch that introduced 
the bpdu knob.

With current master as of now (without any reverts) some clients still 
can't reach others (this time I tried one connected to the bgn master 
reaching another connected to the ap). They can still reach the router 
though and hence have internet access.

If I ping 192.168.0.100 from such a client (192.168.0.226 in this case) 
I see this on the router:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on $bgnmaster, link-type EN10MB (Ethernet), capture size 
262144 bytes
09:02:30.369914 IP 192.168.0.226.137 > 192.168.0.1.137: UDP, length 68
09:02:30.370345 IP 192.168.0.1 > 192.168.0.226: ICMP 192.168.0.1 udp 
port 137 unreachable, length 104
09:02:30.498273 ARP, Request who-has 192.168.0.100 tell 192.168.0.226, 
length 28
09:02:31.493549 ARP, Request who-has 192.168.0.100 tell 192.168.0.226, 
length 28
09:02:32.491840 ARP, Request who-has 192.168.0.100 tell 192.168.0.226, 
length 28

Looks like a missing arp reply.

Also from the router:
$ cat /sys/class/net/*/brport/bpdu_filter
0
0
0
0
0
0
0

But if I now switch back to what I thought was a known working version, 
it still doesn't work. So maybe it's something different entirely, like 
a race condition or order of setting up things that doesn't hit on every 
boot?

Puzzled,
Andre