Re: kernel: add a bridge feature for filtering BPDU packets on ports
On 2021-09-28 13:49, Andre Heider wrote: > On 28/09/2021 12:20, Andre Heider wrote: >> fyi brport/proxyarp was still "0" too, which probably means that the >> netidf condition "if (up && ifname != vif->ifname)" doesn't eval to true >> as that's the only spot setting "dev->wireless_proxyarp". > > That pointed me in the right direction, attached netifd patch fixes the > issue for me. lol. Your patch looks correct to me, thanks for looking into this. I've pushed it out, but extended the commit description a bit. Not only was the use of strcmp necessary, but the previous logic was inverted as well. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
On 28/09/2021 12:20, Andre Heider wrote:
fyi brport/proxyarp was still "0" too, which probably means that the
netidf condition "if (up && ifname != vif->ifname)" doesn't eval to true
as that's the only spot setting "dev->wireless_proxyarp".
That pointed me in the right direction, attached netifd patch fixes the
issue for me. lol.From 76b389cde9de3208936c8cc4ed35cf42992a8dc7 Mon Sep 17 00:00:00 2001
From: Andre Heider
Date: Tue, 28 Sep 2021 13:29:27 +0200
Subject: [PATCH] wireless: fix applying wireless devices attributes on hotplug
events
Hotplug events pass their own 'ifname' copy, so we need to compare the
strings, not just the pointers.
Signed-off-by: Andre Heider
---
wireless.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wireless.c b/wireless.c
index fbd42ed..4b1fb8e 100644
--- a/wireless.c
+++ b/wireless.c
@@ -328,7 +328,7 @@ static void wireless_interface_handle_link(struct wireless_interface *vif, const
if (!ifname)
ifname = vif->ifname;
- if (up && ifname != vif->ifname) {
+ if (up && !strcmp(ifname, vif->ifname)) {
struct device *dev = device_get(ifname, 2);
if (dev) {
dev->wireless_isolate = vif->isolate;
--
2.33.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
Sorry for the spam, last mail for now as I found some log entries that might be related (HEAD=6cd54254e4bbe7ed2b71c17cb2d54ad7b0bc2991): kern.warn kernel: [ 55.820638] netlink: 'iw': attribute type 302 has an invalid length. kern.warn kernel: [ 56.354160] netlink: 'iw': attribute type 302 has an invalid length. daemon.notice wpa_supplicant[2028]: mesh: MESH-PEER-CONNECTED $mac kern.warn kernel: [ 76.849584] [ cut here ] kern.warn kernel: [ 76.852852] WARNING: CPU: 0 PID: 5298 at net/core/flow_dissector.c:975 __skb_flow_dissect+0x21c/0x1894 kern.warn kernel: [ 76.862457] Modules linked in: ath9k ath9k_common xt_connlimit pppoe ppp_async nf_conncount iptable_nat ath9k_hw ath10k_pci ath10k_core ath xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_CT wireguard pppox ppp_generic pl2303 nf_nat nf_conntrack_netlink nf_conntrack mac80211 libchacha20poly1305 libblake2s ipt_REJECT ftdi_sio cfg80211 ath9k_pci_owl_loader xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY usbserial slhc sch_cake poly1305_mips nf_reject_ipv4 nf_log_ipv4 nf_log_common nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libblake2s_generic iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat chacha_mips sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred act_gact drv_dsl_cpe_api ledtrig_usbport drv_mei_cpe kern.warn kernel: [ 76.863496] xt_set x_tables ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ifb ip6_udp_tunnel udp_tunnel br2684 atm zram zsmalloc drv_ifxos sha256_generic libsha256 seqiv jitterentropy_rng drbg hmac cmac dwc2 roles ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug kern.warn kernel: [ 76.998750] CPU: 0 PID: 5298 Comm: sh Not tainted 5.10.64 #0 kern.warn kernel: [ 77.004303] Stack : 80a28218 8079d544 0001 80083264 kern.warn kernel: [ 77.012650] 000c a4d9dc81 80c0bbc4 0001 80c0bb58 a4d9dc81 kern.warn kernel: [ 77.021006] 8076c9b0 80c0ba00 efff ffea kern.warn kernel: [ 77.029362] 0156 80c0ba08 8083 8083 8000 8077 kern.warn kernel: [ 77.037712] 0009 8083 0018 0030 80a0 kern.warn kernel: [ 77.046074] ... kern.warn kernel: [ 77.048506] Call Trace: kern.warn kernel: [ 77.050965] [<8000bf54>] show_stack+0x40/0x128 kern.warn kernel: [ 77.055408] [<8035de84>] dump_stack+0x9c/0xcc kern.warn kernel: [ 77.059776] [<80030bd8>] __warn+0xc0/0x12c kern.warn kernel: [ 77.063841] [<80030cb4>] warn_slowpath_fmt+0x70/0xd8 kern.warn kernel: [ 77.068817] [<804c7b90>] __skb_flow_dissect+0x21c/0x1894 kern.warn kernel: [ 77.074122] [<804c9380>] __skb_get_hash+0x7c/0x128 kern.warn kernel: [ 77.079043] [<82a3aa28>] ieee80211_schedule_txq+0x784/0xa24 [mac80211] kern.warn kernel: [ 77.085490] kern.warn kernel: [ 77.086994] ---[ end trace f966cd7c4a091c65 ]--- daemon.notice hostapd: $bgnmaster: interface state COUNTRY_UPDATE->ENABLED daemon.notice hostapd: $bgnmaster: AP-ENABLED daemon.notice hostapd: $nacmaster: interface state COUNTRY_UPDATE->ENABLED daemon.notice hostapd: $nacmaster: AP-ENABLED daemon.notice netifd: Network device '$bgnmaster' link is up daemon.notice netifd: Network device '$guestmaster' link is up daemon.notice netifd: Interface 'guests' is enabled daemon.notice netifd: Interface 'guests' is setting up now daemon.notice netifd: Interface 'guests' is now up daemon.notice netifd: Interface 'guests' has link connectivity kern.info kernel: [ 71.979551] br-lan: port 5($nacmaster) entered disabled state daemon.notice netifd: radio0 (2821): command failed: Link has been severed (-67) daemon.notice netifd: radio0 (2821): command failed: Link has been severed (-67) kern.info kernel: [ 72.905264] br-lan: port 7(mesh) entered blocking state kern.info kernel: [ 72.909227] br-lan: port 7(mesh) entered disabled state kern.info kernel: [ 72.915258] device mesh entered promiscuous mode ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
On 28/09/2021 12:08, Andre Heider wrote: On 28/09/2021 09:54, Andre Heider wrote: [...] 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? Updated again to current master without reverts. Problem exists after boot, and it turns out hairpin_mode wasn't set for both APs. After: echo "1" > /sys/class/net/$nacmaster/brport/hairpin_mode echo "1" > /sys/class/net/$bgnmaster/brport/hairpin_mode It starts working again! Cheers, Andre fyi brport/proxyarp was still "0" too, which probably means that the netidf condition "if (up && ifname != vif->ifname)" doesn't eval to true as that's the only spot setting "dev->wireless_proxyarp". Dunno if all that is related due to my "ifname" config? For all "config wifi-iface" I have "option ifname" set to the same value as "option ssid". Cheers, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
On 28/09/2021 09:54, Andre Heider wrote: [...] 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? Updated again to current master without reverts. Problem exists after boot, and it turns out hairpin_mode wasn't set for both APs. After: echo "1" > /sys/class/net/$nacmaster/brport/hairpin_mode echo "1" > /sys/class/net/$bgnmaster/brport/hairpin_mode It starts working again! Cheers, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
On 27/09/2021 22:25, Martin Blumenstingl wrote:
On Sat, Sep 25, 2021 at 6:53 PM Martin Blumenstingl
wrote:
Hi Andre,
On Sat, Sep 25, 2021 at 1:17 PM Andre Heider 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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sat, Sep 25, 2021 at 6:53 PM Martin Blumenstingl
wrote:
>
> Hi Andre,
>
> On Sat, Sep 25, 2021 at 1:17 PM Andre Heider 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
Best regards,
Martin
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Andre, On Sat, Sep 25, 2021 at 1:17 PM Andre Heider 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. Best regards, Martin --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: kernel: add a bridge feature for filtering BPDU packets on ports
Hi Felix, I think there's a problem with a4b5bc20 "kernel: add a bridge feature for filtering BPDU packets on ports" My lantiq/xrx200 router has 2 radios with 2 wireless networks each: * nac * mesh point * master * bgn * master * master (guests, isolated) The first three are bridged with the lan ports. Before the patch in question clients connected to the bgn master can reach clients connected to the nac master (like a simple ping). With the patch that doesn't work anymore. Only clients connected to the nac master can reach other clients (but weirdly that doesn't seem to apply to all clients, only some). Toggling the isolated option on the guest master doesn't make a difference (as it seems to have a similar effect). 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" With just the first 2 reverts it's still broken. Any idea? Cheers, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
