Mi conexión inalámbrica falla desde algunos minutos después de estar conectada hasta media hora o más.
Síntomas:
- nuevas páginas no se abren
- las descargas que ya están en progreso continúan
- ping 8.8.8.8 no funciona
La "solución" es fácil (dura un período de tiempo aleatorio):
$ sudo arp -d 192.168.1.1
Esta solución no tiene ningún sentido, ya que lo he comprobado y no es veneno ARP.
¿Alguna idea de por qué sucede esto?
$ 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
Enrutador inalámbrico: ZonHub 1.0 (Placa Hitron BVW3653 con OpenRG de Jungo personalizado, proporcionado por mi ISP)
EDITAR 1 de mayo a las 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 dije, no es veneno ARP.
NOTA 1:Solo puedo acceder a una página web en mi enrutador, ya que todo lo demás está bloqueado por el ISP.
Respuesta1
Esta respuesta serán todas conjeturas, no tengo idea si esta es realmente la causa, pero...
Cuando elimina el enrutador de su tabla ARP, su computadora se ve obligada a enviar un paquete ARP la próxima vez que quiera enviar cualquier paquete al enrutador. Puedo suponer que este paquete ARP arregla cualquier cosa que esté rota en la tabla ARP del enrutador, ya que en el ejemplo que publicaste, la tabla ARP de tu computadora parece estar bien (lo mismo antes y después de "arreglarlo").
Supongo que la tabla ARP del enrutador, si pudiera mirarla, mostraría "(incompleto)" en lugar de la dirección MAC de su computadora (intente hacer ping a una dirección LAN inexistente para ver un ejemplo de cómo se ve). Llegaría a ese estado si la entrada ARP expirara, transmitiera un paquete ARP y ese paquete de transmisión nunca llegara a su computadora (o el paquete de respuesta nunca llegara al enrutador). Su paquete ARP completa la entrada y puede enviar paquetes IPv4 a su computadora nuevamente.
Ahora bien, ¿por qué sucedería eso? Puedo pensar en dos posibles causas. Un firewall mal configurado en el enrutador o en su computadora (lo cual creo que es improbable), o un problema con la transmisión desde el enrutador inalámbrico.
Los paquetes de difusión según el estándar 802.11 son algo problemáticos. Ya que están dirigidos a todas las estaciones asociadas:
- No se reconocen, por lo que AP no puede saber si fueron recibidos. Esto significa que una sola ráfaga de estática fuera de lugar puede matar un paquete de transmisión.
- Deben enviarse a una velocidad que todas las estaciones puedan escuchar. El AP no puede utilizar la mejor tarifa encontrada por sus algoritmos de control de tarifas. Esto suele significar una tarifa mucho más baja que las tarifas básicas del BSS. Esto utiliza más tiempo aire, pero ayuda con el problema anterior (las tarifas más bajas suelen ser algo más sólidas).
- Dado que el mismo paquete debería poder ser decodificado por todas las estaciones asociadas, no se pueden cifrar con la clave individual de la estación. En su lugar, deben cifrarse con una clave de grupo independiente, que todas las estaciones asociadas conocen. Esta clave de grupo se rota periódicamente (de lo contrario, las estaciones que abandonaron la red aún podrían decodificar paquetes de transmisión).
Personalmente me parecen misteriosos fallos relacionados con este último punto. Un punto de acceso que una vez configuré venía con el intervalo de clave de grupo deshabilitado. "Esto es una tontería", pensé, "¿por qué desactivarían esa característica de seguridad?", y la configuraron en una hora. Después de un tiempo solucionando problemas intermitentes de conexión inalámbrica que podían resolverse haciendo ping desde el lado correcto (ya no recuerdo si era desde el lado cableado o inalámbrico; tenía acceso ssh al firewall y recuerdo que era un ARP). problema), tuve una idea y pensé: "Ah, ESO es el motivo por el que estaba deshabilitado de forma predeterminada, probablemente tenga errores en el firmware del punto de acceso y lo configuraron en cero como solución de último momento", configúrelo de nuevo en el predeterminado y el problema desapareció.
No tengo idea si ese es tu problema; el fabricante es completamente diferente y probablemente nunca hayas tocado un entorno tan esotérico.
Lo siguiente que podría intentar sería ejecutar un rastreador cuando ocurra el problema, para ver qué paquetes se están intercambiando. Si tiene una segunda computadora, puede conectarla a los puertos LAN Ethernet del enrutador y ejecutar un rastreador también al mismo tiempo (para ver si mi hipótesis de una transmisión ARP visible en la LAN pero no en la inalámbrica tiene algún mérito). ).
Y no tengo idea de cómo continuarían las descargas si mi hipótesis es cierta. ¿Quizás de alguna manera almacena en caché la dirección MAC en el estado de conexión TCP?