поставил последнюю прошивку

 

802.11r исчезло из настроек, и, я смотрю, уже по дефолту вменяемые значения для отстрела.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

802.1r для однобэндов грю же нет в стабильной ветке. Эт у нас вебер накосячил потому оно в роже оказалось на однушках со стабильной веткой дров.

 

Значения да, подогнаны для решения общей проблемы +/- километр. Надо будет позже несколько профилей сделать.

 

Запустились уже?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

да, запустились, вернее сейчас тестируем.

а как узнать, умеет ли клиент k? или проще включить и не думать? (или наоборот выключить, если там глюки могут быть)

Изменено пользователем edo

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Включить и не думать. Вероятность что умеет стремиться к нулю. Но в отличии от R оно даже если не умеет или умеет криво никак не приведёт к глюкам. Оно по сути только добавляет доп инфу к маякам и отвечает на специализированные запросы (в случае с текущей реализацией на однобэндах оно добавляет TPC, информацию о региональных ограничениях, так же без этих анонсов не все клиенты используют QLOAD которые анонсируются у нас на самом деле всегда и т.д. и т.п.).

 

Т.е. если клиент как-то сможет использовать эти дополнительные данные - хорошо.Нет, ну нет так нет. А вот 802.11r меняет логику аутентификации, и вот там да могут быть проблемы совместимости если клиенты кривые.

 

да, запустились, вернее сейчас тестируем.

 

Результат? Что за клиенты?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2) KickStaRssiLowPSM - уровень при котором отстреливать клиента находящегося в режиме энергосбережения

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

 

нельзя ли в "station list" как-то индицировать нахождение клиента в режиме энергосбережения?

 

Результат? Что за клиенты?

пока в процессе

 

недорогие android'ы

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

нельзя ли в "station list" как-то индицировать нахождение клиента в режиме энергосбережения?

 

Ессно, он грит АП что будет спать, и АП данные для него буферизирует и выплёвывает партиями по таймеру а не сразу. И т.д. В stalist включить режим advanced и всё увидите и PSM и прочее.

 

 

пока в процессе

 

недорогие android'ы

 

Ясно, чёт затянулся у вас процесс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да забыл сказать. Ести используете принудительный отстрел по уровню,то WPA Enterprise противопоказан, ну либо порог отстрела должен быть очень низко (т.е. клиенты сами должны инициировать миграцию если умеют, обычно оно происходит при уровне -75/-85 например на intel7260 при средней и низкой агрессивности роуминга в настойках клиента). При принудительном сбросе при использовании WPA2 Enterprise почти все клиенты переподключаются используя полную фазу соединения как в первый раз. Так что никакие FT или OKC тут уже не помогут. Т.е. принудительный отстрел в режимах с WPA2 Enterprise должен выполнять лишь страховочную роль.

 

Вот такой вот бедлам.

 

В вашем случае (ну раз дешовые ведроиды и под озвученную задачу) я бы не парился со всякими ынтырпрайзами, а сделал бы тупо WPA2+PSK с принудительным отстрелом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Надеюсь поделитесь потом изысканиями и профилем, может кому пригодиться. Может мы добавим ваш профиль в рожу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё нюанс, смотрим например сюда https://android.googlesource.com/kernel/omap.git/+/33354ddea6e0c1165f9067d7b42bf53278872cf3/drivers/net/wireless/bcmdhd/Makefile

 

Видим:

DHDCFLAGS += -DCUSTOM_ROAM_TRIGGER_SETTING=-70

 

Флаг задаёт The RSSI threshold to trigger roaming порог при котором клиент "задумается о" миграции и выполнит определённые телодвижения которые приведут или не приведут к запуску собсно процедуры миграции (handover).

 

Это значение варьируется от вендора к вендору (ну если клиент вообще умеет самостоятельно выполнять миграцию без пинка и запретных мер со стороны сети, не редко встречаются клиенты которые и этого не умеют, а висят пока не отвалятся по числу ошибок передачи) в диапазоне от -65 до -75 для broadcom based клиентов (для остальных примерно так же). Т.е. если мы хотим по возможности что бы клиент мигрировал сам используя всевозможные OKC/R и и.т.д. мы не должны мешать ему самому инициировать миграцию. А значит уровень отстрела должен быть ниже -75 (что бы спихивать принудительно только тех что сами не могут мигрировать). Что не всегда выполнимо когда нужно разместить АП действительно плотно, а вместо стен стекло (см офис НАГ). И вот тут придётся решать или мы гарантированно раскидаем клиентов по АП где они будут работать максимально эффективно, либо будем радоваться максимально прозрачному роумингу.

 

