总结：经过一周的调查，我认为要么是 ath9k_htc 固件损坏了，要么是 0cf3:9271 设备中的大部分存在错误。我的下一个计划是购买或挑选一个可以避免使用该固件的其他 wifi 适配器。我对 ath9k_htc 驱动程序的检查表明，所有 Atheros 9271 芯片都使用此固件。
在我将系统从 Ubuntu 18.04 LTS 更新到 Ubuntu 20.04 LTS 后，我的 USB wifi 适配器在使用一段时间后断开了连接。我可以通过拔下适配器并重新插入来暂时解决问题，但我想修复根本问题，以便设备完全停止这样做。但是，我不知道从哪里开始寻找。
lsb_release -a：
LSB Version: core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
我启用了 ath9k_htc 驱动程序的调试日志。除了更改配置之外，我还从与 Ubuntu 存储库中的 Linux 内核 debian 包相同的源构建了内核，这些源是我通过apt-get source linux-modules-extra-5.4.0-70-generic
uname -a：
Linux herpcomp 5.4.94afw #1 SMP Sat Apr 10 21:27:47 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux
以下是《跑步》的摘录链接journalctl-https://paste.ubuntu.com/p/kmV4MYKDYB/。我想我抓住了设备行为异常的时刻，因为我看到有一行日志说：
4 月 11 日 16:59:14 herpcomp 内核：wlx00c0ca82d3fc：从 04:d9:f5:b1:f8:30 取消身份验证（原因：15=4WAY_HANDSHAKE_TIMEOUT）
这里还有一组日志，具体显示了我的适配器开始出现异常时 NetworkManager 和 wpa_supplicant 的情况：https://paste.ubuntu.com/p/gW7s5rsMhC/. 这是用 检索到的journalctl -S "2021-04-11 16:55:00" -U "2021-04-11 17:10:00" -u NetworkManager -u wpa_supplicant。
这是 /etc/NetworkManager.d/conf.d/default-wifi-powersave-on.conf 的内容：
$ cat default-wifi-powersave-on.conf
[connection]
wifi.powersave = 2
sudo iw reg get显示：
global
country US: DFS-FCC
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#0
country GB: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 20), (0 ms), DFS
(57000 - 71000 @ 2160), (N/A, 40), (N/A)
由于我住在美国，我认为该global选项设置正确。但我不确定为什么phy#0设置为 GB，也不知道如何更改它。
关于我应该在哪里找到问题，您有什么想法吗？我的下一个猜测是搜索与 wpa_supplicant 相关的日志和配置，并对实际执行的操作进行一些研究iw reg get/set。我会在解决这个问题时留下更新。
编辑1：我添加了一个指向我从运行中获得的一些日志的链接journalctl -S "2021-04-11 16:55:00" -U "2021-04-11 17:10:00" -u NetworkManager -u wpa_supplicant。时间间隔包含我的无线适配器行为异常的时刻。日志粘贴在https://paste.ubuntu.com/p/gW7s5rsMhC/。
有趣的是，我从读取内核、NetworkManager 和 wpa_supplicant 日志中发现了以下日志序列：
Apr 11 16:59:05 herpcomp kernel: ath: phy1: AWAKE -> FULL-SLEEP
Apr 11 16:59:05 herpcomp kernel: ath: phy1: Set HW Key
Apr 11 16:59:05 herpcomp kernel: ath: phy1: FULL-SLEEP -> AWAKE
Apr 11 16:59:05 herpcomp kernel: ath: phy1: AWAKE -> FULL-SLEEP
Apr 11 16:59:05 herpcomp wpa_supplicant[1212]: wlx00c0ca82d3fc: CTRL-EVENT-DISCONNECTED bssid=04:d9:f5:b1:f8:30 reason=0
Apr 11 16:59:05 herpcomp NetworkManager[1174]: <info> [1618185545.3145] device (wlx00c0ca82d3fc): supplicant interface state: completed -> disconnected
Apr 11 16:59:05 herpcomp kernel: ath: phy1: FULL-SLEEP -> AWAKE
Apr 11 16:59:05 herpcomp kernel: ath: phy1: Set channel: 2452 MHz
当 ath9k_htc 驱动程序说设备正在从“AWAKE”变为“FULL-SLEEP”时，我不太确定这意味着什么，但这看起来非常可疑。
编辑2：我从 wpa_supplicant 收集了 2 组日志。第一个文件是我无法连接到路由器时的日志：https://paste.ubuntu.com/p/5VBk27GXTZ/
第二个日志文件是我成功连接到路由器时生成的：https://paste.ubuntu.com/p/4YT8FtR3zg/
在第一个描述我的 wifi 卡无法连接到路由器的文件中，我发现四次握手中的消息 1 不断重复。路由器（我将其称为接入点，或 AP）会向我发送包含 AP 的 ANonce 的消息 1。然后，wpa_supplicant 会使用刚刚生成的 SNonce 回复。然后，AP 会再次使用相同的消息 1 回复，而不是四次握手中的消息 3。
在成功的情况下，这种情况根本不会发生。在这种情况下，4 次握手顺利进行。AP 向我发送了消息 1。wpa_supplicant 用消息 2 进行响应。AP 发回消息 3，wpa_supplicant 通过发回消息 4 完成握手。
我使用 wireshark 进一步确认了这种奇怪的行为。我发现当我无法连接到 AP 时，AP 只是不断发送相同的消息 1。然后，我比较了无法连接时的 4 次握手和可以连接的情况。我发现 AP 的消息 1 在这两种情况下没有差异。
我还比较了 wpa_supplicant 在失败和成功时的响应；除了 SNonce 和消息完整性检查的差异外，wpa_supplicant 的响应是相同的。
此时，我认为 AP 的行为不正确。我还没有完全解决问题，但至少缩小了可能出现问题的范围。
编辑3：我今晚发现了一个问题！我使用了diff从 wpa_supplicant 检索到的两组日志。一组日志记录了连接成功时的系统日志，另一组日志记录了连接失败时的系统日志。我发现从路由器收到的 ANonce 在两个位置有所不同：
第一条日志显示：
4a 47 9e 38 c5 1b fc e4 c1 b2 73 7d 9a 2d 8f 34 3c 68 80 b2 bb c0 b0 ed ce ec 5f 55 1a 4e 36 d6
第二条日志显示：
4a 47 9e 38 c5 1b fc e4 c1 b2 73 7d 9a 2d 8f 34 3c 68 80 b2 bb c0 b0 ed ce ec 5f 55 1a 4e 36 dA
这两个 nonce 几乎完全相同。唯一的区别在于最后 4 位（上面一对字符串中的最后一个十六进制数字）。
这可以解释我的路由器的行为。wpa_supplicant 使用与路由器不同的随机数来计算 MIC。
现在的问题变成了为什么最后第 4 位和倒数第 3 位不同。
当 wifi 连接失败时，我曾尝试将我的系统连接到手机的热点，我发现我的系统出现了与无法连接到路由器时相同的症状。由于我在使用手机而不是路由器时遇到了同样的问题，所以我怀疑路由器向我发送了错误的随机数。我假设我的系统上的某些东西正在错误地从路由器收集数据。
我的搜索可能又会从 ath9k_htc 驱动程序的某个地方开始。我怀疑 wpa_supplicant 的 nl80211 驱动程序是否出了问题；否则我预计会在许多用户的系统中看到这个问题，这可能已经引起了 wpa_supplicant 维护者的注意。
编辑4：我仔细查看了 nonce。我发现每次 wpa_supplicant 未能完成 4 次握手时，下一次尝试都会包含一个比前一个 nonce 大 1 个整数的 nonce。例如，如果我查看 nonce 的最后 2 个字节，我会在每次握手尝试中看到以下内容：
db 07
db 08
db 09
db 0a
db 0b
db 0c
db 0d
db 0e
有东西在增加 nonce。我想知道重放计数器是否与此有关，因为该计数器在每次握手尝试时都会增加。也许重放计数器的内存位置与密钥重叠？
编辑5：经过长达一周的漫长调查，我发现驱动程序没有出现问题。内核中的网络堆栈没有出现问题。wpa_supplicant 没有出现问题。似乎只是低级错误。我还记得我遇到过类似（可能相同）的问题，另一个 wifi 适配器的 USB 供应商和设备 ID 与我目前不稳定的适配器相同。我得出的结论是，要么是固件出了问题，要么是这些 0cf3:9271 芯片的大部分出了问题。
我想我只需要选择一张不同的 wifi 卡或一个不同的 wifi 适配器。