KoneTaH

Где именно "с <r 2> что-то непонятное происходит"? Если в конфиге, то приведите его - мол, "вот конкретный пример конфига, который не загружается с <r 2>, но загружается, если его убрать".

Ну так в вопросе у человека речь конкретно про CLI. И в CLI простое убирание <r 2> не помогает и помочь не может, зачем вы вводите людей в заблуждение - непонятно. У вас как в анекдоте - "... и не Волгу, а велосипед, и не выиграл, а проиграл"

Даже не представляю, с чего вы это взяли. Во-первых, параметры, содержащие в себе пробелы, должны быть заключены в кавычки, поэтому само по себе убирание <r 2> совершенно ничего не даст. Во-вторых, синтаксис команды сейчас такой: Usage template: asc {jc} {jmin} {jmax} {s1} {s2} {h1} {h2} {h3} {h4} [{s3} {s4} {i1} {i2} {i3} {i4} {i5}] то есть параметры s3, s4 и i1 - i5 должны быть либо указаны все, либо не указан ни один из них. Если какие-то из них пустые, то нужно указать в качестве такого параметра пустые кавычки. Таким образом, правильный синтаксис команды будет такой: interface Wireguard1 wireguard asc 5 10 50 67 127 408497356-1600544948 2108567814-2122865249 2124439465-2126166684 2135261384-2139127173 24 11 "<r 2><b 0x858000010001000000000669636c6f756403636f6d0000010001c00c000100010000105a00044d583737>" "" "" "" "" Такая команда замечательно принимается в CLI.

Это вовсе не обязательно. Это же пакеты-заполнители, в них вообще могут быть совершенно случайные данные для обмана DPI (через теги r*), а насколько содержимое этих пакетов реально соответствовало тому, что вы указывали в конфигурации (т.е. в какие реальные UDP пакеты превращались ваши i*) - неизвестно.

ЕМНИП это ограничение временное. Но оно совершенно сознательное, это никакой не баг. В чем именно там глубинная проблема - я уже не помню, обсуждение было довольно давно, месяца три назад.

cli в лице mws wlan уже так не считает Можете сами попробовать: Добавьте свежий экземпляр, например, mws wlan test. В нем пропишите какой-нибудь не используемый нигде ssid (например, ssid name test). Привяжите его к существующему бриджу, к которому уже привязан другой mws wlan (например, bind Bridge0). Попробуйте с помощью команд band 0 и band 1 добиться того, чтобы на этих wlan набор band'ов пересекался. У вас не выйдет. Хочу напомнить, что и веб, и синхронизация с экстендерами в 5.1 работает через mws wlan. Приложение, наверное, еще нет, не слежу за этим вопросом, честно говоря.

Ответ на изначальный вопрос ("корректно ли ведет себя веб-интерфейс") ответ может быть только один - корректно

Это не баг, это сделано намеренно. В один сегмент/бридж сейчас можно включить одновременно несколько точек с разными ssid, но только при условии, что они используют разные диапазоны. Вручную вы конечно через include на бридже можете повключать, вам никто не запрещает, но в такой конфигурации какие-то фичи работать нормально не будут, по крайней мере, пока. Я помню само обсуждение, но деталей на тему того, какие именно проблемы это вызывает - уже не помню, честно говоря. Но какие-то вызывает.

На второй бете никакой адекватной проверки синтаксиса этих параметров тупо не было, они загружались в ядро "как есть", и вполне могли, например, загружаться, но в реальности не работать. Вот описание синтаксиса этих параметров: https://docs.amnezia.org/documentation/amnezia-wg/#how-it-works (раздел "3. Obfuscation Packets I1-I5 (Signature Chain) and CPS (Custom Protocol Signature)"), проверьте, что синтаксис параметра i2 соответствует описанию - состоит из правильных тегов, в нем нет никаких лишних пробелов нигде, и т.п.

Этим вы выключили изоляцию везде - и на проводных соединениях, и на беспроводных, в общем, на всем, что входит в Bridge0. В настройках mws wlan изоляция осталась и заново применилась после перезагрузки. Изоляция в mws wlan - это по сути просто обертка над изоляцией на Bridge.

NDM-4524

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

