t800

5.1beta2 быть может?

Это при том, как я понимаю, что указанная проблема в 5.0.11 как бы устранена

Команда в CLI же отработает, наверное. Вопрос в том, что конкретно в итоге будет на экстендеры передано и как на контроллере активируется (и активируется ли). Как бы там ни было, 5.1b2 мы-то и не видели пока, речь вообще про b1

Контроллер - KN-1010 5.1b1 Два экстендера - KN-1711 (5.0.6), KN-1710 (4.3.6.2) Настройки контроллера: interface Bridge0 rename Home description "Home network" include GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G mac address factory lan mac access-list type none security-level private ip address 192.168.50.1 255.255.255.0 ip dhcp client dns-routes ip access-group _WEBADMIN_Bridge0 in igmp downstream no band-steering iapp key ns3 xxx up ! ... mws wlan Home encryption wpa2 band 0 wpa psk ns3 yyy bind Home ssid name DDZ wps enable rrm enable ft mdid 10 ft enable ft iapp key ns3 zzz enable ! mws wlan wlan0 encryption wpa2 band 1 wpa psk ns3 yyy bind Home ssid name DDZ5 wps enable rrm enable ft mdid 11 ft enable ft iapp key ns3 zzz enable ! Настройки экстендеров: interface Bridge0 rename Home description "Home network" include FastEthernet0/Vlan1 include AccessPoint include AccessPoint_5G mac address factory lan mac access-list type none security-level private ip address 192.168.1.3 255.255.255.0 ip address dhcp ip dhcp client fallback static ip dhcp client dns-routes ipv6 address auto ipv6 name-servers no band-steering iapp key ns3 yyy up mws wlan, понятно, на экстендерах нет. Собственно, вопрос - ft mdid там выставлены на точках доступа корректно (10 и 11), но iapp key там же один общий, он на Bridge0. В моём случае ключ одинаковый везде. А если бы я его сделал для разных диапазонов разным в mws vlan? Где и какой ключ в итоге бы оказался? И вопрос со звёздочкой - а что такое ip address 192.168.1.3 на экстендерах, если даже подсеть в сегменте другая?

А вот такой вариант поясните, пожалуйста: как будет отрабатывать ситуация, если для band 0 настроен 10 домен, а для band 1 настроен 11 домен? Старые экстендеры, как я понимаю, могут работать только с одним доменом от BridgeX

Скажите, а как будет обеспечена совместимость со "старыми" экстендерами, работающими на 5.0.* или 4.*?

Понял. Ну, на Bridge0 я ничего не менял, поэтому буду считать, что работают именно те параметры, которые заданы в mws wlan. Осталось понять, как это проверить. Видимо, только по логу wifi-системы, искать "быстрые" переходы.

То есть, вне зависимости от того, что прописано в mws wlan, фактически используется ключ iapp key из Bridge0? В моём понимании доминировать должна нижестоящая, "уточняющая" настройка. Ведь у меня ДВЕ РАЗНЫЕ точки доступа, с разными мобильными доменами. Так почему доминирует общий ключ, да еще и доступный только из CLI?

Прошу прощения за дотошность, я пытаюсь досконально разобраться. Смотрите, у меня в Bridge0 точки 2.4 и 5 имеют разные ssid и разные настройки. Соответственно, есть две секции mws wlan - Home и wlan0. Параметры ft mdid и ft iapp key - разные для Home и для wlan0. Это может конфликтовать с iapp key на уровне Bridge0? Или ft iapp key имеет преимущество?

Но тут вопрос скорее про конфликт. ft iapp key в mws wlan отличаются от iapp key на бридже. Номера доменов на 2.4 и 5 точках разные. Что в итоге работает?

@KoneTaH Ну и вдогонку опять: Interface Bridge0 -> iapp key Этот параметр какую играет роль, если есть отдельные ft iapp key в секциях mws wlan X

ОК, спасибо за разъяснения, но тогда вот этот момент поясните: Названия секций несут смысловую нагрузку? Или они могут быть произвольными? Home явно взят из Bridge0: interface Bridge0 rename Home description "Home network" include GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G mac address factory lan mac access-list type none security-level private ip address 192.168.50.1 255.255.255.0 ip dhcp client dns-routes ip access-group _WEBADMIN_Bridge0 in igmp downstream no band-steering iapp key ns3 ххх up Но у меня в этом сегменте как раз две точки доступа, которые имеют раздельные настройки FT (Home и wlan0 по CLI). Связанность конфигураций в данном случае никак не страдает?

Вдогонку: (config)> mws wlan Home Mws::Wlan::Manager: WLAN "Home" already exists. По идее, вход в секцию настроек не должен формировать такое уведомление

