Wireless falha até que alguém faça arp -d 192.168.1.1

Question

Minha rede sem fio falha entre alguns minutos depois de ser conectada por meia hora ou mais.

Sintomas:

• novas páginas não abrem
• downloads já em andamento continuam
• ping 8.8.8.8 não funciona

A "correção" é fácil (dura um período de tempo aleatório):

$ sudo arp -d 192.168.1.1

Esta solução não faz sentido, pois verifiquei e não é veneno ARP.

Alguma idéia de por que isso acontece?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=53.4 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 53.425/54.358/55.282/0.923 ms

Roteador Wireless: ZonHub 1.0 (Placa Hitron BVW3653 com OpenRG personalizado da Jungo, fornecido pelo meu ISP)

---

---

EDITAR 1º de maio, 17:12 UTC:

$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.8 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=79.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 53.544/62.396/79.815/12.317 ms
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
    inet6 fe80::21c:bfff:fe2a:9b6/64 scope link 
       valid_lft forever preferred_lft forever
$ sudo arp -an 
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0

Como eu disse, não é veneno ARP.

NOTA 1:Só consigo acessar uma página da Web no meu roteador, pois todo o resto está bloqueado pelo ISP.

Answer 1

Essa resposta será apenas suposições, não tenho ideia se essa é realmente a causa, mas...

Quando você exclui o roteador da tabela ARP, seu computador é forçado a enviar um pacote ARP na próxima vez que quiser enviar qualquer pacote ao roteador. Posso adivinhar que este pacote ARP corrige tudo o que está quebrado na tabela ARP do roteador, já que no exemplo que você postou a tabela ARP do seu computador parece estar bem (a mesma antes e depois de "consertá-la").

Suponho que a tabela ARP do roteador, se você pudesse vê-la, mostraria "(incompleta)" em vez do endereço MAC do seu computador (tente executar ping em um endereço LAN inexistente para ver um exemplo de sua aparência). Ele chegaria a esse estado se a entrada ARP expirasse, ele transmitisse um pacote ARP e esse pacote de transmissão nunca chegasse ao seu computador (ou o pacote de resposta nunca chegasse ao roteador). Seu pacote ARP completa a entrada e pode enviar pacotes IPv4 para o seu computador novamente.

Agora, por que isso aconteceria? Posso pensar em duas causas possíveis. Um firewall mal configurado no roteador ou no computador (o que considero improvável) ou um problema com a transmissão do roteador sem fio.

Os pacotes de transmissão no padrão 802.11 são um tanto problemáticos. Uma vez que são direcionados para todas as estações associadas:

• Não são reconhecidos, pelo que a AP não pode saber se foram recebidos. Isso significa que uma única explosão de estática mal colocada pode matar um pacote de transmissão.
• Eles devem ser enviados a uma taxa que todas as estações possam ouvir. O AP não pode usar a melhor taxa encontrada pelos seus algoritmos de controle de taxa. Isso geralmente significa uma taxa muito menor, em relação às taxas básicas do BSS. Isto utiliza mais tempo de antena, mas ajuda com o problema anterior (taxas mais baixas são geralmente um pouco mais robustas).
• Como o mesmo pacote deve poder ser decodificado por todas as estações associadas, eles não podem ser criptografados com a chave individual da estação. Em vez disso, eles devem ser criptografados com uma chave de grupo separada, que todas as estações associadas conhecem. Esta chave de grupo é alternada periodicamente (caso contrário, as estações que saíram da rede ainda poderão decodificar pacotes de transmissão).

Pessoalmente, considero falhas misteriosas relacionadas a este último ponto. Um ponto de acesso que configurei veio com o intervalo de chave de grupo desativado. “Isso é idiota”, pensei, “por que eles desabilitariam esse recurso de segurança?”, e configurei para uma hora. Depois de algum tempo corrigindo problemas intermitentes de conexão sem fio que poderiam ser resolvidos com ping do lado correto (não me lembro mais se era do lado com ou sem fio - eu tinha acesso ssh ao firewall e lembro que era um ARP problema), tive uma ideia e pensei: "Ah, é por isso que ele foi desativado por padrão, provavelmente está com bugs no firmware do ponto de acesso e eles o definiram como zero como uma correção de última hora", configurei-o de volta para o padrão e o problema desapareceu.

Não tenho ideia se esse é o seu problema; o fabricante é completamente diferente e você provavelmente nunca tocou em um cenário tão esotérico.

A próxima coisa que você poderia tentar seria executar um sniffer quando o problema ocorrer, para ver quais pacotes estão sendo trocados. Se você tiver um segundo computador, poderá conectá-lo às portas LAN Ethernet do roteador e executar um sniffer ao mesmo tempo (para ver se minha hipótese de uma transmissão ARP visível na LAN, mas não na rede sem fio, tem algum mérito ).

E não tenho ideia de como os downloads continuariam se minha hipótese fosse verdadeira. Talvez de alguma forma armazene em cache o endereço MAC no estado da conexão TCP?