Причём надо понимать, что уровень с которым клиент видит АП и по которому принимает решение о миграции, и уровень с которым мы видим его это суть разные вещи (rssi feedback увы так же не стал частью "стандарта")...

 

Тоже касается и band steering, т.к. в основе этого метода балансировки по диапазонам (на самом деле костыля) лежит попытка выяснить кто что может и не пустить на 2.4 тех кто может 5ть это может сиииильно осложнить миграцию клиентов между АП. Больше половины клиентов всегда будут выбирать 2.4ГГц АП просто потому что там заведомо уровень выше (а опускать низя, вокруг другие дядьки шумят своими АП и сразу по рэйту провалимся), т.е. будет долбиться на 2.4, а band steering будет не пускать видя что оно 5ку может. И часто приходиться держать клиента в состоянии "не пущу на 2.4" по 4-6секунд прежде чем он додумается таки переползти в 5ку.

 

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

 

Для подконтрольной сети, в случае необходимости именно бесшовного и максимально быстрого переключения, я бы разнёс 5GHz и 2.4GHz сети по разным SSID если это возможно, и не использовал бы band steering вовсе рассаживая клиентов в 2.4 или 5ГГц диапазоны административными методами (например с помощью терморектального криптоанализа =) ). Но увы, это не всегда реализуемо с административной точки зрения (как в офисе NAG например).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё один нюанс на многих Android устройствах.

 

Не смотря на то, что wpa_supplicant умеет okc (Opportunistic Key Caching (also known as Proactive Key Caching)) вендоры часто не заморачиваются и не включают поддержку оного в конфиге wpa_supplicant (пример почти все устройства на MTK).

 

На линукс ситуация аналогична, но там можно руками в wpa_supplicant либо глобально включить опцию okc=1 либо для конкретной сети задать proactive_key_caching=1

 

Наверное не надо говорить, что при отключенной опции OKC так же работать не будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При принудительном сбросе при использовании WPA2 Enterprise почти все клиенты переподключаются используя полную фазу соединения как в первый раз. Так что никакие FT или OKC тут уже не помогут. Т.е. принудительный отстрел в режимах с WPA2 Enterprise должен выполнять лишь страховочную роль.

то есть подключение будет дольше, чем с WPA2 PSK?

 

т.е. клиенты сами должны инициировать миграцию если умеют, обычно оно происходит при уровне -75/-85 например на intel7260 при средней и низкой агрессивности роуминга в настойках клиента

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

 

 

Для подконтрольной сети, в случае необходимости именно бесшовного и максимально быстрого переключения, я бы разнёс 5GHz и 2.4GHz сети по разным SSID если это возможно, и не использовал бы band steering вовсе рассаживая клиентов в 2.4 или 5ГГц диапазоны административными методами

не будут ли страдать пользователи 5ГГц? зашёл в угол - сеть потерял.

 

Не смотря на то, что wpa_supplicant умеет okc (Opportunistic Key Caching (also known as Proactive Key Caching)) вендоры часто не заморачиваются и не включают поддержку оного в конфиге wpa_supplicant (пример почти все устройства на MTK).

в общем про быстрое переключение можно забыть )))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 21.03.2017 в 00:17, edo сказал:

то есть подключение будет дольше, чем с WPA2 PSK?

 

Опять таки зависит от клиента, но по моим наблюдениям большинство из них начинают полную фазу от и до без использования кэшированны ключей, т.е. до кучи будет потрачено ещё время для запроса к радиусу и т.д.

 

В 15.03.2017 в 23:03, sfstudio сказал:
да в том-то и дело, что сами клиенты не любят переключаться, норовят держаться за пойманную точку изо всех сил.

 

