01:00 <tersono> I'm just updating a feed of packages to build on OpenWrt 24.10; it looks like the PKG_MIRROR_HASH for packages that use PKG_SOURCE_PROTO:=git changes between 23.x and 14.10 due to the change to compress as zst by default. Is this expected?

01:20 <tersono> Actually, even manually setting a .xz extension in PKG_SOURCE doesn't result in matching hashes because the PKG_VERSION is now in a slightly different format and a change related to gitattributes results in the .gitmodules file no longer being in the archive. So overall it looks like supporting different OpenWrt versions in the same feed is an uphill battle?

02:28 <dwfreed> you could set PKG_MIRROR_HASH based on which openwrt version is being built

07:52 <owrt-images-builds> Build [#134](https://buildbot.openwrt.org/images/#/builders/70/builds/134) of `openwrt-24.10_mvebu/cortexa53` failed: failed Packages built (failure)

08:56 <Cahata> hello, ngircd package still in 26.1-r1 version instead of 27 (alredy there from 2024-04-26 )

08:57 <Cahata> 26.1-r1 still have nasty flaw is there version 27 as package in future ? its still only ircd in the world who can run without services with predefined channels and mods great for minimal ircd on router

16:07 <f00b4r0> hmm, is there a new wifi exploit in the wild? I'm seeing some strange MAC addresses registered to "Tuya Smart Inc." that seems to "auth" (how?) without acknowledging auth response to all broadcasted SSIDs from a given AP and do something that eventually results in a kernel panic (rcu-sched stall after list_del corruption in napi/phy) on mt76/mt7915e

16:07 <f00b4r0> schmars[m]: ever seen something like that?

16:08 <f00b4r0> 24.10 ends up crashing. 23.05 seems to survive this madness

16:26 <nbd> f00b4r0: can you please show me traces?

16:26 <dwfreed> f00b4r0: it's less likely an exploit and more likely some really stupid IoT garbage just trying every visible SSID

16:27 <dwfreed> Tuya is a brand of IoT stuff

16:27 <f00b4r0> my impression as well however the fact that they apparently auth to WPA-enabled SSIDs is, well, weird

16:28 <f00b4r0> then again I don't know the physical setup, it's possible someone did something stupid. It also tries to assoc to multiples BSSIDs (multiple APs broadcasting the same SSID)

16:28 <f00b4r0> nbd: I'll dump that for you

16:28 <dwfreed> does hostapd say they're successful? or are they just starting the 4 way handshake and failing

16:28 <f00b4r0> hostapd reports "auth=true" in get_clients ubus call

16:28 <f00b4r0> the logs are littered with 'daemon.notice hostapd: phy0-ap2: STA c4:82:e1:ae:93:07 IEEE 802.11: did not acknowledge authentication response'

16:29 <f00b4r0> nbd: https://pastebin.com/0pLB6K0j

16:30 <f00b4r0> most relevant dmesg

16:30 <f00b4r0> i can provide output of logread although it's stuffed with the above message

16:30 <dwfreed> might be worth capturing the air traffic as well

16:30 <nbd> can you please re-enable kallsyms in your builds to get a proper backtrace?

16:31 <f00b4r0> that'll take time

16:33 <f00b4r0> nbd: in case this matters, this is a stock kernel, we're using ImageBuilder

16:34 <nbd> ah, okay

16:34 <nbd> i'll try to decode the dump later

16:34 <nbd> thx

16:34 <f00b4r0> np

16:35 <f00b4r0> we're being as stock as possible precisely to not introduce extra bugs and to be able to report actual "upstream" breakage :)

19:08 <sur5r> Uhm, am I holding this wrong? "make target/linux/refresh" seems to be reverting changes I made to a patch instead of refreshing the patch...

19:12 <sur5r> Hm, now it worked