Re: Bug#1091799: installation-reports: Qualcomm Atheros AR9485 detected, wifi networks seen but no network connection
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 <jscott@posteo.net>
magnus@debian3:~$
firmware-free: Recommend or Suggest firmware-ath9k-htc
Reported by: John Scott <jscott@posteo.net>
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'
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:
We are living both in Italy.
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
root@debian2:~# iw reg get
global
country 00: DFS-UNSET
(755 - 928 @ 2), (N/A, 20), (N/A), PASSIVE-SCAN
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW,
PASSIVE-SCAN
(5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)
phy#0
country 99: DFS-UNSET
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(2457 - 2482 @ 40), (N/A, 20), (N/A), PASSIVE-SCAN
(2474 - 2494 @ 40), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5140 - 5360 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
(5460 - 5860 @ 80), (N/A, 30), (N/A), PASSIVE-SCAN
root@debian2:~#
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.
Ok, thank you!
Also from your email address I guess you might already be familiar with
Jabber/XMPP (info at
Well, I have never used Jabber/XMPP but if you thing that the
debugging is easier I'm willing to try it to help you!
[>] 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:me@johnscott.me and in the meantime
I'll also be doing more research on your card in particular.
Thank you very much!
Kind regards, Magnus
Reply to: