Início / unix / Perguntas / 437492
Accepted
chefarov
Asked: 2018-04-14 01:38:11 +0800 CST

Problema peculiar de "desconexão" com ALFA AWUS036NHA (atheros 9271L)

  • 772

Estou usando: Debian Sid (kernel 4.15.0-2-amd64), e consigo conectar perfeitamente na minha rede wi-fi usando meu onboard Intel 7265e iwlwifimesmo com sinal fraco (ex: -80dBm).

No entanto, recentemente obtive ALFA AWUS036NHA (Atheros 9271), e em momentos aleatórios não consigo pingar meu roteador, apesar de ter boa qualidade de sinal (-68dBm). Eu tentei o firmware-atherospacote debian e a alternativa de código aberto , tendo o mesmo resultado descrito abaixo:

Normalmente minha tabela de roteamento se parece com:

:~$ 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

Em momentos aleatórios, a tabela de roteamento torna-se

:~$ 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

nesse caso, o ping do gateway (192.168.1.1) e qualquer outro IP (por exemplo, 8.8.8.8) trava indefinidamente . No entanto , o arp funciona neste caso, mostrando o restante dos dispositivos conectados, e a luz da antena está piscando conforme o esperado.

A diferença está na coluna Gateway ( _gatewayvs speedport-entry). Não consigo observar nenhuma outra peculiaridade quando isso acontece. Ele mantém o IP, máscara de rede, etc:

$ 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

SOLUÇÃO :

A solução é 1) desconectar e reconectar, usando o Wicd (já que a rede selecionada do gerenciador de rede do gnome carrega indefinidamente) ou 2) aguardar (1 a 5 minutos) e ela será corrigida automaticamente.

Algumas informações:

$ 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

Não consigo localizar nenhuma informação útil durante os incidentes, apenas registros anteriores/antigos:

:~$ 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

Os únicos erros relevantes que encontrei (últimas três linhas) ~ novamente esses logs são anteriores e não se repetem nas "desconexões" que examinei.

:~$ 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

Alguma idéia de como eu poderia depurar isso ainda mais?

networking debian

1 respostas

  1. Best Answer

    Eu tive os mesmos problemas com este adaptador e depois de depurar os drivers por um longo tempo, não encontrei o problema. Então notei que os mesmos problemas também existem no Windows, que foram instalados na mesma máquina (com inicialização dupla). Isso tornaria os problemas de driver uma coincidência e tanto, então comecei a suspeitar que o problema é com o hardware deste adaptador WiFi ou com a porta USB que o serve. Portanto, devolvi o antigo e reordenei um novo ALFA AWUS036NHAadaptador WiFi e instalei uma nova placa PCIe com um par de novas portas USB.

    Para minha surpresa, os problemas persistiram em AMBOS os sistemas operacionais!

    Lembrando que a luz indicadora de LED deste adaptador WiFi às vezes congela (principalmente no estado OFF), comecei a suspeitar que o MCU dentro deste adaptador WiFi travou ou reinicializou devido a alguns problemas de fonte de alimentação, então conectei um inline USB power monitorno Mini- B USB do adaptador WiFi, configurei-o MAX Hold displaye descobri que este adaptador consome mais corrente do que o máximo permitido pelo padrão USB (que é 500mA) consumindo intermitentemente até 830mA nas configurações de estoque (e até 910mA com o aumento Corte de energia TX ).

    Depois de construir meu próprio cabo USB de 3 metros de comprimento a partir de um cabo de par trançado blindado de impedância de 90Ω (S/STP com condutores 16AWG) com um conector USB Mini-B em uma extremidade deste cabo e dois conectores USB tipo A paralelos na outra extremidade deste cabo para extrair a corrente de alimentação de 2 soquetes USB host ao mesmo tempo (mas os dados formam apenas um soquete USB!), todos os problemas de desconexão aleatória, travamentos e problemas de travamento desapareceram.

    • 1

relate perguntas