07:42 <ynezz> blocktrron: hi, thanks for the OWE mbedtls fix! BTW what about https://patchwork.ozlabs.org/project/hostap/patch/20220130192200.10883-1-mail@david-bauer.net/ ? It seems to be good enough as temporary fix/workaround for Arch Linux https://github.com/archlinux/svntogit-packages/commit/35d161737f75d7c9cf339070fd56d21902faa878 so if its fine with you, I would create a PR to include that fix as I've got

07:42 <ynezz> reports, that its broken on ath11k as well.

07:45 <blocktrron> ynezz: feel free to do so

07:45 <ynezz> just unsure about that Jouni remark "this does break some cases like WPS PBC and P2P"

07:46 <blocktrron> Gimme a sec

07:48 <ynezz> maybe we should make this workaround configurable, so only affected users could enable it, so we don't break currently working use cases?

07:48 <blocktrron> no need

07:49 <blocktrron> it does not break existing setups, as they do not set the max-scan-ie length

07:50 <blocktrron> Jounis remark was for the case where scan-ie size is limited that pbc / p2p cases will not work.

07:50 <ynezz> ok, but we can't fix that as that would need fix in the firmware blob, right?

07:51 <blocktrron> We can fix this, as I've also answered to him - we could prioritize IEs to include the "important" ones first until we run out of space.

07:51 <blocktrron> This would still not work for cases where we can not fit a single IE into the scan-request, at this point it is firmware

07:52 <ynezz> ok, good, makes sense, thanks

07:52 <blocktrron> fwiw, debian also ships with that patch

07:53 <ynezz> do you've URL handy? I'll include that in the commit description

07:53 <blocktrron> i would have improved the patch to incorporate his request, but I don't start doing so without a clear path provided

07:53 <blocktrron> sec

07:56 <blocktrron> ynezz: https://salsa.debian.org/debian/wpa/-/commit/7c857728d1e267559935c7fedbb4f24faf9caf8e

07:58 <blocktrron> regarding the owe-fix - the code path was and is still very adventerus

07:58 <blocktrron> As soon as I've made the code work a little, it segfaulted right into my face without adapting the pubkey procedure

08:00 <blocktrron> It seems like I'm the only active user of OWE, given this was already broken in 22.03 (?) with wolfssl at some point :D

08:06 <ynezz> well, it works with openssl :P

08:22 <ynezz> blocktrron: https://github.com/openwrt/openwrt/pull/13806

08:36 <owrt-images-builds> Build [#119](https://buildbot.staging.openwrt.org/images/#/builders/138/builds/119) of `openwrt-23.05_imx/cortexa7` failed.

08:42 <kabel> hauke: regarding PR 13799, how does AutoProbe work? because leds-turris-omnia uses AutoLoad with priority 60, and I want to ensure the mcu driver is loaded before the LEDs driver (there are some changes for the LED driver not yet sent which need this order of loading)

08:47 <blocktrron> ynezz: ... which iw generously surprising to me

09:12 <robimarko> kabel: Is your driver even probeable, meaning does it have a DT compatible or something that can be probed against?

09:25 <KanjiMonster> kabel: if the drivers require a certain load/probe order than this is a bug in the drivers

09:59 <mrkiko> someone here with a Netgear R788 at disposal? Need just to know the kind of power jack it uses (you already know if in #openwrt)

10:59 <lu_zero> can someone point me to the logic used to create the ephemeral partition for the overlay?

11:00 <lu_zero> I'm having a strange situation with the partition created being way too small for no apparent reason

11:01 <kabel> robimarko: it has a dt compatible

11:01 <robimarko> Then you can autoprobe it

11:01 <kabel> KanjiMonster: they dont require it, EPROBE_DEFER works

11:01 <kabel> I just thought that the priorities are used for a reason...

11:01 <kabel> to avoid EPROBE_DEFER

11:10 <KanjiMonster> kabel: there are indirect dependencies where autoload priorities are good for. In general though you shouldn't need to use autoload at all and autoprobe should be fine

12:51 <kabel> what does $(LICENSE_FILES) do? is it used to actually copy the files from sources? becuase BKPepe suggested to put PKG_LICENSE_FILES:=LICENSE into package Makefile, but the tarball from PKG_SOURCE_URL does not contain that file. Only the source repository contains it (the PKG_SOURCE_URL tarball contains only built binaries)

12:52 <kabel> grepping through the repostiory, it seems that LICENSE_FILES is actually only used as a field in package info, the file is not actually used

13:04 <owrt-images-builds> Build [#98](https://buildbot.staging.openwrt.org/images/#/builders/164/builds/98) of `openwrt-23.05_armsr/armv7` completed successfully.

13:57 <linusw> Ansuel: as discussed https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/45

14:13 <KanjiMonster> kabel: since nothing validate the field, you could put a link to the LICENSE file in gitlab there

14:13 <owrt-images-builds> Build [#118](https://buildbot.staging.openwrt.org/images/#/builders/117/builds/118) of `openwrt-23.05_bmips/bcm6358` completed successfully.

15:18 <owrt-images-builds> Build [#117](https://buildbot.staging.openwrt.org/images/#/builders/130/builds/117) of `openwrt-23.05_apm821xx/sata` failed.

15:21 <owrt-images-builds> Build [#115](https://buildbot.staging.openwrt.org/images/#/builders/113/builds/115) of `openwrt-23.05_bcm63xx/smp` failed.

16:15 <hitech95> is there something similar of "spi-cs-setup-delay-ns" f

16:15 <hitech95> on kernel 5.14?

17:53 <Ansuel> hauke should i backport the CI also to 22.04? (i recently moved 23.05 to the unified system we have so main and 23.05 use the same actions)

19:10 <hauke> Ansuel: depends how it is easier to maintain the CI code

19:10 <hauke> we will probably stop maintaining 22.03 in about 6 months

19:10 <hauke> maybe it is easier to keep it seperate

19:12 <Ansuel> well if we introduce new check (like refreshing every package) then 22.03 will also fail (as the new check will apply also there)

19:12 <Ansuel> so that might be a problem

19:34 <schmars[m]> blocktrron: we have the OWE issue too in berlin!

19:35 <schmars[m]> My debugging intel is here https://github.com/freifunk-berlin/bbb-configs/issues/426 - i concluded that transition mode handshake is broken with mbedtls and wolfssl, but could only repro on ipq40xx, and not on ath79 and mt7621

19:35 <schmars[m]> I will test your patch today or tomorrow

19:45 <schmars[m]> the other day i also repro'd a different OWE issue specific to broadcom clients (on fedora macbook air) which can be fixed with a config change (wpa_key_mgmt) https://github.com/freifunk-berlin/bbb-configs/issues/426#issuecomment-1773478672

19:45 <schmars[m]> no clue if that fix might break something

19:47 <schmars[m]> cc ynezz

21:07 <blocktrron> schmars[m]: please report your test results in the PR once you've concluded your tests

21:07 <blocktrron> and thanks for letting me know :)

21:07 <blocktrron> I'll have a look at wolfssl, as you report in your PR it appears to be broken.

21:07 <blocktrron> However I'm using it at precisely this moment without any issue

21:08 <blocktrron> your client is a MBP with fedora in this case, right?

21:09 <schmars[m]> Thinkpad with intel ax201 for the transition mode bug, the macbook was my flatmate's with that broadcom-specific config bug

21:10 <schmars[m]> the transition mode handshake bug we're having might be different from your patch. i'll test regardless

21:21 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)