Запись deauthenticated due to local deauth request или строка вида «deauth after EAPOL key exchange sequence» в логах hostapd, wpa_supplicant или NetworkManager означает, что точка доступа разорвала соединение сразу после завершения четырёхстороннего рукопожатия 4-way handshake — то есть пароль был принят, ключи согласованы, но сеанс тут же оборвался. Это одна из самых неочевидных причин «мигающего» Wi-Fi: клиент подключается, получает IP или не успевает его получить и через секунды отваливается снова.
Ошибка встречается на роутерах с OpenWrt, hostapd в Linux, точках доступа Ubiquiti, MikroTik и при подключении Linux-клиентов через wpa_supplicant. Ниже разберём, что происходит на этапе обмена ключами EAPOL, какие причины чаще всего приводят к немедленному деаутентификации и как это диагностировать без риска для сети.
Что происходит на этапе EAPOL key exchange
Протокол EAPOL (EAP over LAN) используется в WPA2 и WPA3 для согласования сеансовых ключей шифрования. После того как клиент прошёл аутентификацию (ввёл правильный пароль PSK или прошёл 802.1X), точка доступа и станция выполняют четырёхэтапный обмен сообщениями EAPOL-Key: точка отправляет ANonce, клиент отвечает SNonce и MIC, затем стороны подтверждают установку группового ключа GTK.
Если все четыре сообщения прошли успешно, соединение считается установленным, и в логе появляется строка вида WPA: Key negotiation completed. Когда сразу после этого следует deauth, значит, разрыв инициировала не ошибка пароля, а логика уже после успешного рукопожатия — и это ключевая подсказка для диагностики.
Отличить такой сценарий от банально неверного пароля просто: при неверном PSK рукопожатие обрывается на втором или третьем сообщении, и в логе будет 4-Way Handshake failed или таймаут handshake. Если же handshake завершён, а deauth пришёл после — искать нужно в другом месте.
Deauth после завершённого EAPOL handshake — это не проблема пароля. Разрыв вызывают настройки точки доступа, конфликт ключей или особенности клиента, проявляющиеся уже после успешной авторизации.
Типичные причины разрыва после рукопожатия
Единого «кода 6105» в стандарте 802.11 не существует: причина деаутентификации передаётся полем reason code в кадре deauth, и его значение зависит от прошивки точки. Поэтому первый шаг — посмотреть, какой reason code сопровождает разрыв в вашем конкретном логе. Частые причины выглядят так:
- 🔑 Смена или рассинхронизация group key — точка ротирует GTK, клиент не успевает или не может обновить ключ, и точка отключает его.
- 📡 Конфликт параметров шифрования — например, точка принудительно требует WPA3/SAE или management frame protection (
ieee80211w), а клиент его не поддерживает или настроен иначе. - ⏱️ Агрессивные таймеры inactivity — короткий
ap_max_inactivityили max_listen_interval приводит к отключению «тихих» клиентов почти сразу после подключения. - 🔁 Дублирующийся MAC или повторная ассоциация — тот же клиент (или устройство с рандомизированным MAC) ассоциируется повторно, и точка сбрасывает предыдущую сессию.
- 🌐 Проблемы на уровне выше — VLAN, ACL, RADIUS или фильтрация на контроллере отклоняют клиента после успешной аутентификации.
⚠️ Внимание: не меняйте одновременно несколько параметров безопасности (шифрование, PMF, таймеры). Иначе вы не сможете понять, какое изменение устранило разрыв, и рискуете оставить сеть в нестабильной конфигурации.
Диагностика: как собрать нужные данные
Диагностику начинайте с логов обеих сторон. На точке с hostapd полезно временно поднять уровень детализации и смотреть события в реальном времени:
logread -f -e hostapdНа Linux-клиенте аналогичную информацию даёт журнал wpa_supplicant или NetworkManager:
journalctl -u wpa_supplicant -f
journalctl -u NetworkManager -f
Обратите внимание на три вещи: завершился ли handshake (Key negotiation completed), какой reason code указан в кадре deauth и кто его инициировал — точка (AP-STA-DISCONNECTED на стороне hostapd) или сам клиент. Если клиент отключается сам, подозревать нужно драйвер, энергосбережение адаптера или конфликт сетевых служб, а не точку доступа.
Если есть возможность, подключите к той же сети второе устройство другого типа (например, смартфон вместо ноутбука). Если разрывается только одно устройство — проблема почти наверняка на стороне клиента, а не точки.
Проверка настроек точки доступа
На стороне точки доступа проверьте параметры, которые чаще всего связаны с разрывом после handshake. Конкретные имена опций зависят от прошивки, поэтому сверяйтесь с документацией вашей версии hostapd или OpenWrt.
☑️ Что проверить на точке доступа
Особое внимание уделите protected management frames. Если на точке выставлено обязательное PMF (ieee80211w=2), а клиент его не поддерживает или у него устаревший драйвер, разрыв может происходить именно после обмена ключами. Временный перевод в опциональный режим (ieee80211w=1) — безопасный способ проверить эту гипотезу.
Вторая частая причина — слишком частая ротация группового ключа. Если параметр wpa_group_rekey выставлен в очень малое значение, клиенты с агрессивным энергосбережением могут не успевать обрабатывать rekey и отключаться. Увеличение интервала или отключение принудительной ротации — обратимая проверка, которую легко откатить.
Почему mixed-режим WPA2/WPA3 иногда провоцирует разрывы
В переходном режиме точка анонсирует одновременно PSK и SAE. Некоторые клиенты с устаревшими драйверами некорректно выбирают метод аутентификации или путаются при обработке PMF. Если deauth появился после включения WPA3 transition mode, попробуйте временно оставить чистый WPA2 и проверить стабильность — это безопасный диагностический шаг.
Проверка со стороны клиента
На клиентском устройстве первым делом отключите энергосбережение Wi-Fi-адаптера — оно регулярно вызывает самопроизвольные деаутентификации. Для Linux-подключения через NetworkManager проверить текущий режим можно так:
iw dev wlan0 get power_saveЕсли power save включён, временно отключите его командой iw dev wlan0 set power_save off и понаблюдайте, прекратились ли разрывы. Имя интерфейса (wlan0) уточните командой iw dev — оно зависит от системы.
Также проверьте:
- 💾 Актуальность драйвера адаптера — старые драйверы Intel, Realtek и MediaTek имели известные проблемы с WPA3 и PMF; обновление через штатный пакетный менеджер — первый шаг.
- 🎲 Рандомизацию MAC-адреса — если точка или контроллер привязывает сессии к MAC, смена адреса при переподключении может вызывать сброс предыдущей сессии.
- 📶 Конфликт служб — одновременно работающие wpa_supplicant вручную и NetworkManager могут «перехватывать» интерфейс друг у друга, что выглядит как циклические deauth.
⚠️ Внимание: не отключайте шифрование сети «для проверки» — открытая сеть даже на короткое время создаёт риск перехвата трафика. Диагностируйте на защищённой конфигурации, меняя по одному параметру.
Сводная таблица симптомов и причин
| Что видно в логе | Вероятная причина | Что проверить в первую очередь |
|---|---|---|
| Handshake завершён, deauth от точки через секунды | PMF, VLAN/ACL, ротация GTK | ieee80211w, wpa_group_rekey, списки доступа |
| Handshake failed / timeout | Неверный пароль или несовместимость WPA2/WPA3 | PSK, режим шифрования, mixed-режим |
| Deauth инициирует клиент | Энергосбережение, драйвер, конфликт служб | power_save, обновление драйвера, NetworkManager vs wpa_supplicant |
| Разрыв только у одного устройства | Проблема конкретного клиента | Драйвер, MAC-рандомизация, поддержка PMF |
| Разрывы у всех клиентов одновременно | Настройки или нестабильность самой точки | Таймеры, канал, перезагрузка и логи точки |
Когда стандартные проверки не помогают
Если после перебора настроек разрыв сохраняется, следующий шаг — захват трафика. Сниффер на отдельном адаптере в режиме монитора (например, через Wireshark) покажет сам кадр deauth и его reason code, который не всегда попадает в логи. Это самый достоверный способ понять, кто и почему разорвал сессию.
Для корпоративных точек (Ubiquiti UniFi, MikroTik, контроллерные решения) имеет смысл проверить журналы контроллера: разрыв может инициировать не радиочасть, а политика доступа — например, RADIUS-сервер, гостевой портал или балансировка между точками. В таких сетях диагностику лучше вести совместно с администратором инфраструктуры.
Наконец, не исключайте аппаратную составляющую: нестабильное питание точки доступа, перегрев или дефектный адаптер клиента тоже проявляются циклическими переподключениями. Если логи «чистые», а разрывы продолжаются — проверьте устройство на другой сети и другую сеть на этом устройстве.
Методика диагностики deauth после EAPOL: сначала определить инициатора разрыва и reason code, затем проверять по одному параметру — PMF, ротацию ключей, энергосбережение, драйвер. Захват кадров в Wireshark — финальный арбитр, когда логи не дают ответа.
Частые вопросы
Означает ли deauth после EAPOL handshake, что пароль Wi-Fi неверный?
Нет. При неверном пароле четырёхстороннее рукопожатие обрывается с ошибкой handshake, и в логе это видно отдельно. Если handshake завершён успешно, а deauth пришёл после — причина в настройках точки, клиента или политиках доступа, а не в пароле.
Что такое reason code в кадре deauth и где его смотреть?
Это числовое поле в кадре деаутентификации, указывающее причину разрыва (например, «previous authentication no longer valid» или таймаут неактивности). Его видно в детальных логах hostapd/wpa_supplicant и в захвате трафика через Wireshark. Точная расшифровка кодов приведена в стандарте 802.11 и документации к вашей прошивке.
Может ли включённый WPA3 вызывать такие разрывы?
Да, особенно переходный режим WPA2/WPA3 с обязательной защитой management-кадров (PMF). Клиенты со старыми драйверами могут разрываться сразу после обмена ключами. Проверяется временным переводом точки в чистый WPA2 или в режим опционального PMF.
Разрывается только один ноутбук, остальные устройства работают. Что делать?
Проблема почти наверняка на стороне клиента: обновите драйвер адаптера, отключите энергосбережение Wi-Fi, проверьте, не конфликтуют ли сетевые службы, и попробуйте отключить рандомизацию MAC-адреса для этой сети.
Опасно ли отключать ротацию группового ключа (wpa_group_rekey)?
Отключение или увеличение интервала ротации снижает частоту смены группового ключа, что теоретически ослабляет защиту широковещательного трафика. Для домашней сети это обычно приемлемый компромисс ради стабильности, но решение стоит принимать осознанно и при возможности вернуть ротацию после обновления проблемных клиентов.