Беспроводная связь не работает, пока не произойдет arp -d 192.168.1.1

Question

Мой беспроводной отказывает через несколько минут после подключения к получасу или более.

Симптомы:

• новые страницы не открываются
• загрузка уже продолжается
• пинг 8.8.8.8 не работает

"Исправить" легко (длится случайное количество времени):

$ sudo arp -d 192.168.1.1

Это решение не имеет никакого смысла, так как я проверил, и это не яд ARP.

Любые идеи о том, почему это происходит?

$ 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

Беспроводной маршрутизатор: ZonHub 1.0 (плата Hitron BVW3653 с настроенным OpenRG от Jungo, предоставленная моим провайдером)

---

---

РЕДАКТИРОВАТЬ 1 мая, 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

Как я уже сказал, не яд ARP.

ПРИМЕЧАНИЕ 1. Я могу получить доступ только к веб-странице на своем маршрутизаторе, поскольку все остальное заблокировано провайдером.

Answer 1

Этот ответ будет всего лишь догадкой, я понятия не имею, если это на самом деле причина, но ...

Когда вы удаляете маршрутизатор из таблицы ARP, ваш компьютер вынужден отправлять пакет ARP в следующий раз, когда он хочет отправить любой пакет на маршрутизатор. Я могу предположить, что этот ARP-пакет исправляет все, что не работает в таблице ARP маршрутизатора, поскольку в примере, который вы опубликовали, таблица ARP вашего компьютера выглядит нормально (то же самое до и после "исправления").

Я предполагаю, что таблица ARP маршрутизатора, если бы вы могли посмотреть на нее, показала бы «(неполный)» вместо MAC-адреса вашего компьютера (попробуйте пропинговать несуществующий адрес LAN для примера того, как он выглядит). Он достигнет этого состояния, если срок действия записи ARP в нем истек, он передаст пакет ARP, и этот широковещательный пакет никогда не достигнет вашего компьютера (или ответный пакет никогда не достигнет маршрутизатора). Ваш ARP-пакет завершает запись и может снова отправлять IPv4-пакеты на ваш компьютер.

Теперь, почему это случилось? Я могу думать о двух возможных причинах. Неправильно настроенный межсетевой экран на маршрутизаторе или компьютере (что я считаю маловероятным) или проблема с трансляцией с беспроводного маршрутизатора.

Широковещательные пакеты по стандарту 802.11 несколько проблематичны. Так как они направлены на все связанные станции:

• Они не подтверждены, поэтому AP не может знать, были ли они получены. Это означает, что один неуместный пакет статических сигналов может уничтожить широковещательный пакет.
• Они должны быть отправлены со скоростью, которую могут услышать все станции. AP не может использовать лучшую скорость, найденную его алгоритмами управления скоростью. Обычно это означает гораздо более низкую ставку по сравнению с базовыми ставками BSS. Это использует больше эфирного времени, но помогает решить предыдущую проблему (более низкие тарифы обычно несколько более устойчивы).
• Поскольку один и тот же пакет должен быть в состоянии декодироваться всеми связанными станциями, они не могут быть зашифрованы с помощью индивидуального ключа станции. Вместо этого они должны быть зашифрованы отдельным групповым ключом, который знают все связанные станции. Этот групповой ключ периодически поворачивается (в противном случае станции, покинувшие сеть, могут все еще декодировать широковещательные пакеты).

Мне лично кажутся загадочные неудачи, связанные с этим последним пунктом. Точка доступа, которую я однажды настроил, пришла с отключенным интервалом групповых ключей. «Это глупо, - подумал я, - почему они отключают эту функцию безопасности?", и установите его на один час. После некоторого времени исправления неустойчивых проблем с беспроводным соединением, которые могли быть решены путем проверки связи с правильной стороны (я не помню больше, если это было с проводной или беспроводной стороны - у меня был ssh доступ к брандмауэру, и я помню, что это был ARP проблема), у меня было понимание и я подумал: «Ах, вот почему он был отключен по умолчанию, он, вероятно, глючит в этой прошивке точки доступа, и они установили его на ноль в качестве последней минуты исправления», установите его обратно в по умолчанию, и проблема исчезла.

Я понятия не имею, если это ваша проблема; производитель совершенно другой, и вы, вероятно, никогда не касались такой эзотерической обстановки.

Следующее, что вы можете попробовать, - это запустить анализатор при возникновении проблемы, чтобы увидеть, какие пакеты обмениваются. Если у вас есть второй компьютер, вы можете подключить его к Ethernet-портам маршрутизатора и одновременно запустить анализатор на нем (чтобы увидеть, имеет ли смысл гипотеза о трансляции ARP в локальной сети, но не в беспроводной сети)).

И я понятия не имею, как будет продолжаться загрузка, если моя гипотеза верна. Возможно, он как-то кеширует MAC-адрес в состоянии соединения TCP?