Jump to content
  • 5
vasek00

2.15.C.1 реализация Band Steering

Question

Вопрос к разрботчикам, скорей всего к Padavan

Суть его в том что в процессе работы над 2.14/2.15 функция "Band Steering" претерпела много изменений и включение поддержки 802.11v BTM а так же наличие клиентов как с 802.11k/r/v так и без них. Возможно ли описать данный процесс более развернуто не так как в 14/02/2019 https://help.keenetic.com/hc/ru/articles/360000849720-Band-Steering где суть метода это отключение клиента от точки доступа при некотором значении rssi.

Можно как то разрозненное описание на данном форуме в разных темах про "Band Steering"/802.11k/r/v и 802.11v BTM как то в компактном виде описать (если с примерами некоторых логов, то было вообще отлично).

 

  • Thanks 2

Share this post


Link to post
Share on other sites

Recommended Posts

  • 0

Попробую проверить работу на релизе 215С100 (KN1810). Клиент смартфон который при разном имени на SSID для 2.4/5 при подключении к 5GHz может k/r/v. Клиент смарт Android 8.1 пере сканирует эфир Wi-fi 6-7секунд т.е. идя с данным клиентом видно как меняется параметры его подключения.

Скрытый текст

[I] Mar 19 12:53:01 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully (FT mode).
[I] Mar 19 12:53:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:53:02 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 12:53:02 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 12:53:02 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 12:53:02 ndhcps: sending ACK of 192.168.130.17 to ....be.
...
[I] Mar 19 12:53:26 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).

 

Настроил роутер SSID одно имя, уменьшил 5GHz до 10% так что в помещении далеко не ходить и найти место для подходящих уровней при которых должно работать.

1. роуминг 802.11r(FT) - выкл., Управление BSS - выкл., Band Steering - по умолчанию

Скрытый текст

В 2м от роутера подключаемся к 5GHz отходим от роутера где клиент перекл. на 2,4 потом возвращаемся к роутеру на первоначальнюю 
точку в 2м. от него. Уровень подключения в 2м. точке 5GHz=-55 2,4GHz=-40/-42.Переключение где-то после уровня на клиенте более -81

Попытка 1
[I] Mar 19 11:30:18 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:30:18 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:30:19 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:30:19 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:30:19 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:30:19 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:30:19 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:30:35 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:30:47 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:31:02 bndstrg: band steering: client ....be is allowed to connect to 2.4GHz band 
[I] Mar 19 11:31:02 bndstrg: band steering: client ....be is NOT allowed to connect to 5GHz band (Low RSSI: -85) 
[I] Mar 19 11:31:17 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:31:29 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:31:29 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:31:40 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:31:47 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:32:47 ndm: Core::Syslog: last message repeated 3 times.
[I] Mar 19 11:32:59 bndstrg: band steering: client ....be is allowed to connect to 5GHz band (Good RSSI: -50) 
[I] Mar 19 11:32:59 bndstrg: band steering: client ....be is NOT allowed to connect to 2.4GHz band

Попытка 2
[I] Mar 19 11:38:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:38:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:38:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:38:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:38:02 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:38:02 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:38:03 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:38:03 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:38:03 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:38:03 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:40:59 ndm: Core::Syslog: last message repeated 9 times.
[I] Mar 19 11:41:04 bndstrg: band steering: client ....be is allowed to connect to 2.4GHz band 
[I] Mar 19 11:41:04 bndstrg: band steering: client ....be is NOT allowed to connect to 5GHz band (Low RSSI: -85) 
[I] Mar 19 11:41:29 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:43:29 ndm: Core::Syslog: last message repeated 4 times.
[I] Mar 19 11:43:44 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:43:44 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:43:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:44:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:44:32 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:44:49 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:44:56 ndm: kernel: fastvpn: bind table cleared

Вывод - при подходе в исходную точку клиент не вернулся на 5GHz

2. роуминг 802.11r(FT) - выкл., Управление BSS - выкл., Band Steering - Предпочтение 5GHz

Скрытый текст

Клиент в исходной точке и подключился к 5GHz сигнал -52 в 2м от роутера, стал удаляться, на 2,4 переключился и
уровень на клиенте -55. Возвращаюсь в исходнуюю точку в 2м от роутера на 5GHz не захотел, на 2,4 тут уровень -40
Переключение помоему происходит ~-75 на клиенте.

Попытка 1
[I] Mar 19 11:47:31 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:47:31 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:47:31 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:47:31 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:47:32 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:47:32 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:47:32 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:47:35 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:48:56 ndm: Core::Syslog: last message repeated 3 times.
[I] Mar 19 11:49:25 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:49:25 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:49:26 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:49:35 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:49:41 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:52:11 ndm: Core::Syslog: last message repeated 5 times.
[I] Mar 19 11:52:26 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:52:32 ndm: kernel: fastvpn: bind table cleared

