[email protected] wrote: > Hi Debian Linux kernel maintainers, Hello! Thanks for the poke. I'm a newcomer to helping with the kernel but know this particular family of devices well, so I'll do my best to help. I apologize that your very detailed report has been stagnant for a while.
> As the problem described in this bug is present not only in the installer but > also in the installed system (one time it worked) I'm asking you for help to > debug it: according to Cyril it's "most likely a problem with the Linux > kernel modules and/or firmware" > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091799#10 > > I believe that the Linux kernel module is this one: > https://wiki.debian.org/ath9k You're correct. In your initial report, some of this automatically-included hardware information has what we need to know: > 02:00.0 Network controller [0280]: Qualcomm Atheros AR9485 Wireless Network > Adapter [168c:0032] (rev 01) > Subsystem: Lite-On Communications Inc AR9485 Wireless Network Adapter > [11ad:6627] > Kernel driver in use: ath9k > Kernel modules: ath9k > According to the firmware-summary attached to my installation report I > suppose that the firmware package is the following: firmware-atheros That shouldn't be needed. firmware-atheros is the package with non-free firmware for some of Qualcomm Atheros's other products, but non-USB devices in the ath9k family don't require any firmware at all. As you've figured out when using your AR9271, the USB version does require extra firmware, but it's libre and it sounds like that's working okay. > > Using the 12.8.0 Netinst I tried to install on 2024-12-05 experiencing > the problem described in the Subject, with the two different mobile > phones. You can find the syslog of the installation attached to the > bug log. Here are some lines I find interesting: > Dec 5 08:39:41 kernel: [ 58.988490] ath9k 0000:02:00.0 wlp2s0: renamed > from wlan0 ath9k is the non-USB driver, so this means that in all lines that follow, the name "wlp2s0" refers to that internal card (not the USB one). Then: > Dec 5 08:40:17 netcfg[4247]: INFO: Activating interface wlp2s0 > Dec 5 08:40:18 netcfg[4247]: INFO: Scan of wireless interface wlp2s0 > succeeded. > Dec 5 08:40:23 kernel: [ 100.645660] wlp2s0: authenticate with > 8e:b5:68:52:60:5f > Dec 5 08:40:23 kernel: [ 100.645710] wlp2s0: 80 MHz not supported, > disabling VHT > Dec 5 08:40:23 netcfg[4247]: INFO: Taking down interface wlp2s0 > Dec 5 08:40:23 kernel: [ 100.664025] wlp2s0: send auth to 8e:b5:68:52:60:5f > (try 1/3) > Dec 5 08:40:23 kernel: [ 100.664163] wlp2s0: aborting authentication with > 8e:b5:68:52:60:5f by local choice (Reason: 3=DEAUTH_LEAVING) > Dec 5 08:40:23 netcfg[4247]: INFO: Network chosen: moto e(7) plus 3650. > Proceeding to connect. and the lines that follow show it trying to connect to the access point, but failing to authenticate and timing out over and over again. After some time the following messages can be seen: > Dec 5 08:42:17 main-menu[312]: (process:4246): SIOCSIWMODE: Invalid argument > Dec 5 08:42:17 main-menu[312]: (process:4246): Successfully initialized > wpa_supplicant The SIOCSIWMODE ioctl() is used to set what kind of wireless user you want to be: a client ("station"), an access point, a passive eavesdropper ("monitor"), or whatever else. wpa_supplicant should be using this command to affirm that you'd like to be an ordinary client; it strikes me as odd that this would fail here. The second line is more interesting: this is the first time it appears, even though you've been attempting authentication for almost two minutes by the time that appears. That seems weird. There's nothing blatantly wrong here but we do see it set the regulatory domain as follows: > Dec 5 08:39:41 kernel: [ 58.940089] ath: EEPROM regdomain: 0x60 > Dec 5 08:39:41 kernel: [ 58.940090] ath: EEPROM indicates we should expect > a direct regpair map > Dec 5 08:39:41 kernel: [ 58.940092] ath: Country alpha2 being used: 00 > Dec 5 08:39:41 kernel: [ 58.940093] ath: Regpair used: 0x60 The details are fuzzy, but I think seeing on the linux-wireless mailing list that there was some kind of issue with ath9k handling the '00' country code differently from how it used to. Also, I believe the 0x60 regpair maps to this same "world" regulatory domain concept. It is a long-standing issue that, unfortunately, the majority of GNU/Linux wireless devices don't have their regulatory domain correctly set to indicate where the user is actually located. There is no interface for a user to conveniently do this to my knowledge, nor is it a thing most users are aware they need to do. There's an open issue in Network Manager to consider if they want to pick up that job, and I hope to see that happen in the future. In the meantime, this needs to be addressed. (Newer versions of the Debian Installer *might* handle this, but I'd have to look into it, and that's only a crutch for the problem at large.) Possibly-old wiki documentation suggests the "world regpair" was specially interpreted as meaning "United States" by these Atheros drivers. If I may ask, in what country is your friend using this computer? Setting the regulatory domain appropriately might help, and my hunch is informed by this: > Months later instead the wifi network did successful connect, with an access > point of an Internet café and both mobile phones. Perhaps merely being near the café enticed any of these devices to pick different wireless channels than they normally would. This would explain why a change in location helped even if you were just intent on connecting to the same cell phones. So, in addition to letting me know what country the computer is being used (or planned to be used) in, could you run this command in a terminal and let us know what it says: sudo iw reg get If the system doesn't use sudo but has a root password instead, run the 'su' command first to get superuser privilege and run the same without the 'sudo' in front. If the output suggests the regulatory domain is still nonsense, we can try to address that. I'll provide directions on how to set it right. Also from your email address I guess you might already be familiar with Jabber/XMPP (info at https://www.autistici.org/docs/jabber/ about it). If it'd make troubleshooting this easier, we can try to work this out in real-time if you'd like. I can be reached at xmpp:[email protected] and in the meantime I'll also be doing more research on your card in particular. Thank you.
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
