07:28 <f00b4r0> is there an easy way to macfilter an entire range of mac addresses (at the wifi ap interface level)?

07:29 <f00b4r0> nbd: the Tuya "device of death" bug we discussed a while ago is quite real and painful

07:30 <f00b4r0> however using hostapd macfilter to prevent assoc seems to be enough to "shield"

07:30 <f00b4r0> so I'd like to ban the Tuya MAC prefix ;P

07:31 <f00b4r0> I'm guessing the hardware may not support that though

07:51 <nbd> f00b4r0: can you easily reproduce the issue at the moment? or do you have to wait for a while every time?

07:52 <f00b4r0> apparently all it takes is such a device in range and then wait a (usually short) while for the AP to crash

07:55 <f00b4r0> btw on a side topic, in turns out that #11650 is affecting filogic devices with mt7531 switches (or so it seems, I want to do a test with the MT6000 using the 2.5G ports to confirm whether it's related only to the mt7531 or not) on 24.10, but not ramips with mt7530 anymore, something I failed to report

08:06 <nbd> f00b4r0: how does the AP crash exactly?

08:07 <nbd> kernel trace, firmware crash?

08:07 <f00b4r0> iirc kernel panic, I had pasted a dump for you back then. Let me try to find it again, hold on

08:13 <f00b4r0> nbd: https://pastes.io/crash-7216 I've unearthed this from last December, that's on a Yuncore AX820 (dreaded devices). "a0:92:08:2e:9f:88" is Tuya. Stock 24.10 kernel from whatever was current at the time

08:13 <f00b4r0> I think I have a more recent one somewhere.

08:13 <nbd> i need a crash dump with KALLSYMS enabled

08:13 <nbd> preferably from a recent version

08:14 <f00b4r0> not easy. Last time you mentioned you could get the symbol info since this was stock kernel

08:15 <nbd> when i tried, i didn't get proper symbols

08:15 <f00b4r0> damn

08:15 <nbd> does the tuya device need to be fully configured, or just looking for APs?

08:16 <f00b4r0> we don't know what these devices are tbh

08:16 <f00b4r0> from the AP's pov, it seems they try to assoc to all available SSIDs

08:16 <f00b4r0> open or encrypted

08:16 <nbd> ok

08:17 <f00b4r0> we see floods of "STA d8:d6:68:d8:c7:a6 IEEE 802.11: did not acknowledge authentication response"

08:17 <f00b4r0> (for a current example - although this one isn't yet triggering the crash)

08:18 <f00b4r0> in between are "STA d8:d6:68:d8:c7:a6 IEEE 802.11: deauthenticated due to local deauth request"

08:19 <f00b4r0> these messages are typically in bursts of 2-3 every 2-3 seconds, completely saturating the logs

08:28 <f00b4r0> crap, the dual VLAN entry also happens when using the 2.5G ports on MT6000, so it's not mt7531-related

08:29 <nbd> f00b4r0: i think i have an idea about the cause of the crashes

08:29 <f00b4r0> awesome

08:29 <nbd> i'll make a patch

08:32 <f00b4r0> would you happen to have a suggestion as where to look for the source of the issue I'm dealing with on filogic (in a nutshell: APs with vlan-aware bridge, SSIDs bridged to a tagged vlan, when a client connects the AP puts on the ethernet side two ARP frames one on the tagged vlan and one on the same port's untagged vlan - seen from the remote end of the ethernet port)

08:32 <f00b4r0> I'm about to start spraying printk()s in the kernel

08:33 <f00b4r0> that's how desperate I am ;P

08:40 <nbd> f00b4r0: please test if this patch helps: https://nbd.name/p/ae0c34b9

08:40 <nbd> should replace the crash with a WARN_ON

08:40 <nbd> at least if i picked the right place

08:41 <f00b4r0> ok. I can dump this in mt76/patches and rebuild, correct?

08:41 <noltari> Hi all, I've been working on making odhcpd compliant with RFC9096 (at least with SLAAC, DHCPv6 requires some work and I haven't looked into it).

08:41 <noltari> Feel free to review my PRs -> https://github.com/openwrt/odhcpd/pull/245 https://github.com/openwrt/netifd/pull/53

08:41 <noltari> Feedback is more than welcome. Hopefully we can fix the IPv6 stale addresses issue for those who receive dynamic IPv6 prefixes from our ISPs like me.

08:41 <nbd> f00b4r0: yes

08:41 <f00b4r0> ok thx

08:59 <ukleinek> noltari: without having looked, there is an annoying issue with ipv6 RAs: If you have two machines sending out RAs, the respective netif usually has addresses that should be ignored for calculating the content of the RA.

09:00 <ukleinek> So IMHO I think it's a broken concept to look at the configured addresses for announcing e.g. the used prefix. The source of truth should be /etc/config/network instead.

09:00 <ukleinek> noltari: just saying as you touched the code in that region.

11:12 <f00b4r0> nbd: patch deployed on a few devices prone to the issue, now we wait. I'll let you know what comes up; meanwhile I'll keep digging that filogic issue (it makes it impossible for us to use filogic devices as dumb APs)

11:13 <nbd> what issue is that?

11:13 <f00b4r0> similar to #11650

11:14 <f00b4r0> when a client connects to an SSID bridged to a tagged VLAN, on the ethernet side of things, two fdb entries appear: one for the tagged VLAN, and one for the default untagged one

11:14 <f00b4r0> after a while, this causes all sorts of problems

11:15 <f00b4r0> mainly DHCP breakage as replies no longer reach the target

11:17 <f00b4r0> as seen from the main router, this looks like this:

11:18 <f00b4r0> a6:18:fc:45:ff:0f dev eth0 vlan 8 master vbridge0

11:18 <f00b4r0> a6:18:fc:45:ff:0f dev eth0 vlan 2 master vbridge0

11:18 <f00b4r0> here, vlan 2 is the tagged one to which the remote wifi client connected on the dumb AP, and vlan 8 is the default untagged vlan (on the same ethernet port)

11:18 <f00b4r0> (output of bridge monitor on main router)

11:19 <f00b4r0> (main router and dumb AP have identical vlan-aware bridge config)

11:31 <f00b4r0> at least this one is very easy to reproduce

11:31 <f00b4r0> anyhow, lunch break ;)

13:39 <f00b4r0> nbd: the confusing part for me is I'm not sure if I should look for the culprit in linux tree or in the mt76 tree

14:16 <f00b4r0> since this affects a PHY that's not part of the onboard switch I'm tempted to assume this is unrelated to DSA

14:18 <f00b4r0> oh! It actually does *not* affect the ports that are on the DSA link

14:44 <f00b4r0> same thing on the CF devices. Only the direct-attached PHY (eth1 in both cases) is affected

14:46 <f00b4r0> nbd: just thinking out loud here but is it possible that said PHY is treated as a switch CPU-phy somewhere in the code? Could this explain the bogus VLAN assignment that's probably normally filtered out by the switch?

16:34 <djfe> castiel652: please pm me if you are online :)

17:29 <f00b4r0> narrowed down to two possible offending patches, yay

17:29 <f00b4r0> hauke: I'm told you want to tag .3, I may have a patch to propose in a few moments that fixes a very annoying bug on mediatek devices

18:03 <f00b4r0> false alarm, *sigh*

18:13 <f00b4r0> I guess I'll need nbd's help on this one, I'm lost in the code

18:25 <plappermaul> anyone here who knows details about uci/netifd interaction?