Попытка 2
[I] Mar 19 11:52:26 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:52:32 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:53:32 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 19 11:53:39 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....bee) had associated successfully.
[I] Mar 19 11:53:39 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:53:40 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:53:40 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:53:40 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:53:40 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:53:40 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:54:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:54:14 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:54:18 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:54:18 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:54:28 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:54:35 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:56:05 ndm: Core::Syslog: last message repeated 3 times.
[I] Mar 19 11:56:25 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:56:32 ndm: kernel: fastvpn: bind table cleared

Вывод - при подходе в исходную точку клиент не вернулся на 5GHz

3. роуминг 802.11r(FT) - выкл., Управление BSS - вкл., Band Steering - по умолчанию

Скрытый текст

Начинаем от роутера 2м. 5GHz при -55, удаляемся переключился моментально, идем обратно у роутера в 2м на 5GHz не хочет, 
2,4 показывает уровень -40/-42

Попытка 1
[I] Mar 19 12:00:31 ndm: Core::Syslog: last message repeated 5 times.
[I] Mar 19 12:00:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 12:00:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:00:56 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 12:00:56 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 12:00:56 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 12:00:56 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:00:56 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 12:00:59 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:01:32 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 19 12:02:01 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 12:02:01 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:02:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:02:12 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 12:02:20 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:04:50 ndm: Core::Syslog: last message repeated 7 times.
[I] Mar 19 12:05:10 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).

Попытка 2, переключение с 5GHz где то после -73 переключился на 2.4GHz

[I] Mar 19 12:06:06 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 12:06:07 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:06:07 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 12:06:07 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 12:06:07 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 12:06:07 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:06:07 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 12:06:17 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:06:47 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 19 12:06:52 bndstrg: band steering: send BTM request to ....be for roam to 2.4GHz band (Low RSSI: -82) 
[W] Mar 19 12:06:52 bndstrg: band steering: WNM client ....be rejected 2.4GHz band (code: 1) 
[I] Mar 19 12:06:52 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 12:06:53 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:07:03 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 12:07:11 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 12:07:11 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had deauthenticated by STA (reason: class 3 error - nonassoc STA).
[I] Mar 19 12:07:11 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:07:47 ndm: Core::Syslog: last message repeated 2 times.

Вывод - при подходе в исходную точку клиент не вернулся на 5GHz

C роуминг 802.11r(FT) - вкл. проверять нет смысла так как были исправления 215С101 и поведение такого клиента k/r/v может на правильно себя повести.

Во всех тестах переключение с 5GHz происходило, но обратно клиент с 2,4GHz на 5GHz не возвращался.

Edited by vasek00
  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0

Если подключаемый клиент в assoc request принес бит поддержки WNM BTM, то Band Steering отделяет таких клиентов в отдельное правило.

Для того чтобы включить поддержу WNM BTM со стороны AP, нужно включить галку "Управление BSS-окружением 802.11k/v", либо CLI команда rrm. Одна команда включает сразу RRM и BTM, поскольку BTM не может работать без RRM. При включенном BTM, AP взводит 1 бит в beacons и probe response/assoc response. Большинство клиентов, видя у AP поддержку BTM, высвечивают со своей стороны бит в assoc request. Есть исключение, некоторые клиенты могут показывать этот бит, даже если на AP не включена BTM. Если клиент приносит бит BTM, он отображается в списке с тегом 11v.

Если клиент приходит с битом WNM BTM, то Band Steering действует так:
- оба бэнда остаются открытыми для него, никаких ограничений. Куда клиент хочет подключиться, туда он и подключается (хоть быстро переходит по FT, хоть 4-way), без каких либо ограничений
- если клиент на 5G бэнде и у него падает уровень RSSI ниже порогового значения, ему отправляется BTM реквест с просьбой перейти на соседний 2.4 бэнд (в BTM реквест помещается Neigh Report c target BSS 2.4). Если клиент решает что это ему подходит, он отвечает кодом 0 и вскоре сам быстро перемещается (особенно быстро по FT). Иногда он решает что это ему не подходит и отвечает любым ненулевым кодом. Причина может быть любая, у Apple своя логика, у Android своя. Android обычно отвечает отказом, только если у него в скан-листе нет этого BSS. Поэтому важно, чтобы оба бэнда были открытыми, чтобы клиент мог рассылать probe и получать ответ. Если клиент ответил отказом, повторять BTM реквесты нет смысла, практика показала что это ничего не дает. Есть другая ситуация - клиент не услышал BTM реквеста, поэтому если ответа не пришло за 4000мс, то выполняется повтор BTM реквеста до 3 раз.
- если клиент сидит на 2.4G бэнде и в течении 10 секунд уровень от него выше нормы (+ небольшой запас), и если с последнего переключения прошло более 50 секунд, то ему генерится BTM реквест с просьбой перейти на соседний 5G бэнд. Без насилия.
- независимо что ответил клиент в BTM response, клиент c поддержкой 11v (либо 11r) никогда не будет отстрелен принудительно.

