Технология "802.11k/r/v roaming" пояснения

[vasek00]

Цитата

• interface {AccessPoint} rrm — включить расширения 802.11k RRM (Radio Resource Management)
• interface {AccessPoint} ft enable — включить поддержку 802.11r FT (Fast Transition)
• interface {AccessPoint} ft mdid {mdid} — настроить идентификатор Mobility Domain
• interface {AccessPoint} ft ods — включить режим Over-the-DS
• interface {Bridge} iapp key {key} — настроить ключ обмена данными по IAPP*

Ввиду начала внедрения "802.11k/r/v roaming" можно хоть как то на пальцах как это будет выглядеть. Из того что есть :

FT enable - обязательна для клиента, механизм обмена ключами, т.е. если не можешь то для тебя так сказать проблема. FT Protocol и FT Resource Request Protocol между клиентом и точкой общение происходит на прямую "через воздух" (Over-the-Air) или через используемую точку (Over-the-DS). Идентификатор  Mobility Domain роуминг в пределах одного домена.

т.е. имеем клиента который будет сам запрашивать от ТД по SSID список соседей через ActionFrame => формирования списка на ТД будет автоматом по SSID, частотные каналы в данном случае должны быть одинаковые на всех ТД или могут быть разными.

Пока описания данных команд в cli нет.

Или это как-то выглядит по другому?

[pigovina]

Прошивка 2.14.B.1.0-2.

На данный момент гораздо больше интересует вопрос, когда починят ошибку status code: 28.

Edited November 26, 2018 by pigovina

[Vladimir Alferyev]

Как появится 2.14.B.2, то понаблюдайте за появлением status code: 28. Если у кого проявится, то отпишитесь

[T@rkus]

В 26.11.2018 в 17:54, Владимир23 сказал:

Как появится 2.14.B.2, то понаблюдайте за появлением status code: 28. Если у кого проявится, то отпишитесь

Ultra II 2.14.B.2.0-1 и на трех ТД подключенных к ней сообщение присутствует.

Edited November 27, 2018 by T@rkus

[pigovina]

2.14.B.2.0-1, проблема сохраняется.

[Vladimir Alferyev]

В 2.14.B.2.0-1 были пофиксены часть причин появления code status: 28. На следующих прошивках в планах другие причины также исправить. Тема ускоренного роуминга развивается и Keenetic занимается этим активно.

[T@rkus]

2.14.B.2.0-1 Столкнулся с такой вот странностью на тд см.скрин. И это только часть лога. Self-testы на всякий прилагаю

[Vladimir Alferyev]

а что за модель STA (dc:...:68:9e)?

[T@rkus]

1 минуту назад, Владимир23 сказал:

а что за модель STA (dc:...:68:9e)?

Увы не знаю. Дело было в гостевой сети. Там за день масса устройств бывает. Но это вчера и сегодня вот так вот наследило в логе. Могу только полный МАС устройства дать 

[pigovina]

В релизе 2.14 стоит ли ждать решения проблемы?

Также когда-то давно проскакивала информация, что 802.11v как раз планируется в этот релиз, но на сколько я понимаю, пока не успели сделать?

[Vladimir Alferyev]

Firmware v2.14 включает 11k/r. В следующей прошивке в планах 11v. В работе.

[pigovina]

14 часа назад, Владимир23 сказал:

Firmware v2.14 включает 11k/r. В следующей прошивке в планах 11v. В работе.

А разве релиз 11k/r состоялся не в v2.13 ?

[vasek00]

Sams клиент, на котором просто включен разарботчик и галки в некоторых местах на разделе сети, root не нужен.

Два роутера с одним SID но с разными каналами 5GHz - 5180 и 5280

Edited December 7, 2018 by vasek00

[vasek00]

Роутер1
Дек 7 16:50:34 wmond WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:d9) had associated successfully (FT mode).
Дек 7 16:50:35 wmond WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:d9) set key done in WPA2/WPA2PSK.
Дек 7 16:50:35 ndhcps DHCPREQUEST received (STATE_INIT) for 192.168.1.21 from хх:хх:хх:хх:хх:d9.
Дек 7 16:50:35 ndhcps sending ACK of 192.168.1.21 to хх:хх:хх:хх:хх:d9.

Роутер2
Дек 7 16:50:34 mtkiappd IAPP: UDP packet: invalid tag Version (59), possible IAPP keys mismatch!
Дек 7 16:50:35 ndhcps DHCPREQUEST received (STATE_INIT) for 192.168.1.21 from хх:хх:хх:хх:хх:d9.
Дек 7 16:50:35 ndhcps sending ACK of 192.168.1.21 to хх:хх:хх:хх:хх:d9.

IAPP: UDP packet: invalid tag Version (59), possible IAPP keys mismatch!

[pigovina]

Прошивка 2.14.С.0.0-0, ошибка 28 присутствует. Клиентские устройства Samsung и Apple.

[T@rkus]

16 минут назад, pigovina сказал:

Прошивка 2.14.С.0.0-0, ошибка 28 присутствует. Клиентские устройства Samsung и Apple.

Подтверждаю

[Vladimir Alferyev]

готовится к публикации новая версия v2.14. В ней будут внесены дополнительные исправления по ошибке 28 

[pigovina]

12 часа назад, Владимир23 сказал:

готовится к публикации новая версия v2.14. В ней будут внесены дополнительные исправления по ошибке 28 

Владимир, а Вы участвуете в разработке или какое-то отношение имеете к ней?

