corniger

Спасибо. Поправлено, войдёт в очередной выпуск.

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

Буква "и" не была использована чтобы избежать ..ее и И.. Вся настройка так и осталась называться Ограничение скорости, данное поле ввода принимает значение для обоих направлений одинаковое, если включить ниже Асимметрично то поле разделяется на два, по направлениям

Настройка "Без IP адреса" для сегментов устройства в режиме extender запланирована в 3.8.

Спасибо. Вам, если рассматривать использование Wi-Fi-системы, не поможет решение вопроса "просто разрешите сохранение настроек сегмента без IP-адреса", так как в случае ваших требований, если даже и будет такая возможность, это будет, как, знаете, маска с огурцами. Действует пока нанесено. Как только контроллер проведет следующее построение, например при перезапуске, настройка interface ip no address с ретрансляторов будет убрана - заменена на ip address dhcp. Другая настройка не поддерживается для неосновного сегмента в Wi-Fi-системе, и планов на реализацию этого пока совсем нет. Я не понял причем тут настройки arp у вас на шлюзе). Если не рассматривать управляемые с контроллера точки доступа, тогда да, во имя чего-то настройка без IP-адреса имеет место быть на сегменте. Есть мнение что стоит предусмотреть такой сценарий в веб-интерфейсе, хотя бы для избежания отказа при работе. А скажите, сценария когда вы устройство переводите в неуправляемый Wi-Fi-коммутатор без возможности зайти на него по сети, такого нету ведь у вас? Хотя бы один сегмент остается с настройкой IP?

Кажется, понял о чем вы. Имеется в виду, что в дополнительных сегментах (кроме основного, который вы оставляете как VLAN управления) требуется на всех узлах Wi-Fi системы, включая контроллер, отсутствие IP-адресов? FT-роуминг при этом не будет работать, но вам это и не нужно, так? А требование такое, потому что а) доступ пользователей к веб-интерфейсам точек доступа и контроллера неприемлем б) использование DHCP-клиентов неприемлемо в) статические адреса (они и не поддерживаются на точках досутпа в дополнительных сегментах) также неприемлемы

Доступ к управлению можно закрыть при помощи сетевого экрана, устранять адрес интерфейса для этого не обязательно. Я видимо неверно понимаю вашу схему, мне так начинает казаться по прочтении этого несмотря на то, что вы не отреагировали на мой вопрос о примере настройки интерфейса сегмента. Или, если это не относится к сегменту, то тогда кто - он? Пожалуйста, уточните, как у вас планируется, как должен быть настроен сегмент? Вы включаете в сегменте несколько VLAN-интерфейсов, с разными внешними DHCP-серверами?

Пожалуйста уточните, чем мешает адрес интерфейса сегмента, кроме очевидного - занятый IP? Верно понимаю, что вы говорите о сегменте к примеру с такой конфигурацией? interface Bridge2 description "Segment 3" include GigabitEthernet0/Vlan15 include WifiMaster0/AccessPoint2 include WifiMaster1/AccessPoint2 mac access-list type none security-level protected ip dhcp client dns-routes ip dhcp client name-servers iapp key ns3 6i1ln01HEPOQDCOyDeDwY/FL up Без адреса на сегменте, если не ошибаюсь, не будет работать 802.11r - FT-роуминг. Если можно расскажите подробнее также о других недоработках. В реализации на данный момент, действительно, контроллер Wi-Fi-системы это обязательно устройство в основном режиме работы, но все сегменты кроме Home вы можете настроить на использование внешнего DHCP и шлюза.

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

1 и 2, работы в этом направлении запланированы, обращение в техподдержку если нет специальной необходимости можно не оформлять в названии топика есть слово "ребут", и также вы пишете в сообщениях о ребуте всех клиентов - пожалуйста, уточните, это перезагрузка имеется в виду? или ребут в данном случае надо понимать как переподключение к сети

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

не так будили видимо. грамотно заданный вопрос..

как пользоваться Allowed IPs разъяснено для примера, в целом повторяющего вашу схему, в статье на русском языке https://help.keenetic.com/hc/ru/articles/360012075879 посмотрите ее пожалуйста может быть, у вас есть предложения, как ее улучшить? Wireguard концептуально может казаться несколько громоздким, думаю, с этим связано отчасти двусмысленное название вашего топика - "Подключение одного пира к другому через Keenetic WireGuard" - выглядит так, будто вы внутри туннеля еще один устанавливаете)

с точки зрения функционала, управление от уровня сигнала клиента еще пока не реализовано. тем не менее, мало что конкретного можно определить из вышеизложенных данных. что если клиент хватается за первый попавшийся маяк в эфире? что если он запоминает себе по-тихому BSSID, и других и не ищет? если у вас есть возможность поделиться захватом радиоэфира MESH-системы, например, моментов когда запускается клиент и подключается не к близкорасположенной ТД, а удаленной, с низким уровнем сигнала ТД - анализ подобной информации может помочь. вы можете прислать такие данные в ТП, чтобы здесь не прятать в сообщения.

рекомендовал бы обратиться в поддержку если проблема продолжается, пришлите вместе с обращением файл диагностики (self-test.txt) сохранив его непосредственно в период когда проявляется описанное поведение