11v - отличный инструмент, поэтому Band Steering его использует элегантно, без принуждения. Если на клиенте логика 11v не совсем мертвая, он никогда не уйдет с нашей AP (в пользу мобильного 3G/4G), независимо сколько раз его будут вежливо просить о переходе.

---

Если клиент приходит без поддержки WNM BTM, то Band Steering использует второе правило и оно немного отличается от того (единственного правила) что было ранее:
- вновь прибывшему клиенту (время протухания клиента в BS списке = 90 секунд отсутствия), сейчас открыты оба бэнда, поэтому клиент подключается на свое усмотрение
- если клиент сейчас сидит на 5G бэнде и у него падает уровень RSSI ниже порогового значения, то ему применяется событие OP_STEERED, после которого 5G бэнд блокируется (не выдается ответ на probe request/auth request), тем самым ему мотивируется уход с данного бэнда (других штатных механизмов влияния нет), а если в BS preference выбрано значение не Default, то клиент принудительно отстреливается. Дальнейшее его поведение неконтролируемо. Он может совсем уйти (например на 3G/4G или вообще на другую AP). На это повлиять со стороны AP невозможно.
- если клиент сейчас сидит на 2.4G бэнде и в течении 10 секунд уровень от него выше нормы (+ небольшой запас), и если с последнего переключения прошло более 50 секунд (180 для iOS), то ему применяется событие OP_STEERED, далее все как в пункте 5G

iOS обычно заявляет поддержку FT (11r), поэтому отстрел не выполняется. Но правило переключается все равное не ранее 180 секунд, так как iOS имеет механизм бана, если ее нагнали чаще этого интервала, она заносит BSSID в бан-лист и больше к нему не подключится автоматически (только по тапу вручную).

Ранее, все клиенты получали семафор по логике открытия бэнда. Т.е. если клиент в probe/auth/assoc request приносил хороший уровень, то ему сразу перекрывался бэнд 2.4G и открывался 5G. К сожалению эта логика очень плохо работает с тупыми клиентами, не имеющих handover логики. Они начинают долбиться в 2.4 и не хотят подключатсья к 5. В итоге такие клиенты либо совсем не подключаются, либо с очень большой задержкой. Что сильно снижает юзабилити.

 

 

  • Thanks 5

Share this post


Link to post
Share on other sites
  • 0

@Padavan А при активации MWS возможна рекомендация BTM роутером А перейти на точку доступа расположенную на роутере Б? Или все реквесты только в рамках одного роутера?

ЗЫ Еще интересны текущие настройки порогов для генерации реквестов. 

Share this post


Link to post
Share on other sites
  • 0

Нет, Band Steering работает только внутри одного устройства, т.е .не выполняет функции Load Balancing между разными физическими AP.

При этом механизм 11v можно применять именно для Load Balancing, т.е. гонять клиентов между разными AP. Например, у Cisco контроллеров 11v используется именно для этой цели.

  • Thanks 4

Share this post


Link to post
Share on other sites
  • 0
1 час назад, Padavan сказал:

Ранее, все клиенты получали семафор по логике открытия бэнда. Т.е. если клиент в probe/auth/assoc request приносил хороший уровень, то ему сразу перекрывался бэнд 2.4G и открывался 5G

Можно реализовать опционально?

Share this post


Link to post
Share on other sites
  • 0

@Padavan не могли бы вы описать, как работает роуминг при такой настройке:

80211.thumb.png.55537147cc4ccd962c57dc27ae82d1bd.png

BTS это, согласно вашим постам выше, вспомогательный механизм Band Steering для клиентов с поддержкой 11k/v, который мягко помогает им определиться с бэндом. Но если BS полностью отключен, как на скриншоте выше, то как в этом случае работает включенный BTS?

Share this post


Link to post
Share on other sites
  • 2

А нельзя добавить клиентам k/v при нахождении в 2,4 Ghz и его видимости в 5Ghz хотя бы раз в несколько минут дополнительно подавать BTM реквест с просьбой перейти на 5G бэнд ?

Вот сейчас обновил KN-1010 до 2.15С2-2 и после перегрузки оба смарта повисли в 2,4 Ghz.

Реквесты на 5 Ghz судя по логам и не шлются... Хотя они в 3-х метрах от роутера.

Если передернуть на них wifi - сразу уходят в 5-ку.

Клиенты - Android 9.

 

  • Upvote 1

Share this post


Link to post
Share on other sites
  • 0
10 часов назад, Sergey Zozulya сказал:

не могли бы вы описать, как работает роуминг при такой настройке: 

80211.thumb.png.55537147cc4ccd962c57dc27ae82d1bd.png

BTS это, согласно вашим постам выше, вспомогательный механизм Band Steering для клиентов с поддержкой 11k/v, который мягко помогает им определиться с бэндом. Но если BS полностью отключен, как на скриншоте выше, то как в этом случае работает включенный BTS?

В 5GHz с моим клиентом при проверке работает ОК. Пост открыть по стрелке.

 

Edited by vasek00

Share this post


Link to post
Share on other sites
  • 1

