No wireless signal on ath9k solved, but ...

English Network/Internet
#1

Hi guys!

I’m writing this post to help another people with this problem, but also to understand a little more with you guys, if possible.

After uptading to kernel 5.11.15 my wireless device stopped, but I changed to the previous kernel version on boot and ignored it. Today I made zypper dup and my functional kernel was removed, resulting in neither, 5.11.15 and 5.12.4, working with my wireless device.

My wireless device is a Atheros AR9485 as you can see on lspci:

1c:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)

The dmesg output with dmesg | grep -E ‘ath|cfg80’ showed:

    5.449501] cfg80211: Loading compiled-in X.509 certificates for regulatory database
    5.449692] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
    5.814081] ath9k 0000:1c:00.0: enabling device (0000 -> 0002)
    5.822335] ath: EEPROM regdomain: 0x21
    5.822338] ath: EEPROM indicates we should expect a direct regpair map
    5.822338] ath: Country alpha2 being used: BB
    5.822339] ath: Regpair used: 0x21
    6.066413] ath9k 0000:1c:00.0 wlp28s0: renamed from wlan0

Looking around I learned that could be a missing or wrong country code. I live in Brazil, so I create a file on /etc/modprobe.d/ath9k.conf:

softdep ath9k pre: cfg80211
options cfg80211 ieee80211_regdom=BR

Unload and reload the module:

modprobe -r ath9k
modprobe -v ath9k

After this the wireless is working again!

But this was a “luck guess”. How could I track this change from the last working kernel to my current kernel version?

#2

https://bbs.archlinux.org/viewtopic.php?id=124574

#3

Sorry, I read this post but didn’t find any useful information about how to track what changed from the last Tumbleweed dist-upgrade.

#4

You may have a look at:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/net/wireless/ath/ath9k?h=linux-5.12.y&qt=grep&q=ath9k
and:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/net/mac80211?h=linux-5.12.y&qt=grep&q=mac80211
I see two commits on 2021-05-14 that were included in kernel 5.12.4 (see https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.12.4 ) but I cannot tell if those might be related to your problem.
Having an AR9485 too but I saw no problems with the default “global” setting of ieee80211_regdomain (which is hard coded in the EEPROM of my card, so I cannot experiment, sorry).

#5

Have a look at the changelog for the wireless-regdb package, there were two changes in April, nothing relating to Brazil specifically but … who knows?

#6

Thanks OrsoBruno! I’ll look!

I’m confused because the message on dmesg stills the same:

    5.465871] cfg80211: Loading compiled-in X.509 certificates for regulatory database
    5.466024] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
    5.674322] ath9k 0000:1c:00.0: enabling device (0000 -> 0002)
    5.682437] ath: EEPROM regdomain: 0x21
    5.682439] ath: EEPROM indicates we should expect a direct regpair map
    5.682440] ath: Country alpha2 being used: BB
    5.682441] ath: Regpair used: 0x21
    6.072813] ath9k 0000:1c:00.0 wlp28s0: renamed from wlan0

But I’m looking for enlightenment, I’ll try to figure this out from the source, pretty obvious now that you appointed :stuck_out_tongue: but is something that I not used to do.
So, I’m far away from really understand Linux, this is why I came here lol!

#7

**Country alpha2 being used: BB **, that is “Barbados”?? Maybe you have to check that your config actually calls for “BR”?
**Regpair used: 0x21 **: maybe your card (like mine) follows what is in the EEPROM no-matter-what?
Adding to my previous post, there is a remark in the changelog for wireless-regdb that might be related to your problem:

| gio 26 nov 2020, 13:00:00
|
| dmueller@suse.com
| - Update to version 20201120:
  * wireless-regdb: update regulatory database based on preceding changes
  * wireless-regdb: Update regulatory rules for Kazakhstan (KZ)
  * wireless-regdb: update 5.8 GHz regulatory rule for GB
  * wireless-regdb: Update regulatory rules for Pakistan (PK) on 5GHz
  * wireless-regdb: Update regulatory rules for Croatia (HR)
  * **wireless-regdb: restore channel 12 & 13 limitation in the US**
  * wireless-regdb: update regulatory rules for Egypt (EG)

|

Channels 12 and 13 are apparently allowed in Brazil, so if your hot-spot uses one of those channels but your laptop card defaults to an “US” setting, that could explain why your laptop became “deaf” after that update.
(just my guess, I’m not really an expert in the field).

