KoneTaH

{ "ping-check": { "profile": { "_PINGCHECK_VPN4": { "max-fails": { "count": 4 } } } } } А ошибка с таймаутом реальна, поправим.

Все правильно, пока ping-check на основном интерфейсе не даст добро, WG нормально не поднимется. Это может занять время. И вот: [I] Aug 28 18:21:01 ndm: PingCheck::Profile: "default": interface "PPPoE0": failed to resolve any of the checked hosts, failure count 1/5. [...] [W] Aug 28 18:24:12 ndm: PingCheck::Profile: "default": interface "PPPoE0" address 100.104.198.230: success count 1/5. [...] [W] Aug 28 18:24:23 ndm: PingCheck::Profile: "default": interface "PPPoE0" address 100.104.198.230: success count 2/5. [...] [I] Aug 28 18:24:53 ndm: PingCheck::Profile: "default": interface "PPPoE0" address 100.104.198.230: success count 5/5. [I] Aug 28 18:24:54 ndm: Wireguard::Interface: "Wireguard0": resolved peer "XXX" endpoint to "X.X.X.X". [I] Aug 28 18:24:54 kernel: wireguard: Wireguard0: peer "XXX" (6) created [I] Aug 28 18:24:54 ndm: Network::Interface::EndpointTracker: "Wireguard0": "XXX": remote endpoint is "X.X.X.X". [I] Aug 28 18:24:54 ndm: Network::Interface::EndpointTracker: "Wireguard0": "XXX": connecting via "PPPoE0" (PPPoE0). [I] Aug 28 18:24:54 ndm: Network::Interface::EndpointTracker: "Wireguard0": "XXX": local endpoint is "X.X.X.X". [I] Aug 28 18:24:55 ndm: Network::InternetChecker: Internet access detected. [I] Aug 28 18:25:00 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". [I] Aug 28 18:25:00 ndm: Network::Interface::Ip: "Wireguard0": interface "Wireguard0" is global, priority 31743. [I] Aug 28 18:25:00 ndm: Network::Interface::Ip: "Wireguard0": adding default route via Wireguard0. Все как я и сказал - один фейл у ping-check и все, нужно ждать почти минуту, потом WG нормально поднимается.

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

Судя по селф-тесту, PPPoE интерфейс, через который работает WG, гасится ping-check'ом, поэтому WG не может стартовать нормально. Если у ping-check не прошел хотя бы один тест, то ему при дефолтных настройках потом потребуется не менее 5 успешных тестов (50 секунд) для того чтобы перейти из состояния fail в состояние pass, все это время он будет гасить ваш PPPoE. Можете включить отладку на PPPoE интерфейсе (interface PPPoE0 debug), сохранить конфиг, перезагрузиться и посмотреть, что там ping-check про себя думает в процессе загрузки.

А что значит "показывает зеленый"? В CLI команда show ping-check что выводит?

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

Я уж было подумал, что в последнее время что-то изменилось, но нет: UniFi Dream Machine - от 50 килорублей, UniFi Cloud Key - подешевле, от 25 килорублей. Ну или компьютер-сервер. Все как я и сказал. Так что "ни разу не так"-то? Для гика нормально, для рядового пользователя, далекого от IT - уже либо сложновато, либо дороговато.

Насколько я помню, у того же Ubiquiti, если ты хочешь централизованное управление, то ты должен развернуть для этого отдельную железку (сервер) со специальным софтом, которая больше ничем, кроме управления, не занимается. Это по-вашему точно предел мечтаний типичной аудитории soho-устройств, которой нужно просто "удлинить" wifi в квартире или на даче, чтобы комфортно сидеть в соцсетях с телефона и смотреть какое-нибудь онлайн тв с "умного" телевизора? Думаете, они готовы раскошелиться условно на три-четыре устройства вместо двух-трех?

Если вы не хотите "синхронизацию параметров от головы", а хотите вручную все везде крутить индивидуально, бегать включать MLO вручную, отдельные точки доступа на отдельных ретрансляторах крутить, то зачем вам вообще тогда MWS? Можно же устройства в меш просто не объединять и вы получите практически то что хотите. Никакой синхронизации от головы, полная свобода самовыражения.

Ну а показывать и позволять включать и выключать 5 Ггц для ssid на однодиапазонном контроллере (или, аналогично, позволять включать и выключать per-ssid полосы 2.4 и 5 Ггц на гипотетическом контроллере вообще без Wi-Fi на борту) - это ок или нет? Если нет, то почему? Если да, то чем ситуация с MLO принципиально отличается?

Вы о чем вообще? Эта настройка настраивается на AP, а не на WifiMaster, и в GUI она соответственно относится к ssid, а не к общим параметрам Wi-Fi. И зачем заставлять людей бегать по ретрансляторам и включать её индивидуально там, где она поддерживается? Какой в этом сакральный смысл?

Ещё раз - эта настройка может показываться на контроллере, даже если сам контроллер не поддерживает MLO, так как эта настройка передаётся на ретрансляторы. Это менять не планируется. Единственное, что планируется - добавить проверку, что хотя бы один из зарегистрированных ретрансляторов поддерживает Wi-Fi 7.

Почему должно? Контроллер находится в одном месте, там одна радиообстановка, ретрансляторы в других местах, там своя радиообстановка. Такие параметры как номер канала должны настраиваться индивидуально на каждом ретрансляторе, эта настройка не передается с контроллера.

Там случаем рядом не написано что-нибудь вроде "determined by a 5 GHz mesh connection"? Скорее всего защита от пользователей, которые, имея ретрансляторы, подключенные через беспроводной backhaul, пытаются на этих ретрансляторах выставить канал вручную и в результате теряют связь с этими ретрансляторами. Даже если контроллер не поддерживает MLO, его могут поддерживать какие-то из экстендеров. Эта настройка передается на экстендеры.

Это не во всех случаях реально сделать. Например, представим себе, что экстендеры подключены в цепочку: экстендер1 - экстендер2 - клиент. В этом случае mac адрес клиента будет значиться на "проводном" порту в таблице как у экстендер1, так и у экстендер2, и чтобы достоверно разобраться, к чему же он всё-таки в конечном счёте подключён, нужно иметь полную информацию о структуре сети, а ей обладает только контроллер.

Неуправляемые коммутаторы не должны фильтровать 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 не синхронизируется между устройствами, входящими в меш.

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