Хотелось бы получить какие-то официальные комментарии по этой проблеме, однако наши уважаемые разработчики почему-то обходят тему стороной.

Специально несколько месяцев назад обновлялся парк точек доступа на нескольких объектах для внедрения бесшовного роуминга, а в итоге поставленная цель была не достигнута и когда ждать решения проблемы и стоит ли вообще - не ясно.

[Vladimir Alferyev]

работаю в Keenetic, но не занимаюсь подготовкой кода. Самому интересно проводить тест роуминга и участвую в этом форуме. Работаем над доработкой функций и техподдержка разбирает каждую тему. Предполагаю вы задавали очередной вопрос в среду нашей техподдержки и они ответили.

[T@rkus]

После обновления роутеров на прошивку 2.14.C.0.0-3 ошибка FT authentication rejected (status code: 28) по прежнему присутствует.

[Vladimir Alferyev]

Пожалуйста, пришлите скриншот логов либо полностью журнал. Если заводили тему в техподдержке, отправьте туда файл журнала. На какой модели это случилось?

[T@rkus]

Только что, Владимир23 сказал:

Пожалуйста, пришлите скриншот логов либо полностью журнал. Если заводили тему в техподдержке, отправьте туда файл журнала. На какой модели это случилось?

Ultra II (роутер); Giga III (тд); Lite III rev/B (тд); Start II (тд) Со всех четырех роутеров логи прислать?

[Vladimir Alferyev]

С одного пока достаточно где ошибка присутствует в логе.

[T@rkus]

3 минуты назад, Владимир23 сказал:

С одного пока достаточно где ошибка присутствует в логе.

В личку или скрытым?

[Vladimir Alferyev]

отправьте в личку файлом. 

[Padavan]

3 часа назад, T@rkus сказал:

После обновления роутеров на прошивку 2.14.C.0.0-3 ошибка FT authentication rejected (status code: 28) по прежнему присутствует. 

Ошибка означает, что хост-кейхолдер не может найти в базе PMK-R0 или R1 запись при попытке клиента пройти на нем FT auth. Такое сейчас возможно, после того как

- вы смените любые настройки Wireless и база PMK будет очищена при перезапуске драйвера
- роутер/AP будут перезагружены
- изменится IP на AP, при этом управляющий демон будет перезапущен

На текущий момент, в 2.14.C.0.0-3 это все факторы, приводящие к очистке базы данных PMK-R1 кейхолдера. До  2.14.C.0.0-3 существовали еще критерии, когда база кейхолдера обнулялась.

После того как клиент не смог перейти по FT auth, он обычно коннектится стандартным способом, используя 4-way хендшейк и база кейхолдера обновляется автоматически. У нас есть идеи, как побороть первые 2 пункта, не прибегая к сохранению PMK-R1 (так как он секретный).

-
На данной ошибке не стоит заострять внимание, так как результат FT auth выводили специально для внутренней отладки.

[pigovina]

9 часов назад, Padavan сказал:

Ошибка означает, что хост-кейхолдер не может найти в базе PMK-R0 или R1 запись при попытке клиента пройти на нем FT auth. Такое сейчас возможно, после того как

- вы смените любые настройки Wireless и база PMK будет очищена при перезапуске драйвера
- роутер/AP будут перезагружены
- изменится IP на AP, при этом управляющий демон будет перезапущен

На сколько я понимаю, ни под один из 3-х случаев мой сценарий работы не попадает: 

К примеру, вчера утром я перезагрузил роутеры при обновлении прошивки, никакие настройки более на нем не менялись. Предположим, что после перезагрузки может разово возникнуть данная ошибка, однако она мелькает на протяжении всего дня. Вечером сотрудники ушли из офиса, вернулись на следующий день, авторизовались по 4-way после отсутствия, ошибка 28 мелькает снова весь день.

9 часов назад, Padavan сказал:

После того как клиент не смог перейти по FT auth, он обычно коннектится стандартным способом, используя 4-way хендшейк и база кейхолдера обновляется автоматически. У нас есть идеи, как побороть первые 2 пункта, не прибегая к сохранению PMK-R1 (так как он секретный).

-
На данной ошибке не стоит заострять внимание, так как результат FT auth выводили специально для внутренней отладки.

А разве тогда не теряется смысл бесшовного роуминга, если клиент не проходит FT, в результате чего начинается полный цикл 4-way? Ну и при этом происходит разрыв WiFi Call звонка.

С таким результатом можно любые другие ТД без поддержки роуминга использовать с одним SSID. Правда и времени на поиск соседних точек будет уходить больше, однако звонок все равно рвется даже и без этого затраченного времени.

Edited December 25, 2018 by pigovina

[Padavan]

Речь о другом, наличие такой ошибки допустимо, факторы я перечислил. Если у вас после  2.14.C.0.0-3 все равно весь лог засыпан этой ошибкой, то что-то идет не так, нужно разбираться в конкретном случае.

[pigovina]

Понял, как соберу статистику, self-test'ы, отпишусь.

[T@rkus]

3 часа назад, Padavan сказал:

Речь о другом, наличие такой ошибки допустимо, факторы я перечислил. Если у вас после  2.14.C.0.0-3 все равно весь лог засыпан этой ошибкой, то что-то идет не так, нужно разбираться в конкретном случае.

Сегодня посмотрел логи на четырех выше мной упомянутых роутерах. Ошибка появляется довольно часто. На всякий прилагаю self-testы со всех четырех.

[Padavan]

T@rkus

Спасибо за логи, попробуем разобраться.