Беспроводное соединение не работает, пока не будет выполнена команда arp -d 192.168.1.1

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Беспроводное соединение не работает, пока не будет выполнена команда arp -d 192.168.1.1

решение1

Связанный контент