KoneTaH

Неуправляемые коммутаторы не должны фильтровать STP BPDU. Если они их не пропускают, а wired и wireless backhaul в mesh оба включены, то будет образовываться петля.

Эту ошибку возвращает непосредственно ядерный модуль WG. Ему эти параметры отдаются "как есть", но он их не принимает. Еще он должен у вас написать в консоль, что "H1 and H2 ranges must not overlap".

Ну хорошо тогда, сделаем послабление, допускающее значение "0" в параметрах Ix.

Ну вроде бы да, но опять же - документирован вариант, когда все параметры имеют значение "0", тогда это режим совместимости с обычным WG, это понятно. А вот когда только некоторые нулевые - тут неочевидно, насколько такой вариант вообще валиден. Ну можно в принципе сделать послабление в валидаторе и пропускать в этих строках нули. Давайте подождём, что вам ответят, впрочем.

А почему нулевые Sx не должны проходить нормально? Это же размеры паддингов, ну не нужны эти паддинги, они могут быть нулевые, тут вопросов нет. А вот что означает ноль вместо строки с тегами - тут вопрос

Смотря о чем речь. Если речь про раздельные настройки расписаний, как выше пишут, то это безусловно новая фича, это в Развитие. Если речь просто про выключение точек на ретрансляторах по расписанию, установленному на контроллере, то это уже реализовано, будет доступно в следующей 5.1 и уже должно быть доступно в 5.2.

Ну вообще я тут уже приводил эту ссылку несколько раз - в официальной документации Амнезии параметры I1 - I5 имеют вполне конкретный строковый(!) формат с тегами, и никаких значений вроде нуля в нем не предусмотрено: https://docs.amnezia.org/documentation/amnezia-wg/#how-it-works Пропускать такие значения в валидаторе теоретически можно, но по факту это какой-то сомнительный недокументированный мусор получается, и в какие пакеты по факту он превратится сейчас, или, скажем, через пару минорных версий Амнезии - сказать не берусь.

Нет, эти сообщения не связаны с отношениями контроллер-ретранслятор как таковыми, это что-то связанное с Wi-Fi роумингом.

Если устройство старое, шло с завода со старым ПО, в котором был соответственно по умолчанию выставлен старый интервал, то там при любых обновлениях сохраняется этот старый интервал, пока его явно не сменишь. А если устройство шло с завода с более новым ПО, где дефолтный интервал был выставлен уже новый, то на нем он соответственно будет новый, пока его явно не сменишь. Настройка rekey-interval не синхронизируется между устройствами, входящими в меш.

Только для старых. Потому что, как я написал выше, он не обновляется автоматически при обновлении ПО, так как всегда явно прописан в конфиге и берётся оттуда.

Ну тут такое дело, что механизм передачи конфигурации Wi-Fi в 5.1-то изменился, но он изменился только если и контроллер и ретранслятор оба с софтом 5.1+. Если нет, то используется старый способ для совместимости. Поэтому в связке 5.1 - 4.3 ничего не должно было измениться вообще в плане синхронизации Wi-Fi настроек. GTK rekey interval сам по себе не должен измениться при обновлении на 5.1. Он всегда прописан в конфиге командой в явном виде, поэтому при обновлении новой версией ПО будет просто использовано старое значение. Проблемы могут быть только в случае, скажем, принудительного сброса настроек с последующей перенастройкой вручную (без заливки предварительно сохраненного конфига).

Это не совсем моя область, но, насколько я знаю, проблемы с FT наблюдаются уже довольно давно, в частности почему-то именно на iPhone 11+. Но надежно их воспроизвести на стенде, насколько я знаю, пока не удавалось. Я так понимаю, после отключения FT ошибки, связанные с согласованием ключей, ушли?

Возможно.

5.1.0 гораздо, скажем так, агрессивнее обновляет настройки на интерфейсах AccessPoint при распространении конфига с контроллера на ретрансляторы, возможно, это сильнее "наводит" проблему с FT.

Попробуйте ради интереса отключить 802.11r (fast transition) на всех диапазонах вашей wi-fi сети и посмотрите, не исчезнут ли эти ошибки при хендшейке.

Ну по идее да, надо сделать.

Ну вообще говоря расписания никогда не передавались с контроллера на ретрансляторы Это уже, можно сказать, feature request.

В следующей 5.1.

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

Тут непонятно, в чем именно дело. Но если конфиг загружается без ошибок, то вот эта строка в неизменном виде уходит в ядерный модуль WG, и он там уже формирует пакеты-заполнители в соответствии с ней. Как там дальше воспринимает эти пакеты другая сторона, как она вообще настроена по факту - кто его знает, это неизвестно. Строка сама по себе синтаксически корректная, роутер и в CLI и в конфиге по факту воспринимает ее нормально.

Вот здесь описание всех тегов: https://docs.amnezia.org/documentation/amnezia-wg/#how-it-works <r 2> - это два случайных байта. Как там другая сторона их воспримет именно в этом месте - это зависит не только от ваших настроек, но и от настроек другой стороны.

"... и не Волгу, а велосипед, и не выиграл, а проиграл". Ну OK

Так у вас же он вовсе не загружается, не так ли? Вот и проверим, загружается он вообще или нет. Те ли там IP-шники или не те - для загрузки значения не имеет.

В скрытом выложите, IP-шники и всякие ключи можете "немного" отредактировать