Заметил, что на версии 2.15 телевизор LG (на кухне) перестал автоматом на 5GHz подключаться, только если 2,4GHz выключить, тогда переходит на 5GHz, в комнате так же LG и тоже древний, но такой проблемы нет.

Ниже селф, в момент выключения и включения проблемного зомбоящика

Edited by m__a__l
  • Upvote 1

Share this post


Link to post
Share on other sites
  • 0
В 19.03.2019 в 17:14, Padavan сказал:

- если клиент сейчас сидит на 2.4G бэнде и в течении 10 секунд уровень от него выше нормы (+ небольшой запас), и если с последнего переключения прошло более 50 секунд (180 для iOS), то ему применяется событие OP_STEERED, далее все как в пункте 5G

 

 

Обратил внимание, что ряд клиентов, например Apple и Samsung, при перемещении в уверенную зону покрытия 5 ГГц так и остаются висеть в 2,4. 

Keenetic при этом выполняет всего один BTM request for roam to 5GHz band, клиент отвечает accepted, однако перехода после этого не следует.

Более от Keenetic таких запросов к клиенту не выполняется, а клиент может часами оставаться в 2.4. 

Нормальное ли это поведение? Возможно стоит повторять данный запрос к клиенту с определенной периодичностью, скажем раз в 10 минут, если клиент так и не перешел в 5 ГГц?

Share this post


Link to post
Share on other sites
  • 0
55 минут назад, pigovina сказал:

Обратил внимание, что ряд клиентов, например Apple и Samsung, при перемещении в уверенную зону покрытия 5 ГГц так и остаются висеть в 2,4. 

Keenetic при этом выполняет всего один BTM request for roam to 5GHz band, клиент отвечает accepted, однако перехода после этого не следует.

Более от Keenetic таких запросов к клиенту не выполняется, а клиент может часами оставаться в 2.4. 

Нормальное ли это поведение? Возможно стоит повторять данный запрос к клиенту с определенной периодичностью, скажем раз в 10 минут, если клиент так и не перешел в 5 ГГц? 

Если у вас Sams то легко проверить., Открыть разработчика и сделать настройки для Wi-fi сети -> в итоге будете видеть уровень приема. Теперь имея такие данные постарайтесь определиться с данными уровнями в тех местах где считаете что клиенте должен переключиться.

Без имени-2.jpg

Без имени-1.jpg

Share this post


Link to post
Share on other sites
  • 0

Телефон в 2 метрах от Keenetic.

В 10:00 телефон оказался в уверенной зоне покрытия 5 ГГц и Кинетик предложил ему переход в 5 ГГц, на который телефон ответил согласием, однако переход так и не совершил.

Более никаких событий по логам не происходило, спустя 3 часа телефон остается в 2.4 ГГц.

Apr  4 10:00:18 bndstrg: band steering: send BTM request to 04:d6:aa:8c:xx:xx for roam to 5GHz band 
Apr  4 10:00:18 bndstrg: band steering: WNM client 04:d6:aa:8c:xx:xx accepted 5GHz band 

 

sams_wf.jpg.213b8ce73d3510341e681d1d795a6fc6.jpg

Edited by pigovina

Share this post


Link to post
Share on other sites
  • 0
1 час назад, pigovina сказал:

Телефон в 2 метрах от Keenetic.

В 10:00 телефон оказался в уверенной зоне покрытия 5 ГГц и Кинетик предложил ему переход в 5 ГГц, на который телефон ответил согласием, однако переход так и не совершил.

Более никаких событий по логам не происходило, спустя 3 часа телефон остается в 2.4 ГГц.

Apr  4 10:00:18 bndstrg: band steering: send BTM request to 04:d6:aa:8c:xx:xx for roam to 5GHz band 
Apr  4 10:00:18 bndstrg: band steering: WNM client 04:d6:aa:8c:xx:xx accepted 5GHz band 

Я проверял на Sams Android 8.1 с релизом 2.15С получилось увидеть только после установки 10% на Wi-Fi и все получилось, но так как в настоящие время интересен роуминг 5GHz то данный вариант уже не проверялся. Если будет время то попробую опять проверить BS 5<->2.4<->5.

Вы можете попробовать с уменьшения уровня rssi т.е. уменьшите на хх% так чтоб уровни были в -58-60 для обоих 5/2.4 в стартовой точке, потом просто походите и найдите вторую точку (за двумя стенками например в дальнем углу) где будет переход с 5 на 2.4, а потом обратно к роутеру. Так же проверьте настройки свои с учетом что Sams (ваш наверное тоже) поддерживает /k/v/r :

Скрытый текст

Если клиент приходит с битом WNM BTM, то Band Steering действует так:

....

- если клиент сидит на 2.4G бэнде и в течении 10 секунд уровень от него выше нормы (+ небольшой запас), и если с последнего переключения прошло более 50 секунд, то ему генерится BTM реквест с просьбой перейти на соседний 5G бэнд. Без насилия.
- независимо что ответил клиент в BTM response, клиент c поддержкой 11v (либо 11r) никогда не будет отстрелен принудительно. 

