KoneTaH

Это хорошо, тогда причина, скорее всего, найдена. Она реально вероятностная. А вот если бы прямо надежно воспроизводилось, тогда, скорее всего, причина была бы в чем-то другом, и в чем - непонятно. Такой вот парадокс В следующей 5.2 будет исправлено.

Насколько это надежно воспроизводится? Это всегда происходит с этим накопителем, в том числе, скажем, после перезагрузки?

Он может возникнуть в случае, если установлен компонент wireguard-server, но этот сервер не работает по какой-либо причине.

Ну вообще очень похоже на уже исправленный баг, да. Для того, чтобы он случался, нужен еще Wireguard, и он тут есть. В следующий 5.2 фикс войдет.

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

Self-test нужен с роутеров, снятый сразу после их перезагрузки. Но сдается мне, что эта проблема уже исправлена.

Это другое. Это касалось определенных сценариев маршрутизации, когда шлюз до удаленной сети доступен через интерфейс типа Bridge.

{ "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.