#8

Maybe we are barking up the wrong tree…
Apparently dmesg tells what is hardcoded in the card, limits you cannot override. In your case

    5.682441] ath: Regpair used: **0x21**

translates to

FCC2_WORLD = 0x21

(please see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/ath/regd_common.h?h=linux-5.12.y )
In my case that is slightly wider (0x60 translating to WOR0_WORLD) and I am apparently able to restrict use of some channels.
What I see on this system:

localhost:~ # dmesg |grep ath 
    5.369339] ath: phy0: Set parameters for CUS198 
    5.369344] ath: phy0: Set BT/WLAN RX diversity capability 
    5.375315] ath: phy0: Enable LNA combining 
    5.376479] ath: phy0: ASPM enabled: 0x42 
    5.376482] ath: EEPROM regdomain: 0x60 
    5.376482] ath: EEPROM indicates we should expect a direct regpair map 
    5.376484] ath: Country alpha2 being used: 00 
    5.376484] ath: Regpair used: 0x60 
localhost:~ #

and the channels enabled are:

localhost:~ # iw phy0 info 
Wiphy phy0
<snip>
        Frequencies: 
            * 2412 MHz [1] (17.0 dBm) 
            * 2417 MHz [2] (17.0 dBm) 
            * 2422 MHz [3] (17.0 dBm) 
            * 2427 MHz [4] (17.0 dBm) 
            * 2432 MHz [5] (17.0 dBm) 
            * 2437 MHz [6] (17.0 dBm) 
            * 2442 MHz [7] (17.0 dBm) 
            * 2447 MHz [8] (17.0 dBm) 
            * 2452 MHz [9] (17.0 dBm) 
            * 2457 MHz [10] (17.0 dBm) 
            * 2462 MHz [11] (17.0 dBm) 
            * 2467 MHz [12] (17.0 dBm) (no IR) 
            * 2472 MHz [13] (17.0 dBm) (no IR) 
            * 2484 MHz [14] (17.0 dBm) (no IR) 
<snip>
localhost:~ #

Setting the region to IT (BR should be similar afaik) I see that channel 14 is disabled:

localhost:~ # iw reg set IT 
localhost:~ # iw phy0 info 
Wiphy phy0
<snip>
        Frequencies: 
            * 2412 MHz [1] (17.0 dBm) 
            * 2417 MHz [2] (17.0 dBm) 
            * 2422 MHz [3] (17.0 dBm) 
            * 2427 MHz [4] (17.0 dBm) 
            * 2432 MHz [5] (17.0 dBm) 
            * 2437 MHz [6] (17.0 dBm) 
            * 2442 MHz [7] (17.0 dBm) 
            * 2447 MHz [8] (17.0 dBm) 
            * 2452 MHz [9] (17.0 dBm) 
            * 2457 MHz [10] (17.0 dBm) 
            * 2462 MHz [11] (17.0 dBm) 
            * 2467 MHz [12] (17.0 dBm) (no IR) 
            * 2472 MHz [13] (17.0 dBm) (no IR) 
            *** 2484 MHz [14] (disabled) **
<snip>
localhost:~ #

Setting the region to US (the most restrictive) I see that channels 12 and 13 are disabled too:

localhost:~ # iw reg set US
localhost:~ # iw phy0 info 
Wiphy phy0
<snip>
        Frequencies: 
            * 2412 MHz [1] (17.0 dBm) 
            * 2417 MHz [2] (17.0 dBm) 
            * 2422 MHz [3] (17.0 dBm) 
            * 2427 MHz [4] (17.0 dBm) 
            * 2432 MHz [5] (17.0 dBm) 
            * 2437 MHz [6] (17.0 dBm) 
            * 2442 MHz [7] (17.0 dBm) 
            * 2447 MHz [8] (17.0 dBm) 
            * 2452 MHz [9] (17.0 dBm) 
            * 2457 MHz [10] (17.0 dBm) 
            * 2462 MHz [11] (17.0 dBm) 
         **   * 2467 MHz [12] (disabled) 
            * 2472 MHz [13] (disabled) 
            * 2484 MHz [14] (disabled) **
<snip>
localhost:~ #

and there is no difference in a test Tumbleweed I have not updated for months, so at this point I cannot tell if we are pointing in the right direction to understand your original problem.