Если клиент приходит без поддержки WNM BTM, то Band Steering использует второе правило и оно немного отличается от того (единственного правила) что было ранее:
...
- если клиент сейчас сидит на 5G бэнде и у него падает уровень RSSI ниже порогового значения, то ему применяется событие OP_STEERED, после которого 5G бэнд блокируется (не выдается ответ на probe request/auth request), тем самым ему мотивируется уход с данного бэнда (других штатных механизмов влияния нет), а если в BS preference выбрано значение не Default, то клиент принудительно отстреливается. Дальнейшее его поведение неконтролируемо. Он может совсем уйти (например на 3G/4G или вообще на другую AP). На это повлиять со стороны AP невозможно.
- если клиент сейчас сидит на 2.4G бэнде и в течении 10 секунд уровень от него выше нормы (+ небольшой запас), и если с последнего переключения прошло более 50 секунд (180 для iOS), то ему применяется событие OP_STEERED, далее все как в пункте 5G

 

Ранее, все клиенты получали семафор по логике открытия бэнда. Т.е. если клиент в probe/auth/assoc request приносил хороший уровень, то ему сразу перекрывался бэнд 2.4G и открывался 5G. К сожалению эта логика очень плохо работает с тупыми клиентами, не имеющих handover логики. Они начинают долбиться в 2.4 и не хотят подключатсья к 5. В итоге такие клиенты либо совсем не подключаются, либо с очень большой задержкой. Что сильно снижает юзабилити.

 

Это было описано см.выше

 

И так же = "Handover — процедура миграции между точками доступа, инициируемая и осуществляемая клиентом исходя из определённых (одному ему известных), не регламентированных стандартом критериев."

Так же можно еще попробовать для Android - https://play.google.com/store/apps/details?id=de.resolution.wififixer&hl=ru root не нужен, хотя у меня проверял BS без нее.

Скрытый текст

Многие смартфоны Android (в частности популярная высококлассная модель Samsung Galaxy S7/S8) не способны обеспечивать стабильное Wi-Fi-соединение при наличии нескольких точек доступа под одним SSID. Они не переключаются между точками доступа (ТД) по мере вашего перемещения по зоне покрытия, подключение к новой ТД происходит только тогда, когда исчезает соединение с предыдущей. Иногда, даже если вы не перемещаетесь, ваш телефон может пытаться подключиться к ТД со слабым сигналом, в таком случае вы не получаете push-уведомления и расход вашего аккумулятора увеличивается в связи с необходимостью постоянного переподключения. О данных проблемах известно уже в течение нескольких лет, но производители мобильных устройств ничего не предпринимают. (ОС Android не является источником проблемы.)

Приложение WifiFixer (Wi-Fi-отладка) периодически проверяет силу сигнала текущей точки доступа. Если сигнал ослаб, будет произведено сканирование других точек доступа с такими же параметрами (т. е. таким же SSID). При наличии лучших опций, телефон плавно перейдет к другой ТД. В отличие от обычной ситуации, телефон не будет прерывать и через несколько секунд восстанавливать Wi-Fi-соединение (из-за чего происходит сбой в работе приложений).

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

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

Если вам не совсем ясно, зачем приложению необходим доступ к вашему местоположению: ОС Android не позволяет приложениям сканировать Wi-Fi-сети, если у них нет доступа к вашему местоположению, очевидно, потому что разработчики Google считают, что все, как и они, рассматривают точки доступа как маячки для определения местоположения. Мы не храним данные о вашем местоположении и никуда их не передаем.

 

Edited by vasek00

Share this post


Link to post
Share on other sites
  • 1

Из 5 ГГц в 2.4 переключается без проблем, а вот обратно в пятерку, зачастую, устройства не возвращаются.

Я прекрасно понимаю, что решение о переходе принимает сам клиент, вопрос в том, нормально ли поведение keenetic, при котором он только 1 раз предлагает устройству переход в пятерку.

Share this post


Link to post
Share on other sites
  • 0
29 minutes ago, pigovina said:

только 1 раз предлагает устройству переход в пятерку

Клиент ведь ответил утвердительно, поэтому и попытки прекращаются.

Share this post


Link to post
Share on other sites
  • 0
37 минут назад, Sergey Zozulya сказал:

Клиент ведь ответил утвердительно, поэтому и попытки прекращаются.

Тут не поспоришь, логика верная, только результат не достигнут.

По этому и хотелось бы понять, возможно имеет смысл проводить проверку, перешел ли по факту клиент в 5 ГГц и если нет, продолжать отправлять ему BTM request for roam to 5GHz band, до того момента, пока клиент не перейдет.

 

  • Thanks 3

Share this post


Link to post
Share on other sites
  • 1

@pigovina соглашусь с вами. Даже если клиент намеренно отказался от предложения, имеет смысл через какое-то время снова ему предложить более выгодный бэнд (согласно настроек предпочтения BS). В примере ниже клиент по каким-то причинам отказался переходить на 5 GHz, хотя был совсем рядом с ТД. При этом он больше не совершал никаких попыток в дальнейшем перейти на 5 GHz, оставаясь в менее выгодном диапазоне.

