ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
Dementor has quit [Ping timeout: 480 seconds]
balrog has quit [Quit: Bye]
balrog has joined #asahi-alt
Dementor has joined #asahi-alt
kidplayer666 has quit [Quit: Connection closed for inactivity]
jeisom has quit [Ping timeout: 480 seconds]
maria has quit [Ping timeout: 480 seconds]
maria has joined #asahi-alt
<stintel> soooo upgraded from asahi-6.5-27 to asahi-6.6-3 and I'm also seeing that Wi-Fi disconnect bug every 1 minute ... using iwd
<stintel> DannyB: fyi ^
<stintel> if needed I can provide more debug info tomorrow
<stintel> but it does not appear to be a wpa_supplicant only problem
john-cabaj has quit [Ping timeout: 480 seconds]
kidplayer666 has joined #asahi-alt
veebop has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-alt
<janneg> I don't see any wifi disconnects with asahi-6.6-3 with fedora wpa_supplicant / bcm4387 / wpa3 personal
veloek has joined #asahi-alt
<yuka> I have said this before, but I will repeat it: on my machine it happens depending on the wifi network/vendor. my home wifi has the issue, but my android hotspot works fine.
veebop has joined #asahi-alt
<stintel> so my wild guess goes to 802.11r
<stintel> hostapd_cli shows AKMSuiteSelector=00-0f-ac-4
<stintel> on 6.5 hostapd_cli shows AKMSuiteSelector=00-0f-ac-9 (FT-SAE)
<stintel> so for some reason it downgrades from WPA3 + FT to WPA2 + FT and that seems broken
<stintel> yuka: I suspect you will have 802.11r enabled in your unifi, you could try disabling it to confirm that's the culprit
<stintel> I don't immediately find how to convince NetworkManager or iwd to not use it
<yuka> I currently don't have a unifi controller running 😬
<yuka> someone else might be faster
<stintel> I'll boot my test AP and play around there
<stintel> but first coffee
<yuka> enjoy
jnn has joined #asahi-alt
jn has quit [Ping timeout: 480 seconds]
Manouchehri_ has quit [Read error: Connection reset by peer]
Manouchehri_ has joined #asahi-alt
kidplayer666 has quit [Read error: Connection reset by peer]
kidplayer666 has joined #asahi-alt
jeisom has joined #asahi-alt
<stintel> ok, it appears to be rather complicated. I can't seem to reproduce it on my test AP, but this is a single BSSID, no roaming candidates
<stintel> some interesting findings though ... on 6.6-3, SAE does not work at all
chadmed has quit [Remote host closed the connection]
<stintel> yuka: do you have multiple APs ?
<stintel> or maybe 2.4 and 5 GHz using same SSID
<yuka> both
<yuka> two APs, and both broadcasting the same SSID on 2.4 and 5GHZ
<stintel> thanks
kidplayer666 has quit [Quit: Connection closed for inactivity]
chadmed has joined #asahi-alt
<DannyB> I can connect to a 2.4ghz, 5hgz, and 6ghz wpa-3 only point, a wpa-2/wpa-3 mixed point, and a wpa-2 only point.
<DannyB> In all of these logs the supplicant is the thing requesting the disconnect, which is weird
<DannyB> i would try reverting the following patches from asahi-wip
<DannyB> and testing
<stintel> yeah, as I said, it's complicated
<DannyB> a349ce53cd28d51059ccda826ba133af52995982
<DannyB> 4c411956766690f31c5b65d8fe24235d311b8595
<stintel> interesting though that you can connect to wpa-3 only (I assume that's WPA3-PSK), it does not work at all for me, using NM + iwd. this works fine on 6.5
<DannyB> and maybe 38b690940fe07348f64bd8507b8a32d01a5edbae
<stintel> now I'm still trying to reproduce it on my test setup
<DannyB> It's WPA3-Personal (IE SAE and not PSK)
<DannyB> driver identifies as using SAE offload, daemon shows point as WPA3-SAE
<stintel> what chip? BCM4387/7 here according to dmesg
<DannyB> 4388/4
<DannyB> Interestingly the code paths aren't different for these chips
<DannyB> and never have been
<DannyB> I can believe fast roaming is broken somehow, if so, reverting a349c should fix it
<stintel> yeah the problem is I can't repro it on my test setup with 2 BSSIDs now using the same SSID, and when I connect to my main network it's instantly broken again
<stintel> looking again at the differences
<DannyB> When using hardware roam a349ce depends on the station reporting the right caps to determine if the port is authorized
<DannyB> The weird thing is that in all cases this is connecting, and then the supplicant decides to disconnect. It would be good to try to get enough supplicant debugging to see why it tries to disconnect
<DannyB> it may be the driver is telling it something weird in one case but not the other
<DannyB> but if so, it's not obvious from the logs we have
<DannyB> IE the auth and connect is suceeding, it reports success to supplicant, and then the supplicant says "okay please deauth and disconnect"
<DannyB> and we do
<DannyB> but it's not obvious at all why
<DannyB> I have tried this on 4 different brands of wifi networks, with fast roaming enabled/disabled, neighbor reporting, you name it
<DannyB> and can't get my wifi to disconnect the same way ;(
<stintel> yeah, I've tried many combinations in hostapd.conf (using openwrt here), until now I cannot repro it on my test network
<DannyB> so either the caps are wrong (which is one of the patches above), or the supplicant gets a weird result from the driver it's not telling us about
<DannyB> can you generate logs with iwd -d the next time you can reproduce?
<stintel> but I've not yet tried bss_transition=1, mbo=1, probably few more
<stintel> I can do that easily, hold on
<DannyB> t
<DannyB> apple also has newer firmware for all of these chips than we are shipping
<DannyB> that i can give you to try
<DannyB> (they actually went backwards in firmware versions - they are now shipping an older branch than they were before, so maybe they found this bug?)
<stintel> oh I wouldn't be surprised, broadcom wifi firmware is a disaster ime
<stintel> I was actually pleasantly surprised it worked so well until now
<j`ey> DannyB: huh, we're shipping the fw that comes with macOS though?
<j`ey> oh right, 14.x or whatever could have a new version
<stintel> DannyB: so it appears related to SAE not working here. it tries to upgrade from WPA2-PSK to SAE, which fails and that results in a disconnect
<stintel> let me get you some logs
<stintel> hmm that was probably not the right conclusion
<stintel> fyi I pm'd you a link to the logs, I was too lazy to censor PII
<stintel> ok, it's not apparantly visible in the logs to me, it says "Network is WPA3-Personal", then tries to connect to it, it connects fine, but both `iwctl station wlan0 show` and `hostap_cli sta 74:a6:cd:xx:xx:xx` show that it is using WPA2-Personal + FT (00-0f-ac-4)
<stintel> nov 29 15:42:13 marvin iwd[13096]: src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
<stintel> iiuc this means it got the disconnect event from the kernel?
<stintel> so the driver (probably the firmware)
kidplayer666 has joined #asahi-alt
<stintel> setting roamoff=1 modparm doesn't fix it
<stintel> building with a349ce53cd28d51059ccda826ba133af52995982 reverted now
<stintel> now it doesn't connect at all
john-cabaj has joined #asahi-alt
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-alt
kidplayer666 has quit [Quit: Connection closed for inactivity]
<DannyB> ha
<DannyB> So this log helps, or at least gives issues to run down
<DannyB> that i cna write patches for and see what happens
<DannyB> I also note the exact sequence in the log seems to be special cased in a weird way in iwd
<DannyB> for brcmfmac
<DannyB> */
<DannyB> "/*
<DannyB> * Save the information about the frame's ACK status
<DannyB> * called before it (happens on brcmfmac).
<DannyB> * to be processed in frame_xchg_tx_cb if we were
<DannyB> "
c4sp3r has joined #asahi-alt
<DannyB> stintel: no, the disconnect event you see there is locally generated
<DannyB> see the remaining part
<DannyB> Received Deauthentication event, reason: 3, from_ap: false
<DannyB> Reverting a349ce breaking things is weird
<DannyB> the other weird thing is that the disconnect is exactly 60 seconds after connect
c4sp3r has quit [Ping timeout: 480 seconds]
<yuka> I also tried checking out the entire brcmfmac driver directory from 6.5-29, while having the rest from 6.6-3
<yuka> that also resulted in not being able to connect at all
<DannyB> we changed nothing int the base net wireles code
<DannyB> so that shoul definitely work
<j`ey> yeah but 6.6 might have..
<DannyB> Let's disable softmac and see if it works
<DannyB> in cfg80211.c, delete the block on line 8050 that is
<DannyB> if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_SAE)) {
<DannyB> wiphy->features |= NL80211_FEATURE_SAE;
<DannyB> }
<DannyB> (don't touch the ones that talk about SAE_OFFLOAD above it)
<DannyB> see if that fixes it
<DannyB> that will tell the supplicants to supoprt full SAE offload only, which is what it was in 6.5
<DannyB> if that doesn't work there is only like one more thing i can think of driver related
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-alt
kidplayer666 has joined #asahi-alt
c4sp3r has joined #asahi-alt
c4sp3r has quit [Ping timeout: 480 seconds]
dylanchapell has quit [Read error: Connection reset by peer]
<DannyB> yuka: Try the above and see if it solves your issue, if not i have one more patch for you
<DannyB> stintel: same for you :)
<DannyB> If y'all are tired of dealing with it or found a solution, that's great too!
dylanchapell has joined #asahi-alt
SalimTerryLi has joined #asahi-alt
SalimTer- has quit [Ping timeout: 480 seconds]
kraem has quit [Remote host closed the connection]
kraem has joined #asahi-alt
<stintel> DannyB: sorry, got distracted with paid work ;)
<stintel> before that, I disable NM and used plain wpa_supplicant with a config file, took my old laptop and put the wifi in monitor mode, with wpa_supplicant configured to use SAE, I didn't even see assoc/auth request, I did see probe request and response
<stintel> let me try what you suggested
<stintel> if needed I can do more debugging on Friday, with a test setup that better mimics my main setup (2 APs rather than 1)
<stintel> DannyB: that worked
<stintel> hmm. so it now connects to an SAE-only network, but it's still disconnecting every minute :/
<DannyB> lol
<DannyB> no worries on time
<DannyB> happy to do whatever
<DannyB> I may start with a patch that reverts every commit not related to just getting basics working
<DannyB> and see if it works
<DannyB> because if it doesn't, the problem is more basic
<DannyB> (IE give you a patch that reverts 6g support, etc)
<stintel> I was actually looking at git log for drivers/net/wireless/broadcom/brcm80211/brcmfmac/ and started reverting the commits one by one
<stintel> poor man's git bisect
<stintel> but yeah I need to continue this on Friday probably, need to get up early tomorrow
iaguis has quit [Ping timeout: 480 seconds]
<stintel> fyi, firmware version is 01-126f2c4c here
<stintel> [ 3.203459] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4387/7 wl0: May 27 2023 01:34:59 version 20.96.31.0.8.7.148 FWID 01-126f2c4c
<stintel> that might be more complete