Это уже другой вопрос. Тонкая настройка vlan'ов на транк портах действительно недоступна, как я уже выше написал, но это все-таки не "невозможность выставить trunk на портах экстендера". Я вообще несколько другое имею в виду. До 5.01.C.0 контроллер при передаче конфига на экстендер запускал сохранение конфигурации в startup-config экстендера слишком рано, а поскольку процесс сохранения конфигурации асинхронный, то на момент записи startup-config конфиг, переданный с контроллера, все еще продолжал применяться, и в startup-config мог оказаться произвольный монстр франкенштейна из кусков старого конфига и нового - например, могли еще не примениться настройки vlan'ов на портах. В результате при перезагрузке экстендера настройки на портах тоже были неправильные до тех пор, пока контроллер не присылал правильные. Я вам предлагаю проверить настройки в startup-config экстендера (именно в startup-config, загрузив его в виде файла из веб-интерфейса экстендера например), и, если они там правильные, то поперезагружать экстендер и проверить, наблюдается ли все еще эта проблема. Это не тот конфиг, что я просил проверить.

Какие "другие настройки"? Типа pppoe pass through, настроек igmp или mdns reflector enforce? Они и раньше с контроллера не передавались.

Здесь ничего не понятно. Что в вашей терминологии есть "порт Trunk 3"? Покажите пример такого порта из конфига.

Вы что-то путаете, есть такая возможность. Выставляете порт в Primary Segment и он становится транком: interface GigabitEthernet0 up ! interface GigabitEthernet0/0 rename 1 switchport mode access switchport mode trunk switchport access vlan 1 switchport trunk vlan 3 switchport trunk vlan 4 up ! interface GigabitEthernet0/1 rename 2 switchport mode access switchport access vlan 3 up ! interface GigabitEthernet0/2 rename 3 switchport mode access switchport access vlan 4 up ! Вам совершенно правильно выше сказали, что в состоянии по умолчанию (то, что в port assignments называется "Primary segment") все порты - транки. Вот ограничить набор VLAN'ов на транк-портах через port assignments действительно нельзя, но trunk выставить вполне себе можно.

Ну это, скажем так, сомнительно - при условии, что и на контроллере тоже стоит 5.1.0. Что у экстендера в startup-config? Там должно быть примерно такое: interface GigabitEthernet0 up ! interface GigabitEthernet0/0 rename 1 switchport mode access switchport access vlan 3 up ! interface GigabitEthernet0/1 rename 2 switchport mode access switchport access vlan 4 up ! interface GigabitEthernet0/2 rename 3 switchport mode access switchport access vlan 4 up ! То есть настройки VLAN должны применяться сразу при загрузке экстендера, еще даже до того, как порт будет включен (команды выполняются сверху вниз), и тем более до того, как контроллер успевает туда загрузить port assignments. Я примерно понимаю, откуда тут растут ноги у этой проблемы, но при условии, что на контроллере работает именно 5.1.0, этой проблемы быть не должно.

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

Это чисто косметический баг, связанный с тем, что на доступных пользователям версиях 5.1 (включая последнюю публичную) на экстендер передаются только "классические" настройки, настройки mws wlan не передаются. По факту все работает, просто в веб UI на экстендере показываются лишь те настройки, которые были настроены в mws wlan экстендера до захвата его контроллером. Это уже исправлено (а, скорее, реализовано), в следующей 5.1 эти настройки уже будут передаваться.

Разве у них срок окончания поддержки еще не наступил?

Прямо точно таких же устройств у меня под рукой нет, но на том, что у меня есть, воспроизвести проблему не удалось: Просто сбросил настройки на 3611 и все, больше на него не заходил, мастер первоначальной настройки даже не запускал, все захватилось.

Я к чему - экстендер с паролем, даже совпадающим с тем, что установлен на контроллере, контроллер захватить не сможет. Устройство с 5.1, переведенное в режим экстендера, после сброса настроек не нужно трогать, проходить визард, тем более устанавливать пароли, нужно просто после сброса подключить его к контроллеру и через небольшое время контроллер должен предложить его захватить.

А вы после того как сбрасывали настройки на экстендере, больше ничего на нем не делали? Мастер первоначальной настройки не проходили, пароль администратора особенно не задавали?

Не заморачивайтесь, скоро выйдет версия, где настройки wifi будут передаваться с контроллера через mws wlan, да и все.

Параметры I1 - I5 должны быть в формате CPS, это строка, состоящая из списка тегов в специальном формате (либо пустая): https://asc.org/documentation/asc-wg/ Такого тега как "0" там нет.