BTM.thumb.png.34abde2c7262a835f7777be2bae1cf17.png

@Padavan какой алгоритм для таких клиентов (которые либо согласились, но не перешли, либо не согласились и потом не даже пытаются)? Будут ли им повторные предложения от BTM? Или они так и остаются на своем бэнде до наступления каких-то условий? Если да, то какие это должны быть условия?

UPD: дополню, что клиент сменил бэнд на 5 GHz только во время автоматической смены канала на 2.4 GHz диапазоне. Т. е. если бы не автосмена канала, он так бы и сидел на 2.4 GHz до следующего реконнекта к ТД.

Ch_Ch.thumb.png.c4a558798970ddd9f2657633d02c6b96.png

Edited by Sergey Zozulya
UPD
  • Thanks 2

Share this post


Link to post
Share on other sites
  • 0

Попробовал BS на релизе 3А103 только роутер KN1810 (не большая ремарка на нем есть Beamforming для 2.4/5 в режиме по умолчанию "beamforming explicit"). Напомню - iBF не требует поддержки от клиента, eBF - требует. Клиент Sams если верить datasheet на нем стоит BCM43455HKUBG который "Supports explicit IEEE 802.11ac transmit beamforming", согласно интернету это дает примерно 3dB, т.е. при перемещение клиента происходит "формирование луча" для него, так помещение в котором опробование ограничено и rssi в нем 2.4/5 приблизительно были равны (трудно было найти место с разницей в 10 между 2.4 и 5. Так же клиент может k/v/r, есть одна точка в которой как-бы стабильно переключение на 2.4 с 5. И опять же

Цитата

- независимо что ответил клиент в BTM response, клиент c поддержкой 11v (либо 11r) никогда не будет отстрелен принудительно.

 

Скрытый текст

BS включен и настроен, 2.4/5 дают 10%.

Проба 1

Роуминг 802.11r (FT) выключен, Управление BSS-окружением 802.11k/v включено, BS предпочитать 5GHz. Начинал с 5Ghz потом пару раз на кухни переключался на 2.4<->5


[I] Apr  5 08:04:13 ndm: Core::ConfigurationSaver: configuration saved.
[I] Apr  5 08:04:15 bndstrg: band steering: enabled
[I] Apr  5 08:04:40 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(......:be) had associated successfully.
[I] Apr  5 08:04:41 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(......:be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:04:41 ndhcps: DHCPDISCOVER received  from ......:be.
[I] Apr  5 08:04:41 ndhcps: making OFFER of 192.168.130.17 to ......:be.
[I] Apr  5 08:04:41 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ......:be.
[I] Apr  5 08:04:41 ndhcps: sending ACK of 192.168.130.17 to ......:be.
[I] Apr  5 08:07:13 bndstrg: band steering: send BTM request to ......:be for roam to 2.4GHz band (Low RSSI: -88)
[I] Apr  5 08:07:13 bndstrg: band steering: WNM client 94:7b:e7:29:c4:be accepted 2.4GHz band
[I] Apr  5 08:07:30 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(......:be) had re-associated successfully.
[I] Apr  5 08:07:30 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(......:be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:07:41 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(......:be) had been aged-out and disassociated (idle silence).
[I] Apr  5 08:09:17 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(......:be) had re-associated successfully.
[I] Apr  5 08:09:17 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(......:be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:09:28 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(......:be) had been aged-out and disassociated (idle silence).
[I] Apr  5 08:10:48 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(......:be) had re-associated successfully.
[I] Apr  5 08:10:48 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(......:be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:13:02 bndstrg: band steering: send BTM request to ......:be for roam to 5GHz band
[I] Apr  5 08:13:02 bndstrg: band steering: WNM client ......:be accepted 5GHz band
[I] Apr  5 08:19:09 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(......:be) had been aged-out and disassociated (idle silence).
[I] Apr  5 08:22:06 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(......:be) had disassociated by STA (reason: STA is leaving or has left BSS).

Начало с 5GHz потом видно в какой то удаленной точке клиенте переключился на 2.4 потом на 5 и опять на 2.4. Вернулся в точку старта было предложено клиенту перейти на 5GHz но он не захотел.

Как говорил выше разницы rssi 2.4 и 5 практически нет, правда нашел место с rss разницей 10 не далеко от роутера (иногда) но стоять 5мин. не выдержал, возврата на 5GHz не было.

Проба 2

Роуминг 802.11r (FT) выключен, Управление BSS-окружением 802.11k/v включено, BS по умолчанию.


[I] Apr  5 08:28:41 bndstrg: band steering: enabled 
[I] Apr  5 08:30:01 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(.....be) had associated successfully.
[I] Apr  5 08:30:01 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(.....be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:30:01 ndhcps: DHCPDISCOVER received  from .....be.
[I] Apr  5 08:30:01 ndhcps: making OFFER of 192.168.130.17 to .....be.
[I] Apr  5 08:30:01 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from .....be.
[I] Apr  5 08:30:02 ndhcps: sending ACK of 192.168.130.17 to .....be.
[I] Apr  5 08:31:06 bndstrg: band steering: send BTM request to .....be for roam to 2.4GHz band (Low RSSI: -85) 
[W] Apr  5 08:31:06 bndstrg: band steering: WNM client .....be rejected 2.4GHz band (code: 1) 
[I] Apr  5 08:33:16 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(.....be) had re-associated successfully.
[I] Apr  5 08:33:16 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(.....be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:33:27 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(.....be) had been aged-out and disassociated (idle silence).
[I] Apr  5 08:35:52 bndstrg: band steering: send BTM request to .....be for roam to 5GHz band 
[I] Apr  5 08:35:52 bndstrg: band steering: WNM client .....be accepted 5GHz band 
[I] Apr  5 08:37:46 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(.....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Apr  5 08:37:46 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(.....be) had deauthenticated by STA (reason: class 3 error - nonassoc STA).

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

Проба 3

Роуминг 802.11r (FT) включен для 2.4/5, Совместимость с FT включена, Управление BSS-окружением 802.11k/v включено, BS по 5GHz


[I] Apr  5 08:44:18 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(.....be) had associated successfully.
[I] Apr  5 08:44:18 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(.....be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:44:18 ndhcps: DHCPDISCOVER received  from .....be.
[I] Apr  5 08:44:18 ndhcps: making OFFER of 192.168.130.17 to .....be.
[I] Apr  5 08:44:18 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from .....be.
[I] Apr  5 08:44:19 ndhcps: sending ACK of 192.168.130.17 to .....be.
[I] Apr  5 08:47:28 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(.....be) had re-associated successfully.
[I] Apr  5 08:47:28 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(.....be) had deauthenticated by AP (reason: STA is leaving or has left BSS).
[I] Apr  5 08:47:28 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(.....be) set key done in WPA2/WPA2PSK.
[I] Apr  5 08:49:59 bndstrg: band steering: send BTM request to .....be for roam to 5GHz band 
[I] Apr  5 08:49:59 bndstrg: band steering: WNM client .....be accepted 5GHz band 
[I] Apr  5 08:54:00 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(.....be) had disassociated by STA (reason: STA is leaving or has left BSS).

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

Еще раз убеждаюсь что клиент как говориться "хозяин-барин". Из всех проб что сегодня и были ранее на данном клиенте только один раз на 2.15 при применении BS был достигнут результат 5->2.4->5.

Личное мнение если использовать 5GHz для клиентов и даже в сильно удаленных местах то лучше использовать роуминг в 5GHz базе двух роутеров (например в связке KN19/10+K15/16/17) клиентов 2.4 оставить только на 2.4. Пока 5GHz чист.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
В 25.03.2019 в 21:39, m__a__l сказал:

Заметил, что на версии 2.15 телевизор LG (на кухне) перестал автоматом на 5GHz подключаться, только если 2,4GHz выключить, тогда переходит на 5GHz, в комнате так же LG и тоже древний, но такой проблемы нет.

Ниже селф, в момент выключения и включения проблемного зомбоящика

Спасибо за обновление, на версии 2.15.C.3.0-2 решилась проблема с ТВ от LG и он теперь постоянно цепляется на 5GHz

Share this post


Link to post
Share on other sites
  • 0
28 минут назад, m__a__l сказал:

Спасибо за обновление, на версии 2.15.C.3.0-2 решилась проблема с ТВ от LG и он теперь постоянно цепляется на 5GHz

Что у вас за ТВ такой что сам выбирает к какой сети ему подключаться. У меня оба Самсунга настроены только на 5ГГц и никогда  на 2,4 не перепрыгивают по причине того что она и не настраивалась на них. Хотя оба сеть 2,4 видят.

Я у себя не только ТВ, но и все устройства умеющие 5ГГц (планшет, смартфон) принудительно перевёл на эту сеть.

Edited by Fandor

Share this post


Link to post
Share on other sites
  • 0
8 часов назад, Fandor сказал:

Что у вас за ТВ такой что сам выбирает к какой сети ему подключаться. У меня оба Самсунга настроены только на 5ГГц и никогда  на 2,4 не перепрыгивают по причине того что она и не настраивалась на них. Хотя оба сеть 2,4 видят.

Я у себя не только ТВ, но и все устройства умеющие 5ГГц (планшет, смартфон) принудительно перевёл на эту сеть.

Сеть то одинакого называется и пароль одинаковый, почему бы устройствам и не выбирать сеть самим так сказать?

Я поэтому и оставил комментарий именно в теме про «Band Steering».

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

  • Upvote 2

Share this post


Link to post
Share on other sites
  • 0
В 18.04.2019 в 21:40, m__a__l сказал:

Спасибо за обновление, на версии 2.15.C.3.0-2 решилась проблема с ТВ от LG и он теперь постоянно цепляется на 5GHz

Поторопился я с радостью, что ТВ от LG стал на 5 GHz постоянно цепляться, похоже это просто так звезды пару раз сошлись. 

Снова цепляется на 2,4GHz хотя iPad mini самого первого поколения находясь на большем удалении цепляются на 5GHz. 

Share this post


Link to post
Share on other sites
  • 0
51 минуту назад, m__a__l сказал:

Поторопился я с радостью, что ТВ от LG стал на 5 GHz постоянно цепляться, похоже это просто так звезды пару раз сошлись. 

Снова цепляется на 2,4GHz хотя iPad mini самого первого поколения находясь на большем удалении цепляются на 5GHz. 

Для таких случаев(стационарная техника) я считаю предпочтительнее выделять отдельную точку доступа без всяких BS.

Чтобы цеплялся строго к ней. BS это для мобильной техники.

Кинетик позволяет поднять до 4х точек на диапазон.

  • Upvote 1

Share this post


Link to post
Share on other sites
  • 0
8 часов назад, r13 сказал:

Для таких случаев(стационарная техника) я считаю предпочтительнее выделять отдельную точку доступа без всяких BS.

Чтобы цеплялся строго к ней. BS это для мобильной техники.

Кинетик позволяет поднять до 4х точек на диапазон.

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

Вдруг добрые соседи специально рядом повтыкают 5GHz на этой же частоте, а железка им скажет иди те нахер и сама скинет устройства на 2,4GHz

Share this post


Link to post
Share on other sites
  • 0
41 минуту назад, m__a__l сказал:

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

Вдруг добрые соседи специально рядом повтыкают 5GHz на этой же частоте, а железка им скажет иди те нахер и сама скинет устройства на 2,4GHz

Будем решать проблемы по мере их появления, пока каких либо проблем с перенаселением в 5ке нет, а из-за низкой проникающей способности вряд ли и появятся 🙂

Share this post


Link to post
Share on other sites
  • 0
14 часа назад, r13 сказал:

Для таких случаев(стационарная техника) я считаю предпочтительнее выделять отдельную точку доступа без всяких BS.

В условиях работающей wifi-системы, получается так, что новый сегмент расползается по ТД. И даже без всякого роуминга, телевизор или телеприставка внезапно может самостоятельно решить переключиться хрен знает куда - так решил вот клиент. И остаётся или wifi-систему разбирать, чтобы нужный SSID висел только на конкретной ТД, или вот просить доработать wifi-систему, чтобы на контроллере можно было явно указать, какой сегмент рассылать по всем подчинённым точкам, а какой оставить только в конкретном месте

  • Upvote 1

Share this post


Link to post
Share on other sites
  • 0

Всем привет.

Вопрос касательно управления band-steering через cli: включать и выключать BS можно на любом WiFiMaster, как в таком случае отрабатвается системой множественное включение? Например, band-steering включен и на WiFiMaster0, и на WiFiMaster. А если еще задать band-steering preference по-разному на них (preference 5 на WiFiMaster1 и preference 2 на WiFiMaster0, и наоборот, т.е. так, что бы совсем конфликтно было)?

Спасибо.

Share this post


Link to post
Share on other sites
  • 0
 
 
 
8 часов назад, dpokrovsky сказал:

Вопрос касательно управления band-steering через cli: включать и выключать BS можно на любом WiFiMaster, как в таком случае отрабатвается системой множественное включение? Например, band-steering включен и на WiFiMaster0, и на WiFiMaster. А если еще задать band-steering preference по-разному на них (preference 5 на WiFiMaster1 и preference 2 на WiFiMaster0, и наоборот, т.е. так, что бы совсем конфликтно было)?

Во-первых, band-steering сейчас работает только на сегменте Home.

Во-вторых, для работы band-steering нужно соблюдение следующих условий:

  • band-steering на WifiMaster0 и 1 включен
  • интерфейсы WifiMaster0 и 1, и соответствующие AccessPoint0 включены (up)
  • SSID на обоих диапазонах одинаковые, не пустые, и не скрыты
  • параметры безопасности Wi-Fi на обоих диапазонах одинаковые

В-третьих, команда band-steering preference доступна только на WifiMaster1, поэтому по-разному задать её нельзя.

Share this post


Link to post
Share on other sites
  • 0
15 часов назад, ndm сказал:

и не скрыты

Т.е. при скрытом SSID - Band Steering не работает? Если это так, то не плохо бы подсказку в интерфейсе при включении скрытия SSID :(

Share this post


Link to post
Share on other sites
  • 0

ndm, спасибо! Про отсутсвие поддержки hidden ssid в band steering действительно неочевидно: ни в описании CLI, ни в UI на это не указано, может имеет смысл добавить?

Еще вопрос: имеет ли смысл снижать мощность на WifiMaster0 до 25% (на 6 дБ) для выравнивания диапазонов при включенном стиринге? Ну как универсальное правило.

С уважением.

  • Upvote 1

Share this post


Link to post
Share on other sites

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.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...