Признаться, это всё сильно запутывает. Вы правы, после того, как я убрал ft skip-band 1, то в interface WifiMaster1/AccessPoint0 появился ft enable. Как говорится, у меня есть вопросы. Зачем вообще дублируется "ft enable" внутри AccessPoint и mws wlan? Разве недостаточно сделать связанность этих блоков через ssid и band? Хотя, как по мне, и такая связь - неверная, тут нужен некий внутренний индекс той точки доступа, к которой привязывается настройка FT. Как-то тут это выглядит сырым и архитектурно не продуманным. Например, для ситуации с несколькими точками доступа в одном диапазоне.

В приведённом варианте конфигурации ft активен в итоге на обоих диапазонах? Если я верно вас понял, то на 2.4 должен быть skip-band 1, а на 5 - skip-band 0, так?

Попробовал workaround с удалением mws wlan и загрузкой startup-config для для конфигурации с двумя точками доступа разных диапазонов в одном сегменте. Это помогло - WebUI стал отображать обе точки доступа, а в CLI теперь вот такая конструкция: mws wlan Home encryption wpa2 band 0 wpa psk ns3 xxx bind Home ssid name DDZ wps enable rrm enable ft mdid 10 ft enable ft skip-band 0 ft iapp key ns3 yyy enable ! mws wlan wlan0 encryption wpa2 band 1 wpa psk ns3 xxx bind Home ssid name DDZ5 wps enable rrm enable ft mdid 11 ft enable ft skip-band 1 ft iapp key ns3 yyy enable ! То есть, настройки mws ожидаемо раздельные, но есть один не вполне понятный момент. Если band Х - это указание диапазона, для которого активна данная конфигурация, то как понять ft skip-band 1? Для 5ГГц настройка визуально следующая:

Стоило сразу найти эту тему, а то я уж думал, что у меня что-то уникальное. Да, проблема наблюдается на 5.1, при этом может не включаться одно, а могут все два из двух WG-туннелей. Закономерностей или временных решений не нашёл. Но есть еще одно наблюдение: проблема касается не только перезагрузки. Если туннель упал по какой-то причине (рестарт сервера), то кинетик рандомно может его не поднять. Светится статус "нет соединение" и на графике "гребёнка", как если бы в сторону сервера отправлялись пакеты, а в ответ ничего. Помогает перевключение тумблером в Web UI

Есть вопрос. До 5.1 настройки роуминга 802.11 r/k/v распространялись на весь сегмент. Имя мобильного домена и ключ были одинаковыми, и можно указать для какого диапазона работает FT. В 5.1b настройки точек доступа в сегменте стали полностью независимыми. Но при этом всё равно можно в каждой указать диапазон, в котором должен работать FT. А какая тут логика, если точка доступа чисто 5GHz? И как в этом случае работает band steering (и работает ли)?

Только в его? )) У меня сейчас два роутера (остальные откатил на стабильную версию) - KN-1010 и NC-1012 с той же проблемой. Достаточно разных генераций и настроенные по-разному. Осмелюсь утверждать, что проблема с интерпретацией конфига радиоточек носит системный характер. И мне крайне удивительно, что проблема эта вылезла именно в бете, а не на этапе альфа-версий. А кроме того, объективно нет намёков на то, что с дефектом работают. Я в состоянии управлять роутером через CLI, но отсутствие в WebUI основных элементов управления, как мне кажется, достаточно серьёзный повод приоритезировать работу по устранению именно этого дефекта

@eralde 5.1 Beta 0.3 - точек доступа 5GHz в web-ui как не было, так и нет. Может вам данных для анализа проблемы не хватает?

Ну и еще какая-то непонятка с настройкой Wifi-роуминга. Каждая точка доступа в сегменте имеет вроде бы свою индивидуальную конфигурацию, но по факту она общая - совпадает имя домена и ключ. Если уже менять подход в сторону общих настроек и индивидуальных, то имеет смысл делать это без путаницы. Потому что в текущем варианте это здорово путает и заставляет думать, что сеть 2.4 и сеть 5 имеют индивидуальные настройки роуминга P.S. На кой чёрт было менять то, что хорошо работало и к чему все привыкли, полагаю, вопрос останется без ответа.

Ну, как следует из моего сообщения выше, поправили так себе. Я еще не все роутеры обновил, из тех, где наблюдалась проблема, на Viva - все починилось, а вот Гига 1010 осталась без фикса, точку 5 гигагерц я там не наблюдаю. А она есть (c)

Вот добавить я не пробовал, просто существующая точка появилась в сегменте Вообще, ощущение, конечно, таково, что с маркировкой "бета" погорячились

@eralde обновление до 5.1 Beta 0.2 решило проблему с отсутствием точки доступа 5GHz не на всех роутерах. На том KN-1010, с которого я снимал для вас диагностику, всё осталось как есть:

Выложил в скрытом посте