XPost: linux.debian.bugs.dist   
      
   Hi John,   
      
   When I received you email I recognized your name and   
   email address:   
      
   magnus@debian3:~$ apt-cache show firmware-ath9k-htc | grep 'Maintainer:'   
   Maintainer: John Scott    
   magnus@debian3:~$   
      
   firmware-free: Recommend or Suggest firmware-ath9k-htc   
   Reported by: John Scott    
   Date: Sun, 27 May 2018 03:42:02 UTC   
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900171   
      
   Great!   
      
      
   On 2025-10-13 00:39, John Scott wrote:   
   > magnus@autistici.org 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.   
      
   Thank you very much! Well, I did not write earlier to d-kernel   
   as I couldn't help with debugging without the notebook which   
   was at my friend's home.   
      
      
   >> 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.   
      
   Yes, my AR9271 works like a charm, with the libre firmware build   
   from source and the Debian package maintained by you. Thank you!   
      
      
   >> 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.   
      
   The "moto e(7) plus 3650" is the mobile phone of my friend.   
      
      
   > 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'   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)