10:29 <yuka> my wpa_supplicant keeps disconnecting from my wifi with kernel asahi-6.6-2, does anyone else have that?

10:38 <yuka> "wlp1s0f0: CTRL-EVENT-DISCONNECTED bssid=xx:xx:xx:xx:xx:xx reason=3 locally_generated=1"

11:27 <yuka> this is a regression from asahi-5.5-29

11:36 <mps> yuka: don't know about wpa_s but iwd works fine with 6.6-2

11:38 <yuka> it only happens with my unifi wifi

11:38 <yuka> not with pixel android hotspot

11:42 <j`ey> yuka: DannyB did most (all?) of the changes to the brcm driver recently, I invited him here, so maybe he can help at some point if you dont fix it beofre then

11:43 <yuka> I'm rebuilding my kernel with BRCMDBG y BRCM_TRACING y now :)

12:23 <yuka> https://termbin.com/x82w

14:58 <yuka> DannyB: I'm seeing a bug with the brcmfmac on https://github.com/AsahiLinux/linux/tree/asahi-6.6-2, while https://github.com/AsahiLinux/linux/tree/asahi-6.5-29 works.

14:58 <DannyB> logs?

14:58 <yuka> my home wifi (unifi) is being disconnected once per minute: https://termbin.com/mpi3

14:59 <DannyB> What kind of auth do you use?

15:00 <yuka> WPA2 PSK

15:00 <yuka> I think

15:00 <DannyB> This is fedora 39?

15:00 <DannyB> or 38?

15:01 <DannyB> I ask becasue it's using wpa_supplicant which is weird

15:01 <yuka> it's not fedora

15:01 <yuka> which is why we are in #asahi-alt :)

15:01 <DannyB> ah

15:01 <DannyB> oaky

15:01 <yuka> NixOS

15:02 <yuka> at least my wpa_supplicant.conf only has an "ssid=" and "key=" for this wifi, so no sae_password or anything

15:02 <DannyB> Okay, so what's happening is that there is some bad interaction with the external supplicant. Can you recompile a kernel? If so i can make this very easy to debug. If not, i can figure it out but it will take longer

15:02 <yuka> I can recompile the kernel

15:04 <DannyB> Can you set the options BRCM_TRACING and BRCMDBG in your kernel config, and then shove options brcmfmac debug=1097734 in /etc/modprobe.d/brcmfmac.conf

15:04 <DannyB> That will tell me what commands it's sending back and forth tot he chip and what the response is

15:04 <yuka> good that I already rebuilt with those options :)

15:04 <DannyB> oh

15:05 <DannyB> then yeah you can just rmmod it and re-modprobe it

15:05 <DannyB> with those options

15:07 <DannyB> i think what is happening is that the management frame handling is screwed up somehow

15:07 <DannyB> still

15:08 <j`ey> DannyB: thanks for joining!

15:16 <DannyB> Oh, the patch to handle management frames properly never made it into the branch

15:17 <DannyB> oh no it didn, looking at wrong branch

15:19 <DannyB> oh, i know what it is

15:19 <DannyB> i think

15:19 <DannyB> give me a sec i'll send you a patch

15:22 <yuka> https://termbin.com/q6wvm

15:22 <DannyB> https://gist.github.com/dberlin/b7ef32f592f338c360f35b03ee3abad2

15:23 <yuka> perfect, I'll try that

15:24 <DannyB> actually one sec that's not complete, i forgot a function or two

15:24 <DannyB> i forgot to add the external auth function on the branch

15:29 <DannyB> try

15:29 <DannyB> https://gist.github.com/dberlin/d9641f8fce059519e5943173ead4a5bc

15:29 <DannyB> instead

15:30 <yuka> do you have a base commit for that?

15:33 <DannyB> This is against the current asahi-wip branch

15:33 <DannyB> FWIW, it may not be enough, but if that's the case, i know what is missing :)

15:38 <yuka> does not apply cleanly to asahi-wip. last item in brcmf_cfg80211_ops is .del_pmk and not .set_cqm_rssi_config

15:38 <yuka> but I am building it now

15:39 <yuka> https://termbin.com/to6o

15:39 <yuka> ^ this does actually apply

15:43 <DannyB> got it

15:43 <DannyB> oh

15:43 <DannyB> i know why

15:43 <DannyB> yes that's my fault

15:44 <DannyB> i have patches i haven't sent yet for that iece

15:44 <DannyB> that are under this

15:44 <yuka> fails to compile: https://termbin.com/kw5p

15:45 <DannyB> let me rebase it myself against asahi-wip and paste a new one

15:45 <yuka> yes, thanks!

16:27 <DannyB> okay, try https://gist.github.com/dberlin/fd3b611cfd2c2ff7510ea2180893368e

16:27 <DannyB> that should apply to asahi-wip

16:27 <DannyB> i hope

16:27 <DannyB> ;)

16:40 <yuka> it does apply

16:48 <DannyB> As an aside

16:48 <DannyB> you should get out of the land of wpa_supplicant if you can.

16:48 <DannyB> One thing you are losing by doing this is that is not setting up PSK offload

16:48 <DannyB> i think i added code that may turn it on in this case, but you are going to discover whether it works or not :)

16:49 <yuka> migrating the config is work

16:50 <yuka> sadly it doesn't work

16:50 <yuka> I'm still being disconnected

16:54 <DannyB> Send me the logs

16:57 <yuka> DannyB: https://termbin.com/tptfw