Я в курсе, как и в курсе что почти половина девайсов вообще сама мигрировать не умеет и будет висеть пока драйвер не дропнет соединение по числу ошибок передачи, т.е. до победного, и даже после этого оно сначала попробует долбануться на АП к которой уже было подключено. Поэтому и грю что при текущем положении дел с подходом в 802.11 к роумингу на 90% всё зависит от клиента и его логики, а она часто убога. Ситуация с ведроидами потихоньку выпраляется т.к. гугл сам начал из коробки добавлять логику включения okc, поддержки FT и т.д. (абы как работает с A 7.1 и далеко не на всех девайсах). Но проблема в том, что нельзя сказать юзайте вот эти ведроиды и вот эти яблоки пользователям. Если сеть подконтрольная в части используемых устройств то это не проблема, в других случаях единственная работающая тактика это выпнуть и не пускать.

 

 

В 20.03.2017 в 12:58, sfstudio сказал:
не будут ли страдать пользователи 5ГГц? зашёл в угол - сеть потерял.

 

Сеть в любом случае должна быть спланирована так что бы было полное покрытие в обоих диапазонах везде. Иначе съехавшего в 2.4 с 5ки в углу клиента потом придётся опять же насиловать band steering`ом не давая подключиться в 2.4 что бы тот перелез назад. Как результат тормоза миграции.

 

Ну и в силу того что в 5ГГц пока тишь да гладь + затухание (а значит и развязка между АП) выше то клиент и при уровне в -85дБ в AC 40МГц получит скорость выше чем на 2.4 в 20МГц при -70. Т.е. в 5ГГц клиента можно держать почти до упора не трогая.

 

А за счёт работы group rate alg (некая форма airtime fairness) группа тормозных клиентов не мешает работе группе быстрых, ну конечно тоже ест эфирное время, но не ставит всё это дело раком.

 

В любом случае всё это компромиссные решения и воркэраунды для логики клиентов.

 

В 20.03.2017 в 13:17, sfstudio сказал:
в общем про быстрое переключение можно забыть )))

 

Ну не забыть. FT-PSK на новых ведроидах на квалкомах с bcm радио (топовые самсы, лыжи) вполне работает, и даже часто сами мигрируют уже при настройке отстрела в пределах -70 в 2.4 с дельтой в 10дБ для 5ГГц, а не ждут пока их снесёт. Да и okc и FT+802.1x тоже на них более-менее шевелиться.

 

И даже вообще без отстрела при грамотном размещении АП эти клиенты зачастую вполне корректно мигрируют внутри диапазона приодинаковых SSID. Но пока это всё же далеко не все клиенты и даже не большая их часть в сети. А значит универсальный метод как был в виде принудительного пинка так и остался.

 

И проблема зачастую не в ускорении фазы аутентификации (PSK и так шустрый, а FT-PSK ещё шустрее, okc и R при 802.1x нужен что бы сократить время на постоянные запросы к радиусу по большому счёту т.к. именно они обычно не быстрые), а в том что клиент залипает и повлиять на это никак кроме как запретить ему ассоциацию и выпнуть что бы пересел на другую АП не моги.

 

Вообще достаточно было в "стандарт" добавить возможность передачи со стороны АП клиенту нескольких опорных параметров типа уровня при котором пытаться совершать миграцию, предпочтительную АП для первой попытке перехода и ещё парочку вещей связанных с preffered band/ap/mdie и т.д + сделать это дело обязательным для реализации для получения лого wifi альянса. Но "почему-то" wifi альянс не ишет простых путей. Отсюда все проблемы. Нет чётких требований как к необходимости реализации, так и к самой реализации в полном объёме + ускорить пытаются частные случаи, в то время когда имеются общие проблемы управления миграцией на стороне клиента.

 

Потому для голоса (при не подконтрольных клиентах) use dect. Иначе хоть золотые АП поставь с супермегаконтроллерами если клиент кривой то будут проблемы. А нормальных клиентов хотя бы не стремящихся залипнуть на одной АП (ну уровень же выше -70 будем висеть нафиг нам мигрировать даже когда выпнули, мы снова попробуем подолбиться на ту же АП, а может она передумает) даже среди современных смартов увы не так много.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Причём надо понимать, что уровень с которым клиент видит АП и по которому принимает решение о миграции, и уровень с которым мы видим его это суть разные вещи (rssi feedback увы так же не стал частью "стандарта")...

btw, не стоит ли зажать уровень на точках? или дефолтные 100% адекватны?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну получите "провисшие" рэйты и как следствие падение ёмкости сети + большее влияние со стороны соседей. В чём профит?

 

AGC сам регулирует уровень, а в роже задаётся макс лимит. Маяки всегда летят на полной мощности - лимит.

 

Ну ослабите вы максимум на 12Дб. И что? Ну кроме того что в реальном эфире это сделает почти невозможным работу на макс рэйтах ибо фонят со всех сторон соседи и далеко не на пониженной мощности. =)

 

Придётся ещё тогда и от N отказаться ибо смысл потеряется. И на кой оно надо? Пусть мощность крутит умный алгоритм, он для того и был придуман.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Потому для голоса (при не подконтрольных клиентах) use dect. Иначе хоть золотые АП поставь с супермегаконтроллерами если клиент кривой то будут проблемы. А нормальных клиентов хотя бы не стремящихся залипнуть на одной АП (ну уровень же выше -70 будем висеть нафиг нам мигрировать даже когда выпнули, мы снова попробуем подолбиться на ту же АП, а может она передумает) даже среди современных смартов увы не так много.

Неа, "золотые" ставить можно: работают нормально(проверенно на видео в реальном времени), но они действительно золотые (Вай-фай с безроуминговыми сетями)....

Но на самом деле это эквивалентно операции по удалению гланд через известное место :)

 

Я пришёл к выводу -- что роуминга в Вай-Фай пока нет, сколько бы костылей на АП не городить...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Неа, "золотые" ставить можно: работают нормально(проверенно на видео в реальном времени), но они действительно золотые (Вай-фай с безроуминговыми сетями)....

Но на самом деле это эквивалентно операции по удалению гланд через известное место :)

 

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

 

Я пришёл к выводу -- что роуминга в Вай-Фай пока нет, сколько бы костылей на АП не городить...

 

Абсолютно верно. Точнее роуминг ради балансировки то есть, но ожидания вида что это будет работать как в том же GSM/DECT и с любыми клиентами не оправдываются от слова совсем. Причины сего (в т.ч.) в этой теме я и пытаюсь донести до желающих роуминга.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
С "золотыми клиентами".

неа, клиенты вообще любые :)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

неа, клиенты вообще любые :)

 

Чудес не бывает. Либо есть миграция и тогда привет всему глюкодрому с клиентами т.к. клиент определяет поведение при роуминге на 99% (именно поэтому почти все рекламные статейки аля строим роуминг на ХХХ гогне внезапно описывают в роли клиентов свежие яблофоны, которые вообще без какой-либо логики со стороны АП в состоянии относительно мягко перескользнуть с одной АП на другую при уровнях -70 на текущей если есть кандидат с дельтой +5Дб, т.е. обеспечивающий уровень -65 и выше, т.е. на клиенте корректно реализован хэндофф включая использование данных фонового сканирования, плюс логика вида заснул на текущей, преаутентифицировался на следующей, если всё удалось проснулся попрощался с текущей и переключился на работу со следующей где уже фазу аутентификации прошёл, вот такой вот "хак"), либо её нет (как в случае описанном ниже, но это уже и близко не роуминг) и тогда ограничены эфирным временем которое внезапно жёстко лимитировано. Остальное всё сказки.

 

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

 

Это аля мираковской реализации когда все АП прикидываются одной и на уровне очередей идёт переключение с какой АП плюнуть данными в клиента? Нет не копал ибо геморроя немеряно, требования к опорной сети и эфиру такие, что нафиг нафиг, ёмкость ограничена тем самым эфирным временем доступным для одной АП.

 

Сиё не решает основной задачи ради которой городят роуминг с мультиточкой.

 

P.S. Кстати wpa_supplicant умеет использовать данные фонового сканирования при миграции, причём сканить его можно заставить только с падением уровня до заданного уровня, достаточно указать в конфиге что-то типа bgscan="simple:30:-50:200", что бы он фоном просканил эфир при падении уровня ниже -50. более того эта фишка является обязательной для быстрой миграции в системах используюзих wpa_supplicant.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Это аля мираковской реализации когда все АП прикидываются одной и на уровне очередей идёт переключение с какой АП плюнуть данными в клиента? Нет не копал ибо геморроя немеряно, требования к опорной сети и эфиру такие, что нафиг нафиг, ёмкость ограничена тем самым эфирным временем доступным для одной АП.

Ага, оно самое :) так называемые "безроуминговые" сети, их несколько реализаций, есть и простые(плохо работающие со множеством ограничений, тот же ZeroHandOff от UniFi) и очень сложные и дорогие(Meru,Extricom)...

Изменено пользователем NewUse

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну вот так и говорите, а то роуминг да с любыми клиентами. Даже более того эти ваши "безроуминговые" сети решают одну задачу и порождают тонны других. Но это выходит за границы обсуждаемого топика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Наконец решил проблему с PSM багой и перевёл поддержку 7620 на новый (3.0.5.0) драйвер. Теперь (начиная с 6.0.x FT доступен для всех устройств). Так же был несколько доработан механизм принудительного спихивания клиента на соседнюю АП.

 

Внимание. Если будете задействовать новый функционал, то потребуется сброс и настройка вручную с нуля. Так же как и при обновлении с фабричного ПО крайне желательно выполнить сброс кнопкой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В том числе. Т.е. теперь работают 802.11K/R на всех девайсах как с WPA(2)-PSK так и в WPA-Enterprise.

 

P.S. FT-PSK всё это давно юзается в 5ГГц в офисе наг, и с месяц как запущено там же в обоих диапазонах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Круто! Осталось найти толкового тестера, который сможет делать адекватные миграции настроек (чтоб обходиться без сброса при задействовании нового функционала) и на оборудование можно будет вешать ярлык Энтерпраиз :), только цену не надо задирать :)

 

Сорри за флуд, но это реально здорово: бюджетное устройство с полноценной(на сколько это вообще возможно реализовать в рамках стандарта + костыли для различных специфических клиентов) поддержкой роуминга...

 

Ждём аутдор-версий, ну или порта под тот же UniFi, если такое возможно(давно не слежу за начинкой)....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Круто! Осталось найти толкового тестера, который сможет делать адекватные миграции настроек (чтоб обходиться без сброса при задействовании нового функционала) и на оборудование можно будет вешать ярлык Энтерпраиз :), только цену не надо задирать :)

 

Энтерпрайз этим не заморачивается. =) Они просто вешают лэйбы.

 

Сорри за флуд, но это реально здорово: бюджетное устройство с полноценной(на сколько это вообще возможно реализовать в рамках стандарта + костыли для различных специфических клиентов) поддержкой роуминга...

 

Не всё так просто, но это ооочень длинная тема. Вкратце полноценней роуминг от поддержки FT не становиться. =) Нужны ещё полноценные клиенты и понимание на кой чёрт вообще всё это надо.

 

Ждём аутдор-версий, ну или порта под тот же UniFi, если такое возможно(давно не слежу за начинкой)....

 

Аутдор может и будет, но пока другие планы. А унифай и прочие в пролёте. Переносить наработки на Atheros = сделать заново (да и не вижу смысла, NAG экслюзивный вендор использующий Wive, зачем я буду их подставлять?). У нас всем занимается драйвер, а мелкие демоны лишь обслуживают то что не критично ко времени исполнения и что может подождать например если проц занят. Остальное всё в драйверах. Думаю не стоит говорить что у большинства остальных всё строго наоборот и почти всё что касается авторизации там вынесено на hostapd. В общем сизифов труд.

 

Тут ещё есть над чем работать в т.ч. по роумингу. Мне понравился подход некоторых GSM-LTE железок в некоторых аспектах миграции, если будет свободное время буду пробовать реализовать. Точнее когда будет.

 

P.S. А по ценам эт не ко мне, но я бы задрал бы процентов на 15, ибо и так работаем по цене аля говнолинк, делая работы тонну, да и скоро уже чую плюну на всё и уйду в "дворники". Нужны ещё люди на разработку, а на них денег нет (с).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти