Как обнаружить диссоциацию при перезагрузке точки доступа внутри станции в режиме PS

Question

Я пишу довольно низкоуровневый драйвер для беспроводной карты, и хотя большая часть спецификации довольно проста, я еще не обдумал ни одного вопроса:

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

Я знаю, что наиболее распространенным случаем будет то, что синхронизация будет потеряна достаточно тщательно, так что я пропущу несколько маяков и просто вернусь к поиску точки доступа позже, но если по какой-то счастливой случайности мне удастся увидеть маяки,Есть ли способ узнать, что это новый «экземпляр» того же AP?

Я могу думать о

• коротком (er) поле TIM - однако яполагаю, что AP разрешено сокращать информацию TIM, если трафик не ожидает
• метка времени AP неожиданно меняется.
• поле "число маяков для следующего DTIM" chaнеожиданно.

Будучи перфекционистом, я хотел бы знать, есть ли абсолютно надежный способ обнаружить, что AP был перезагружен, вместо того, чтобы просто собирать ключи.

Answer 1

Я бы посоветовал вам взглянуть на ФБО в полученных кадрах маяка и если он слишком сильно отличается от ожидаемого ФБО, вы отправляете NULL-данные кадр к точке доступа. Если AP был перезагружен, он должен ответить деаутентифицировать кадр с указанием причины "кадр 2 класса получен от STA без проверки подлинности ".

Answer 2

У меня нет никаких знаний о беспроводных картах на этом уровне, но я бы выбрал практический маршрут и проанализировал бы связь от точки доступа, просто ведущую к разъединению, для шаблона, который соответствует типичной последовательности выключения; например, «больше нет трафика, внезапная потеря синхронизации DTIM, а затем объявление AP».

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

Ура! * * 1005