08:28 <robimarko> Is anyone seeing a weird config behaviour?

08:29 <robimarko> I set my config via menuconfig, then save it, but after the first make run it will rescan the targets again and then throw that config is out of sync?

08:34 <Habbie> i'm pretty sure i read something like that in here earlier this week

08:35 <Habbie> robimarko, https://gist.github.com/Habbie/c8ece60f430dcbc0781ca515988f2b10

08:35 <Habbie> that was on monday (UTC timestamps)

09:04 <robimarko> Habbie: Yeah, seems like that is the same issue

12:16 <nbd> Ansuel: could you please double check your commit "scripts/download.pl: detach mirror URLs from script file" for kernel downloads

12:17 <nbd> it breaks the kernel download url for me

12:17 <Ansuel> nbd let me check

12:17 <nbd> it tries to download "https://cdn.kernel.org/pub/6.6.33/linux-6.6.33.tar.xz", which returns 404

12:17 <nbd> i need to leave now, might take another look later

12:26 <robimarko> Yeah, its not correct

12:27 <robimarko> It should be https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.33.tar.xz

12:27 <Ansuel> magic of perl

12:27 <Ansuel> pushing a fix

13:39 <dwfreed> example?

13:40 <f00b4r0> host -t SRV _http._tcp.pkg.FreeBSD.org

13:43 <f00b4r0> this is maximally annoying when you're trying to run pkg update, of course :)

13:44 <dwfreed> likely has nothing to do with size

13:44 <dwfreed> try _http._tcp.deb.debian.org, which is tiny in comparison

13:44 <f00b4r0> indeed

13:44 <f00b4r0> this is plain maximally annoying then.

13:44 <dwfreed> on my old and crusty 19.07 firmware, both return NOERROR NODATA, with AA bit set

13:53 <dwfreed> f00b4r0: is this on 23.05 ?

13:53 <f00b4r0> 22.03

13:54 <dwfreed> so 2.86

13:58 <dwfreed> f00b4r0: check your dnsmasq config, does it have filterwin2k

13:58 <f00b4r0> oh, it does

13:58 <dwfreed> turn that off

13:58 <dwfreed> mine does too

13:59 <f00b4r0> it works

13:59 <f00b4r0> wunderbar

13:59 <f00b4r0> thanks

14:00 <dwfreed> fixed here now too

14:00 <f00b4r0> i'm fixing all locations ;)

14:04 <dwfreed> so in 19.07, it's labeled "filter useless" in luci

14:05 <dwfreed> quite a misnomer

14:05 <jow> taken from dnsmasq own manpage

14:05 <dwfreed> "Do not forward requests that cannot be answered by public name servers"

14:05 <nbd> Ansuel: thx

14:05 <jow> iirc it has been renamed by now in the ui

14:05 <Znevna> in the docs it isn't :P

14:07 <Znevna> https://github.com/openwrt/luci/commit/8607aa7a6712d6a78e4c8cc1be391fe60b85908c

14:14 <xback> Ansuel: Just noticed this on ath10k-ct 6.7: https://pastebin.com/raw/8CbezyHV

14:15 <Ansuel> open issue and please tag me or i will forget

14:16 <xback> will do

14:25 <Ansuel> robimarko thing should be improved... there are still some really big corner case but IMHO they are not worth to handle... In such condition the user will have much worse problem (corner case is a .config and you just change the target with a dirty config... it will work but you will have dependency of the previous target... having the update the config 2 times won't be a problem in such broken condition)

15:01 <dwfreed> Ansuel: I did some looking into xback's report already, because Tapper reported the same in #openwrt earlier; tim->virtual_map is a flex array, but is specified as size 1, so the fortify check complains

15:01 <dwfreed> Ansuel: this is an upstream kernel bug

15:04 <robimarko> Ansuel: That should be fine enough

15:06 <Ansuel> dwfreed yep and i think it should also be already fixed

15:07 <Ansuel> or eventually it's just a patch to backport?

15:39 <dwfreed> Ansuel: https://github.com/torvalds/linux/commit/2ae5c9248e06dac2c2360be26b4e25f673238337

15:39 <dwfreed> that's what you need

16:15 <Ansuel> https://github.com/openwrt/openwrt/pull/15760

16:15 <Ansuel> thanks

18:15 <hauke> Multiple routers are affected by a bug in NAT handling: https://blog.apnic.net/2024/06/18/off-path-tcp-hijacking-in-nat-enabled-wi-fi-networks/ We fixed it last year here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=75e78bcaab847557ce1782eb2dea9dff9a029171

18:24 <russell--> jow: /me is hacking on a luci menu thing. what controls the order of dropdowns in the topmenu?

18:43 <rtznprmpftl> https://github.com/nicolasberens/openwrt-e1000/tree/ubnt_er-8-xg

18:47 <rtznprmpftl> https://openwrt.org/inbox/toh/ubiquiti/edgerouter_infinity

18:59 <rtznprmpftl> https://github.com/neggles/linux-edgerouter/blob/main/ubnt-config/ER-e1000.config

19:49 <jow> russell--: there should be an "order" key in the menu json files

20:14 <Mangix> https://github.com/openwrt/openwrt/pull/15760/commits/e2bbee6e7f1317ece84c9c2d3cd93c8dcfeb531 is interesting. Sounds like I should do the same in https://github.com/neheb/mwlwifi/commit/a0036c6991c348ab50e91285b29d4f11660a16ca

20:20 <russell--> jow: i see "order" in the dropdown items, but not for the topmenu, e.g. https://github.com/openwrt/luci/blob/master/modules/luci-mod-system/root/usr/share/luci/menu.d/luci-mod-system.json

20:30 <owrt-images-builds> Build [#224](https://buildbot.openwrt.org/images/#/builders/237/builds/224) of `master_bcm27xx/bcm2712` failed.

20:37 <jow> russell--: ah, right. They're not set for top level items

20:38 <jow> russell--: the menu render code will honor the order property if you add it though

20:38 <jow> russell--: if order is absent, `1000` is assumed

20:38 <jow> russell--: if two items have the same prio, lexical order is used as fallback

20:40 <jow> russell--: actually the toplevel order is defined here: https://github.com/openwrt/luci/blob/master/modules/luci-base/root/usr/share/luci/menu.d/luci-base.json

20:40 <russell--> jow: aha! thank you!

20:42 <russell--> can i override that in the luci-mod-foo package?

20:49 <russell--> answer: yes. yes, you can.

22:29 <neggles> rtznprmpftl: why are you looking at edgerouter infinity

22:29 <neggles> there be dragons

22:30 <neggles> Octeons truly are a fate worse than death

22:56 <mrnuke> Habbie, Ansuel: Thank you for hearing my complaint a couple of days ago!

22:58 <Ansuel> hope it can stay that way for long but i doubt

22:58 <Ansuel> summer brings lots of free time to troll