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)