00:00 <jow> you should see a bunch of chatter in response to `ubus call uci apply`

00:00 <jow> this will emit at least one config change event for wireless

00:00 <jow> which in turn should trigger more actrivity

00:00 <jow> *ubus monitor

00:00 <\x> okay

00:01 <\x> ill try

00:01 <jow> ubus monitor will also show the data back-and-forth between mac80211.sh & netifd

00:02 <jow> my hunch is that the timing of the luci actions triggers the bug

00:02 <jow> need to hit the bed now, bbl

00:02 <\x> ap is out and such, as for ubus monitor, i got kinda flooded by usteer mssages

00:02 <\x> brb

00:04 <djfe> update

00:05 <djfe> gn8 jow :)

00:09 <\x> https://pastebin.com/raw/516sRSFL

00:09 <\x> here, seems to work, im disabling radio1

00:09 <\x> this is with the button on luci

00:12 <\x> then like this https://pastebin.com/raw/bHhspyrM

00:12 <\x> >"radio1":{"up":false,"pending":false,"autostart":true,"disabled":true,

00:14 <djfe> I tested my Linksys MR8300 as well (read 01:53:54 CEST), ipq40xx is not affected by the LuCI bug. But thanks for taking a look at yours as well :)

00:14 <\x> np

01:15 <SlimeyX> https://github.com/openwrt/openwrt/pull/12850

01:51 <djfe> jow: another issue popped up last week regarding the new naming scheme for wifi if-names

01:52 <djfe> https://github.com/openwrt/openwrt/issues/12788

01:54 <djfe> we could think about whether we want to keep the new naming scheme or atleast figure out what the intentions were behind the rename. I don't care for the rename (it's ok imo) and I think it helps once you have several if-names per phy. But seeing this new issue: maybe we should also mention it in the release notes

01:56 <djfe> but maybe the code should be fixed first.

01:57 <djfe> out of curiosity: Was the new naming scheme ever discussed? https://github.com/openwrt/openwrt/commit/6603748e0ca697f484adfc16a0d49d35ed36954d

03:30 <mrkiko> hauke: thanks a lot for the info

03:31 <mrkiko> hau and for your announce

05:36 <hgl> TianlingShen

05:36 <hgl> sorry, misclicked

05:38 <TianlingShen[m]> ^^

08:22 <Tapper> Test

11:46 <raenye> What determines the order of wireless radios when there's more than one? (i.e., whether 5ghz is phy0 or phy1)

11:47 <raenye> I noticed ath79 tends to have 5ghz first, while ramips has 2.4 first

12:11 <mrkiko> raenye: various factors I guess, including how the radios are connected to the device + bus drivers specific I guess

12:11 <mrkiko> raenye: and infact udevd will force some ordering in full blown systems

12:58 <raenye> mrkiko: thanks. So I guess I should just accept it

13:00 <raenye> Also, I'm struggling to get ag71xx to accept lan mac address from mtd partition via .dts (I know this can be done in pre-init 10_fix...)

17:58 <enyc> WooHoo, I now have a FritzBox 7530 OpenWRT 23.05rc1 working ... Anything in particular I could be helpfully testing?

17:59 <enyc> has 2* usb ports -- can I get RNDIS ethernet usb's into it to get more ports without separate power supply ?? 100mbps would be fine for 2 cases ... ? Is that a $pain with openwrt software?

18:00 <enyc> oh, 1 port actually

18:51 <Znevna> is there any new thing cooking that might give control over the hardware controlled LEDs on mt7530 in the near future?

18:51 <Znevna> (at least the ability to turn them off)

19:39 <Ansuel> Znevna it really depends on the hw and the presence of documentation

19:39 <Ansuel> nothing fancy to implement them

19:40 <Ansuel> it's really just implement some logic to abstract regs to different LEDs and fill the different API

21:46 <mrkiko> enyc: wow! Are you using VDSL?

23:05 <mrkiko> I am expecting to see the menu option to choose rootfs data partition size, but can't see it while compiling for ipq4xx/gl-b2200 that uses emmc

23:25 <dwfreed> mrkiko: openwrt uses the existing partitions; that device has separate partitions for rom and overlay

23:31 <mrkiko> solved