16:58 <DannyB> so it acutally connected this time

16:58 <DannyB> so progress

16:59 <DannyB> it looks like it's not getting the key at this point

17:01 <yuka> it's the same behavior as without the patch: it connects, stays connected, and after about one minute disconnects with "reason=3 locally_generated=1"

17:07 <DannyB> Yes, but that's not what was really happening

17:07 <DannyB> you are looking at what wpa supplicant is saying

17:07 <DannyB> i'm looking at what the chip is saying :)

17:08 <DannyB> the chip before was saying it couldn't handle external station auth

17:08 <DannyB> that is what the Nov 28 16:20:29 m1 wpa_supplicant[1433]: nl80211: kernel reports: Registration to specific type not supported

17:08 <DannyB> means

17:08 <DannyB> and so it was not even trying to hande the management frames to wpa_supplicant

17:11 <DannyB> Can you set the debug options to 1098758 and regenerate the log

17:51 <yuka> DannyB: https://termbin.com/kqng

18:03 <DannyB> okay, this is odd

18:03 <DannyB> but i think i can fix it

18:15 <DannyB> so what is happening is acutally that wpa_supplicant is asking us to disocnnect

18:16 <yuka> but why is it doing that with one kernel version and not another?

18:25 <DannyB> So i think maybe this thing by marcan broke it by accident

18:25 <DannyB> because it's the only real change i see

18:25 <DannyB> the patch i gave you would work if supplicant was doing it one way but it's not

18:25 <DannyB> and the way it's doing it this is the only code path difference

18:25 <DannyB> let's give it a shit

18:25 <DannyB> shot

18:31 <DannyB> https://gist.github.com/dberlin/31401500fcd83d5cee0effac49a5dce4

18:47 <yuka> DannyB: with this patch it does not manage to establish the connection in the first place. https://termbin.com/ce53

18:48 <yuka> At this point it might be easier for me to move to iwd, however other users of non-Fedora asahi might run into it as well

18:49 <yuka> I'm also patient and thankful if someone wants to continue debugging

18:59 <DannyB> Yeah what the supplicant is doing doesn' make any sense

18:59 <DannyB> what is happening is that we connect

18:59 <DannyB> and report we connected

18:59 <DannyB> and everything is fine

18:59 <DannyB> and it sends a deauth message for no obvious reason

18:59 <DannyB> so we disconnect

18:59 <DannyB> i don't get it

19:00 <DannyB> Most of this code was broken in past kernels

19:00 <DannyB> and wpa supplicant was getting lucky somehow

19:00 <DannyB> it's now not lucky

19:00 <yuka> oef

19:01 <DannyB> The last thig i would try is the following, which reverts support for more auth suites

19:01 <DannyB> https://gist.github.com/dberlin/3cd1f07383d98b6fd7e5eb97f4e1faaa

19:16 <janneg> fedora asahi uses wpa-supplicant but is patched. I'm only aware of patches for sae offload though

20:03 <mps> how/where I can see packaging scripts/source for mesa-asahi on gentoo

20:04 <j`ey> https://github.com/chadmed/asahi-overlay/tree/main/media-libs/mesa

20:04 <mps> j`ey: thanks

20:05 <mps> oh, they also use old one

20:06 <mps> ah, and one of newest 20231120

20:06 <mps> good

20:08 <j`ey> there's 20231126 now too

20:09 <j`ey> hm, failed to build for fedora though

20:10 <mps> j`ey: I don't see 20231126 in https://github.com/chadmed/asahi-overlay/tree/main/media-libs/mesa

20:10 <mps> I've built 20231126 for alpine and it works with some issues

20:10 <j`ey> upstream I meant: https://gitlab.freedesktop.org/asahi/mesa/-/tags

20:11 <mps> ah, ok, understand

20:11 <mps> yes, I'm using 20231126 two days now

20:12 <mps> but don't want to merge to alpine because I see some issues

20:12 <DannyB> janneg: There is nothing obvious in why the wpa_supplicant is choosing to disconnect in his case. With the patches (except the last one), it connects successfully, we report a successful connection, then the *suppllicant* decides to disconnect us anyway and we disconnect. it is not the driver deciding to disconnect on its own. The reason it gives us "DEAUTH_LEAVING" - IE it is choosing to leave this BSS for some other

20:12 <DannyB> so it's extra weird

20:13 <DannyB> because i doubt there are local patches tof edora that affect this

20:15 <DannyB> the exact sequence of events post-patches is:

20:15 <DannyB> driver auth and report success

20:15 <DannyB> supplicant tells driver to auth

20:15 <DannyB> Supplicant reports connect success

20:15 <DannyB> ...

20:15 <DannyB> Supplicant asks us to change station

20:15 <DannyB> Supplicant asks us to deauth and disconnect

20:16 <DannyB> I can't see anything wrong in the driver logs - we are setting the key right, we are authing and reporting success, etc

20:22 <janneg> yeah, nothing obvious in https://src.fedoraproject.org/rpms/wpa_supplicant/tree/rawhide

21:04 <chadmed> mps: we try not to pull in updates that are unreleased unless absolutely necessary since its just bm to package and distribute unreleased software

21:05 <chadmed> new tags for the kernel, mesa and friends that are earmarked for release get staged locally and i test them before pushing to the remote

21:12 <mps> chadmed: I do similarly for alpine, so I understand you

21:13 <mps> I test all tags locally first and if I don't see anything problematic I then push