Что может вызвать сбой точки доступа 802.11n с многоадресной активностью, когда беспроводной клиент выходит за пределы допустимого диапазона?

Question

У меня есть Raspberry Pi (работает Raspbian) и беспроводной USB-адаптер LB-LINK, который служит точкой доступа 802.11n с WPA2, работает с hostapd и isc-dhcp-сервером. На Pi у меня есть скрипт Python, который отправляет многоадресные пакеты размером около 50 байтов с частотой 25 Гц. Мы заметили, что, когда беспроводной клиент выходит из зоны действия (а иногда и возвращается в зону действия) точки доступа, точка доступа начинает вести себя странно. В частности, команда socket.sendto () в сценариях python блокирует и отключенные беспроводные клиенты не могут подключиться к сети. На планшетах Android сеть показывает уровень сигнала 1 бар, хотя они находятся рядом с антенной. Кажется, что клиенты, уже подключенные к точке доступа, остаются подключенными (захват Wireshark от клиента, который уже был подключен, показывает, что он продолжает обмениваться пакетами с маршрутизатором), и показывает полную полосу мощности сигнала. Обратите внимание, что беспроводной клиент, который выходит за пределы диапазона, не обязательно должен быть частью группы многоадресной рассылки (по крайней мере, я никогда не устанавливал его явно, и мы не отправляем все группы хостов). Используемый нами беспроводной канал не используется другими соседними точками доступа. hostapd не сообщает о каких-либо отклонениях, и его остановка и запуск не решают проблему. Мы не видели этого с обычным UDP-трафиком, отправляемым с той же скоростью.

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

РЕДАКТИРОВАТЬ: Я только что воспроизвел это на совершенно другом оборудовании. NETGEAR WNR2000 с многоадресными пакетами, поступающими из приложения Visual C++, работающего на устройстве WinCE, подключенном через Ethernet (т. Е. Полностью отличающееся от настройки, использованной выше). Хотя эта конфигурация кажется более редкой, но я определенно сделал это возможным.

Answer 1

Что может привести к сбою? Ошибка в поддержке режима AP в драйвере набора микросхем Wi-Fi вашей точки доступа. Ну, драйвер или микропрограмма микросхемы, или, возможно, аппаратная часть самого чипсета.

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

Если вы просто хотите обойти это, начните с использования высококачественного фирменного USB-адаптера Wi-Fi с набором микросхем от ведущих поставщиков, таких как Broadcom или QCA (Qualcomm Atheros).

Answer 2

Может случиться так, что, когда устройство достигает границы диапазона, USB-адаптер начинает запрашивать больше энергии, чем может обеспечить Pi, и, таким образом, приводит к нестабильности. Это имело бы смысл, поскольку затрагивает только трафик TCP, который требует ответа, в то время как трафик UDP никогда не сможет достичь цели и будет просто отброшен, не вызывая каких-либо проблем.

Я не понимаю, как у вас "TCP multicast"