主页 / unix / 问题 / 437492
Accepted
chefarov
Asked: 2018-04-14 01:38:11 +0800 CST

ALFA AWUS036NHA (atheros 9271L) 的特殊“断开连接”问题

  • 772

我正在使用：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在这种情况下工作，显示其余连接的设备，并且天线灯按预期闪烁。

区别在于网关列( _gatewayvs speedport-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

任何想法我该如何进一步调试？

networking debian

1 个回答

  1. Best Answer

    我用这个适配器也遇到过同样的问题，调试驱动程序很长时间后，我没有发现问题。然后我注意到在安装在同一台机器上（双启动）的 Windows 下也存在同样的问题。这会使驱动程序问题纯属巧合，所以我开始怀疑，问题出在这个 WiFi 适配器的硬件或为其提供服务的 USB 端口上。因此，我退回了旧的并重新订购了新的ALFA AWUS036NHAWiFi 适配器，并安装了带有一对新 USB 端口的新 PCIe 卡。

    令我惊讶的是，两个操作系统上都存在问题！

    记得，这个 WiFi 适配器的 LED 指示灯有时会冻结（大部分处于关闭状态），我开始怀疑这个 WiFi 适配器内部的 MCU 由于某些电源问题而挂起或重置，所以我将一个inline USB power monitor插入 Mini- B WiFi 适配器的 USB 插座，将其设置为MAX Hold display并发现，该适配器通过在库存设置上间歇性地抽取高达 830mA 的电流（随着增加的情况下高达 910mA）消耗的电流超过了 USB 标准允许的最大值（即 500mA） TX电源黑客）。

    在用 90Ω 阻抗屏蔽双绞线电缆（S/STP 和 16AWG 导体）构建我自己的 3 米长 USB 电缆后，该电缆一端有一个 USB Mini-B 插孔，另一端有两个平行的 USB Type-A 插孔使用此电缆同时从 2 个主机 USB 插座获取电源电流（但数据仅来自一个 USB 插座！），所有随机断开问题、挂起和锁定问题都消失了。

    • 1

相关问题