Имеется Wi-Fi система из KN-3010 в роли контроллера и двух KN-3210 в роли ретрансляторов. Также есть проблемный клиент OnePlus 9R, у которого производитель в OxygenOS 13 сломал переходы по FT - телефон держится за первой точкой доступа, не выполняя переход к другой до полной потери сигнала от первой. В логах это выглядит так:
[I] Mar 3 11:07:43 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) FT authenticated successfully.
[I] Mar 3 11:07:43 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) MIC differs in key handshaking.
[I] Mar 3 11:07:43 ndm: Core::Syslog: last message repeated 4 times.
[I] Mar 3 11:07:44 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) had deauthenticated by STA (reason: unspecified).
С поддержкой выяснили, что проблема в некорректном формировании поля Mesh Peering Management драйвером клиента - превышается максимальная длина пакета, в результате чего точка отвечает ошибкой:
Скрытый текст
Баг-репорт с дампом эфира, где явно видно, что это проблема драйвера клиента, был отправлен в OnePlus, откуда я получил ответ, что исправление будет "в ближайшем будущем".
По предыдущему опыту с OnePlus 6, где также производитель много месяцев обещал исправить сломавшийся переход по FT в спящем режиме, но так этого и не сделал, отправив девайс в EoL, решил создать дополнительную сеть в сегменте (необходимо, чтобы клиент имел полный доступ к сегменту) без FT, где будет работать хотя бы переход по PMK-кэшу, т.к. с этим у OnePlus проблем не замечал.
Скопировал все настройки из основной сети сегмента, исключив только связанные с FT параметры, включил её в сегмент и попробовал выполнить переходы. Результат оказался аналогичный - телефон делает попытки перейти на другую ТД, но они завершаются неудачно. Согласно логам точки, к которой клиент собирается перейти, выглядит так, как будто клиент подключился и его сразу же отключился, т.к. его "выкинула" ТД:
[I] Mar 3 11:08:55 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint2": STA(mac) had re-associated successfully.
[I] Mar 3 11:08:55 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint2": STA(mac) had deauthenticated by AP (reason: STA is leaving or has left BSS).
Мной был снят дамп эфира в моменты перехода. Согласно нему, точка, к которой клиент собирается перейти, отвечает ему на reassociation request. Затем идет целая пачка deauth-пакетов от точки, которой клиент покидает:
Скрытый текст
Далее вторая точка по каким-то причинам не начинает хэндшейк с клиентом, и в результате, переход не завершается, телефон остается на первой точке. Чтобы исключить проблему именно с OnePlus 9R, попробовал в этой сети выполнить переход с другими клиентами, их поведение было полностью аналогично.
Если же создать новый сегмент, в котором настроить сеть без FT, то телефон начинает корректно выполнять переход по PMK между точками, нигде не "застревая". В логах в этот момент нет никаких отключений:
[I] Mar 3 11:13:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint3": STA(mac) had re-associated successfully.
[I] Mar 3 11:13:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint3": STA(mac) set key done in WPA2/WPA2PSK.
Снятый дамп эфира показал, что deauth-пакетов от первой точки оказалось намного меньше, а вторая начала хэндшейк, в результате чего переход завершился:
Скрытый текст
В попытках понять причину, начал откатываться на более старые версии KeeneticOS с имеющимися настройками. В уже довольно старой 3.7.4 обнаружил, что переход по PMK-заработал в дополнительной сети сегмента, равно как и не сломался в новом сегменте. Снятые дампы показали, что точка, от которой клиент "уходит", вовсе не шлет deauth, а вторая, к которой клиент переходит, начинает хэндшейк и переход далее успешно завершается.
Затем, прямо с 3.7.4 пробовал обновиться до прошивок 3.9-4.0, в дополнительной сети сразу же сломался переход по PMK, а в новом сегменте сохранил свою работу.
В поддержке сообщили, что в свежих версиях отправка deauth-пакетов клиенту является работой специального механизма, который подчищает уходящих клиентов, чтобы впоследствии, если они захотят вернуться на эту точку, переход корректно выполнился.
Для меня осталось непонятным, почему в дополнительной сети сегмента в актуальных прошивках точка не хочет начинать хэндшейк с клиентом, который к ней собирается перейти.
@Padavan подскажите, пожалуйста, с чем может быть связано такое поведение?
А также, возможно ли со стороны точки доступа проигнорировать поле Mesh Peering Management в пакете от клиента при совершении FT-перехода? Какие в этом случае могут быть последствия в работе FT для сети и её клиентов?
Все снятые дампы эфира, self-test с разных версий KeeneticOS отправлял ранее в поддержку. Ticket ID: 126899824.
You can post now and register later.
If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.
Question
dimon27254
Имеется Wi-Fi система из KN-3010 в роли контроллера и двух KN-3210 в роли ретрансляторов. Также есть проблемный клиент OnePlus 9R, у которого производитель в OxygenOS 13 сломал переходы по FT - телефон держится за первой точкой доступа, не выполняя переход к другой до полной потери сигнала от первой. В логах это выглядит так:
[I] Mar 3 11:07:43 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) FT authenticated successfully. [I] Mar 3 11:07:43 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) MIC differs in key handshaking. [I] Mar 3 11:07:43 ndm: Core::Syslog: last message repeated 4 times. [I] Mar 3 11:07:44 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint0": STA(mac) had deauthenticated by STA (reason: unspecified).С поддержкой выяснили, что проблема в некорректном формировании поля Mesh Peering Management драйвером клиента - превышается максимальная длина пакета, в результате чего точка отвечает ошибкой:
Баг-репорт с дампом эфира, где явно видно, что это проблема драйвера клиента, был отправлен в OnePlus, откуда я получил ответ, что исправление будет "в ближайшем будущем".
По предыдущему опыту с OnePlus 6, где также производитель много месяцев обещал исправить сломавшийся переход по FT в спящем режиме, но так этого и не сделал, отправив девайс в EoL, решил создать дополнительную сеть в сегменте (необходимо, чтобы клиент имел полный доступ к сегменту) без FT, где будет работать хотя бы переход по PMK-кэшу, т.к. с этим у OnePlus проблем не замечал.
Скопировал все настройки из основной сети сегмента, исключив только связанные с FT параметры, включил её в сегмент и попробовал выполнить переходы. Результат оказался аналогичный - телефон делает попытки перейти на другую ТД, но они завершаются неудачно. Согласно логам точки, к которой клиент собирается перейти, выглядит так, как будто клиент подключился и его сразу же отключился, т.к. его "выкинула" ТД:
[I] Mar 3 11:08:55 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint2": STA(mac) had re-associated successfully. [I] Mar 3 11:08:55 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint2": STA(mac) had deauthenticated by AP (reason: STA is leaving or has left BSS).Мной был снят дамп эфира в моменты перехода. Согласно нему, точка, к которой клиент собирается перейти, отвечает ему на reassociation request. Затем идет целая пачка deauth-пакетов от точки, которой клиент покидает:
Далее вторая точка по каким-то причинам не начинает хэндшейк с клиентом, и в результате, переход не завершается, телефон остается на первой точке. Чтобы исключить проблему именно с OnePlus 9R, попробовал в этой сети выполнить переход с другими клиентами, их поведение было полностью аналогично.
Если же создать новый сегмент, в котором настроить сеть без FT, то телефон начинает корректно выполнять переход по PMK между точками, нигде не "застревая". В логах в этот момент нет никаких отключений:
[I] Mar 3 11:13:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint3": STA(mac) had re-associated successfully. [I] Mar 3 11:13:11 ndm: Network::Interface::Rtx::WifiMonitor: "WifiMaster0/AccessPoint3": STA(mac) set key done in WPA2/WPA2PSK.Снятый дамп эфира показал, что deauth-пакетов от первой точки оказалось намного меньше, а вторая начала хэндшейк, в результате чего переход завершился:
В попытках понять причину, начал откатываться на более старые версии KeeneticOS с имеющимися настройками. В уже довольно старой 3.7.4 обнаружил, что переход по PMK-заработал в дополнительной сети сегмента, равно как и не сломался в новом сегменте. Снятые дампы показали, что точка, от которой клиент "уходит", вовсе не шлет deauth, а вторая, к которой клиент переходит, начинает хэндшейк и переход далее успешно завершается.
Затем, прямо с 3.7.4 пробовал обновиться до прошивок 3.9-4.0, в дополнительной сети сразу же сломался переход по PMK, а в новом сегменте сохранил свою работу.
В поддержке сообщили, что в свежих версиях отправка deauth-пакетов клиенту является работой специального механизма, который подчищает уходящих клиентов, чтобы впоследствии, если они захотят вернуться на эту точку, переход корректно выполнился.
Для меня осталось непонятным, почему в дополнительной сети сегмента в актуальных прошивках точка не хочет начинать хэндшейк с клиентом, который к ней собирается перейти.
@Padavan подскажите, пожалуйста, с чем может быть связано такое поведение?
А также, возможно ли со стороны точки доступа проигнорировать поле Mesh Peering Management в пакете от клиента при совершении FT-перехода? Какие в этом случае могут быть последствия в работе FT для сети и её клиентов?
Все снятые дампы эфира, self-test с разных версий KeeneticOS отправлял ранее в поддержку. Ticket ID: 126899824.
Link to comment
Share on other sites
8 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.