ALFA AWUS036NHA (atheros 9271L) 的特殊“斷開連接”問題
我正在使用：
Debian Sid (kernel 4.15.0-2-amd64)，我可以使用我的板載設備完美地連接到我的 wifi 網路Intel 7265，iwlwifi即使信號很弱（例如 -80dBm）。但是，我最近得到了
ALFA AWUS036NHA (Atheros 9271)，儘管信號質量很好（-68dBm），但我還是無法 ping 通我的路由器。我已經嘗試了firmware-atherosdebian 包和開源替代方案，結果與下面描述的相同：通常我的路由表如下所示：
:~$ sudo route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default speedport-entry 0.0.0.0 UG 0 0 0 wlan1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1 192.168.71.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8 192.168.154.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1在隨機時刻，路由表變為
:~$ sudo route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default _gateway 0.0.0.0 UG 0 0 0 wlan1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1 192.168.71.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8 192.168.154.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1在這種情況下，ping 網關（192.168.1.1）和任何其他 IP（例如 8.8.8.8）會無限期掛起。然而， arp在這種情況下工作，顯示其餘連接的設備，並且天線燈按預期閃爍。
區別在於網關列(
_gatewayvsspeedport-entry)。當它發生時，我無法觀察到任何其他特殊性。它保留 IP、網路遮罩等：$ ifconfig wlan1 wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.68 netmask 255.255.255.0 broadcast 192.168.1.255 ether 00:c0:ca:97:32:3e txqueuelen 1000 (Ethernet) RX packets 4102532 bytes 3990894721 (3.7 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3198872 bytes 1012818336 (965.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0解決方案：
解決方案是 1）斷開連接並重新連接，使用 Wicd（因為 gnome 網路管理器的Select Network無限載入），或 2）等待（1-5 分鐘），它會自動修復。
一些資訊：
$ lsmod | grep ath9k ath9k_htc 81920 0 ath9k_common 20480 1 ath9k_htc ath9k_hw 487424 2 ath9k_htc,ath9k_common ath 32768 3 ath9k_htc,ath9k_hw,ath9k_common mac80211 798720 2 iwlmvm,ath9k_htc cfg80211 720896 6 iwlmvm,ath9k_htc,iwlwifi,mac80211,ath,ath9k_common usbcore 290816 11 ath9k_htc,usbhid,snd_usb_audio,usb_storage,ehci_hcd,xhci_pci,snd_usbmidi_lib,btusb,uas,xhci_hcd,ehci_pci $ sudo lshw -c network *-network description: Ethernet interface product: Ethernet Connection (3) I218-LM vendor: Intel Corporation physical id: 19 bus info: pci@0000:00:19.0 logical name: eth0 version: 03 serial: f8:ca:b8:37:ec:75 capacity: 1Gbit/s width: 32 bits clock: 33MHz capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k firmware=0.2-3 latency=0 link=no multicast=yes port=twisted pair resources: irq:52 memory:f7200000-f721ffff memory:f7243000-f7243fff ioport:f080(size=32) *-network description: Wireless interface product: Wireless 7265 vendor: Intel Corporation physical id: 0 bus info: pci@0000:02:00.0 logical name: wlan0 version: 59 serial: 18:5e:0f:9f:2c:61 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless configuration: broadcast=yes driver=iwlwifi driverversion=4.15.0-2-amd64 firmware=29.541020.0 latency=0 link=no multicast=yes wireless=IEEE 802.11 resources: irq:49 memory:f7000000-f7001fff *-network description: Wireless interface physical id: 2 bus info: usb@1:1 logical name: wlan1 serial: 00:c0:ca:97:32:3e capabilities: ethernet physical wireless configuration: broadcast=yes driver=ath9k_htc driverversion=4.15.0-2-amd64 firmware=1.4 ip=192.168.1.68 link=yes multicast=yes wireless=IEEE 802.11在事件期間我找不到任何有用的資訊，只有以前/較舊的日誌：
:~$ sudo dmesg -T | grep -i ath9k [Thu Apr 12 20:57:43 2018] usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested [Thu Apr 12 20:57:43 2018] usbcore: registered new interface driver ath9k_htc [Thu Apr 12 20:57:43 2018] usb 1-1: firmware: failed to load ath9k_htc/htc_9271-1.4.0.fw (-2) [Thu Apr 12 20:57:43 2018] usb 1-1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2 [Thu Apr 12 20:57:43 2018] usb 1-1: ath9k_htc: Firmware htc_9271.fw requested [Thu Apr 12 20:57:44 2018] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008 [Thu Apr 12 20:57:44 2018] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits [Thu Apr 12 20:57:44 2018] ath9k_htc 1-1:1.0: ath9k_htc: FW Version: 1.4 [Thu Apr 12 20:57:44 2018] ath9k_htc 1-1:1.0: FW RMW support: On [Fri Apr 13 00:38:49 2018] usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51008 [Fri Apr 13 00:38:49 2018] ath9k_htc 1-1:1.0: ath9k_htc: HTC initialized with 33 credits我發現的唯一相關錯誤（最後三行）~這些日誌是以前的，而不是在我調查過的“斷開連接”處重複。
:~$ sudo dmesg -T | grep -i error [Thu Apr 12 20:57:38 2018] Error parsing PCC subspaces from PCCT [Thu Apr 12 20:57:39 2018] i801_smbus: probe of 0000:00:1f.3 failed with error -16 [Thu Apr 12 20:57:42 2018] EXT4-fs (sdb3): re-mounted. Opts: errors=remount-ro [Thu Apr 12 20:57:42 2018] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [Thu Apr 12 20:57:43 2018] usb 1-1: Direct firmware load for ath9k_htc/htc_9271-1.4.0.fw failed with error -2 [Fri Apr 13 00:38:48 2018] usb 1-1: device descriptor read/64, error -110任何想法我該如何進一步調試？
我用這個適配器也遇到過同樣的問題，調試驅動程序很長時間後，我沒有發現問題。然後我注意到在安裝在同一台機器上（雙啟動）的 Windows 下也存在同樣的問題。這會使驅動程序問題純屬巧合，因此我開始懷疑，問題出在此 WiFi 適配器的硬體或為其提供服務的 USB 埠上。因此，我退回了舊的並重新訂購了新的
ALFA AWUS036NHAWiFi 適配器，並安裝了帶有一對新 USB 埠的新 PCIe 卡。令我驚訝的是，兩個作業系統上都存在問題！
記得，這個 WiFi 適配器的 LED 指示燈有時會凍結（大多處於關閉狀態），我開始懷疑這個 WiFi 適配器內部的 MCU 由於某些電源問題而掛起或重置，所以我將一個
inline USB power monitor插入 Mini- B WiFi 適配器的 USB 插座，將其設置為MAX Hold display並發現，該適配器通過在庫存設置上間歇性地吸收高達 830mA 的電流（隨著增加的電流高達 910mA TX電源黑客）。在用 90Ω 阻抗屏蔽雙絞線電纜（S/STP 與 16AWG 導體）建構我自己的 3 米長 USB 電纜後，該電纜的一端有一個 USB Mini-B 插孔，另一端有兩個平行的 USB Type-A 插孔使用此電纜同時從 2 個主機 USB 插座獲取電源電流（但數據僅來自一個 USB 插座！），所有隨機斷開問題、掛起和鎖定問題都消失了。