t800
-
Постов
222 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Сообщения, опубликованные t800
-
-
9 часов назад, Kelari сказал:
И я тут отмечюсь. Уже в супорт написал. Два кинетика , один на даче (kn-1112) второй дома(kn-1912), разные провайдеры. После обновления с прошивки 5.0.8 до 5.0.11 стали отваливатся wireguard, а с ним устройства умного дома, камеры и т.д.
Это при том, как я понимаю, что указанная проблема в 5.0.11 как бы устранена
-
1 минуту назад, KoneTaH сказал:
У вас не получится - по крайней мере в 5.1B2 точно
Команда в CLI же отработает, наверное. Вопрос в том, что конкретно в итоге будет на экстендеры передано и как на контроллере активируется (и активируется ли). Как бы там ни было, 5.1b2 мы-то и не видели пока, речь вообще про b1
-
6 минут назад, KoneTaH сказал:
Вы про 802.1x? Приведите пожалуйста пример такой конфигурации. Bridge в любом случае один, и на нем невозможно настроить для одного band что-то одним образом, а для другого - другим.
Контроллер - 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 upmws wlan, понятно, на экстендерах нет. Собственно, вопрос - ft mdid там выставлены на точках доступа корректно (10 и 11), но iapp key там же один общий, он на Bridge0. В моём случае ключ одинаковый везде. А если бы я его сделал для разных диапазонов разным в mws vlan? Где и какой ключ в итоге бы оказался?
И вопрос со звёздочкой - а что такое ip address 192.168.1.3 на экстендерах, если даже подсеть в сегменте другая? -
31 минуту назад, KoneTaH сказал:
Со старыми экстендерами тоже все будет хорошо, туда будет просто применяться только "классическая" конфигурация, она же никуда не делась.
А вот такой вариант поясните, пожалуйста: как будет отрабатывать ситуация, если для band 0 настроен 10 домен, а для band 1 настроен 11 домен? Старые экстендеры, как я понимаю, могут работать только с одним доменом от BridgeX
-
В 11.05.2026 в 02:10, KoneTaH сказал:
Это, можно сказать, уже исправлено по большому счету, но в 5.01.B.2.0 это не попадает. Так что исправление будет "через одну бету".
Скажите, а как будет обеспечена совместимость со "старыми" экстендерами, работающими на 5.0.* или 4.*?
-
6 минут назад, KoneTaH сказал:
Она и доминирует в обычных обстоятельствах, ведь конфиг при загрузке применяется сверху вниз, вот она и применится. Но если вы взяли и на работающем в данный момент устройстве поменяли настройку непосредственно на интерфейсе, то применится именно она, как последняя введенная.
Понял. Ну, на Bridge0 я ничего не менял, поэтому буду считать, что работают именно те параметры, которые заданы в mws wlan. Осталось понять, как это проверить. Видимо, только по логу wifi-системы, искать "быстрые" переходы.
-
Только что, KoneTaH сказал:
Mdid прописывается на точках доступа, и там нет почвы для конфликта с точки зрения конфига. iapp key прописывается на бридже, и должен быть одинаковым на всех mws wlan, привязанных к одному бриджу, и соответственно на этом бридже. На 5.1B1 есть логика по синхронизации настроек бриджа между mws wlan, привязанными к одному бриджу, но она, скажем так, грубовата, в 5.1B2 она изощреннее. Но в любом случае работает именно та настройка что прописана в данный момент на бридже.
То есть, вне зависимости от того, что прописано в mws wlan, фактически используется ключ iapp key из Bridge0?
В моём понимании доминировать должна нижестоящая, "уточняющая" настройка. Ведь у меня ДВЕ РАЗНЫЕ точки доступа, с разными мобильными доменами. Так почему доминирует общий ключ, да еще и доступный только из CLI? -
4 минуты назад, KoneTaH сказал:
Если отличаются (например, на бридже руками сконфигурировали), то работает та настройка, что на бридже. Но если в полностью настроенном mws wlan (привязанном к этому бриджу и имеющем ssid) что-то после этого поменять (любую настройку), то на бридж пропишется та настройка, что указана на mws wlan, и она тогда станет актуальной. mws wlan сейчас - это не более чем такая надстройка над основной конфигурацией.
Прошу прощения за дотошность, я пытаюсь досконально разобраться. Смотрите, у меня в Bridge0 точки 2.4 и 5 имеют разные ssid и разные настройки. Соответственно, есть две секции mws wlan - Home и wlan0. Параметры ft mdid и ft iapp key - разные для Home и для wlan0. Это может конфликтовать с iapp key на уровне Bridge0? Или ft iapp key имеет преимущество?
-
1 минуту назад, KoneTaH сказал:
То же самое, mws wlan должен нести все настройки, относящиеся к wifi, которые пойдут на экстендеры
Но тут вопрос скорее про конфликт. ft iapp key в mws wlan отличаются от iapp key на бридже. Номера доменов на 2.4 и 5 точках разные. Что в итоге работает?
-
@KoneTaH
Ну и вдогонку опять:Interface Bridge0 -> iapp key
Этот параметр какую играет роль, если есть отдельные ft iapp key в секциях mws wlan X
-
1 минуту назад, KoneTaH сказал:
Поэтому никаких жёстких привязок нет и не должно быть, а mws wlan внутри себя должен хранить максимум конфигурации.
ОК, спасибо за разъяснения, но тогда вот этот момент поясните:
Названия секций несут смысловую нагрузку? Или они могут быть произвольными? 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.По идее, вход в секцию настроек не должен формировать такое уведомление
-
3 минуты назад, KoneTaH сказал:
Нет, наоборот я бы сказал, он выключен на обоих диапазонах. Посмотрите в конфигурации соответствующих интерфейсов AccessPoint, там не должно быть строки ft enable. Потом уберите из конфигурации mws wlan skip-band (no ft skip-band 1 например), и ft enable должен на AccessPoint появиться.
Признаться, это всё сильно запутывает. Вы правы, после того, как я убрал ft skip-band 1, то в interface WifiMaster1/AccessPoint0 появился ft enable. Как говорится, у меня есть вопросы. Зачем вообще дублируется "ft enable" внутри AccessPoint и mws wlan? Разве недостаточно сделать связанность этих блоков через ssid и band? Хотя, как по мне, и такая связь - неверная, тут нужен некий внутренний индекс той точки доступа, к которой привязывается настройка FT. Как-то тут это выглядит сырым и архитектурно не продуманным. Например, для ситуации с несколькими точками доступа в одном диапазоне.
-
1 минуту назад, KoneTaH сказал:
skip-band - это отключение некоей фичи для определённых диапазонов. Например, сейчас у вас на соответствующем интерфейсе AccessPoint для 5Ггц не должна быть прописана команда ft enable. К сожалению, в вебе до совсем недавнего времени эта настройка была инвертирована, то есть фича выключалась, когда должна была включаться, и наоборот. В 5.1B2 должно быть исправлено.
В приведённом варианте конфигурации 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 (и работает ли)?
-
14 часов назад, keenet07 сказал:
В вашем случае что-то пошло не так
Только в его? )) У меня сейчас два роутера (остальные откатил на стабильную версию) - KN-1010 и NC-1012 с той же проблемой. Достаточно разных генераций и настроенные по-разному. Осмелюсь утверждать, что проблема с интерпретацией конфига радиоточек носит системный характер. И мне крайне удивительно, что проблема эта вылезла именно в бете, а не на этапе альфа-версий. А кроме того, объективно нет намёков на то, что с дефектом работают. Я в состоянии управлять роутером через CLI, но отсутствие в WebUI основных элементов управления, как мне кажется, достаточно серьёзный повод приоритезировать работу по устранению именно этого дефекта
-
@eralde 5.1 Beta 0.3 - точек доступа 5GHz в web-ui как не было, так и нет. Может вам данных для анализа проблемы не хватает?
-
1
-
1
-
-
Ну и еще какая-то непонятка с настройкой Wifi-роуминга. Каждая точка доступа в сегменте имеет вроде бы свою индивидуальную конфигурацию, но по факту она общая - совпадает имя домена и ключ. Если уже менять подход в сторону общих настроек и индивидуальных, то имеет смысл делать это без путаницы. Потому что в текущем варианте это здорово путает и заставляет думать, что сеть 2.4 и сеть 5 имеют индивидуальные настройки роуминга
P.S. На кой чёрт было менять то, что хорошо работало и к чему все привыкли, полагаю, вопрос останется без ответа.
-
10 минут назад, keenet07 сказал:
Видимо поправили только проблему исчезнувших уже существующих диапазонов
Ну, как следует из моего сообщения выше, поправили так себе. Я еще не все роутеры обновил, из тех, где наблюдалась проблема, на Viva - все починилось, а вот Гига 1010 осталась без фикса, точку 5 гигагерц я там не наблюдаю. А она есть (c)
-
1
-
-
Только что, project_fcc сказал:
у Вас на каких-то моделях появилась возможность добавить второй SSID в сегменте?
Вот добавить я не пробовал, просто существующая точка появилась в сегменте
Вообще, ощущение, конечно, таково, что с маркировкой "бета" погорячились -
@eralde обновление до 5.1 Beta 0.2 решило проблему с отсутствием точки доступа 5GHz не на всех роутерах. На том KN-1010, с которого я снимал для вас диагностику, всё осталось как есть:
-
1
-
-
13 часов назад, eralde сказал:
Выложите конфиг (или self-test)
Выложил в скрытом посте
-
1
-
5.1 Beta 1 | После перезагрузки роутер даже не пытается поднять соединение Wireguard
в Тестирование Dev-сборок
Опубликовано
5.1beta2 быть может?