[4.0-4.1: погрешность в русскоязычном описании вкладки "Монитор трафика"]

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

[Неотключаемый перехват DNS-запросов в отдельном сегменте]

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

[3.9.0: гостевая сеть / ограничение скорости в веб-итерфейсе]

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

[Добавить возможность настроить сегмент без ip адреса]

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

[Добавить возможность настроить сегмент без ip адреса]

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

Я не понял причем тут настройки arp у вас на шлюзе).

Если не рассматривать управляемые с контроллера точки доступа, тогда да, во имя чего-то настройка без IP-адреса имеет место быть на сегменте. Есть мнение что стоит предусмотреть такой сценарий в веб-интерфейсе, хотя бы для избежания отказа при работе.
А скажите, сценария когда вы устройство переводите в неуправляемый Wi-Fi-коммутатор без возможности зайти на него по сети, такого нету ведь у вас? Хотя бы один сегмент остается с настройкой IP?

[Добавить возможность настроить сегмент без ip адреса]

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

[Добавить возможность настроить сегмент без ip адреса]

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

Quote

Если в разных vlan будут разные DHCP он получит несколько шлюзов по умолчанию.

несмотря на то, что вы не отреагировали на мой вопрос о примере настройки интерфейса сегмента. Или, если это не относится к сегменту, то тогда кто - он?

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

[Добавить возможность настроить сегмент без ip адреса]

3 hours ago, AndreyUA said:

Зачастую айпи адрес в vlan сегментах не нужен, кроме одного vlan - vlan управления...

Пожалуйста уточните, чем мешает адрес интерфейса сегмента, кроме очевидного - занятый 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 и шлюза.

[Реализация режима моста на Keenetic LTE]

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

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

[ребут клиентов при ограничении к узлам/частотам]

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

[3.7 А15. Траблы с DNS]

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

[Подключение одного пира к другому через Keenetic WireGuard]

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

[Подключение одного пира к другому через Keenetic WireGuard]

как пользоваться Allowed IPs разъяснено для примера, в целом повторяющего вашу схему, в статье на русском языке https://help.keenetic.com/hc/ru/articles/360012075879
посмотрите ее пожалуйста

может быть, у вас есть предложения, как ее улучшить?

 

Wireguard концептуально может казаться несколько громоздким, думаю, с этим связано отчасти двусмысленное название вашего топика - "Подключение одного пира к другому через Keenetic WireGuard" - выглядит так, будто вы внутри туннеля еще один устанавливаете) 

[Web-интерфейс. Traceroute]

Спасибо, что обратили внимание. Аналогично ведет себя и команда в CLI.
Это можно поправить, в ближайшем тестовом выпуске ожидайте решение.

[Проблема с DNS на LAN-клиентах]

On 8/9/2020 at 10:31 PM, Leksey118 said:

В любой поддержки сходу на сетевухе пропишут всё статично

Но не адреса серверов DNS от другого провайдера, все же) Вы не смотрели на бета 3.5, проблема остается?

[Web-интерфейс: Mesh: слетает настройка кнопки экстендера]

это поведение возникает по определенной, известной причине, исправление будет. насчет того, что уже в 3.5 - да, это вероятно, однако достоверно срок пока нет возможности оговорить

[WISP. Критически падает скорость]

в качестве предположения, это может быть эффект от накапливания ошибок в счетчике внутри firmware радиомодуля. на такое повлиять маловероятно при помощи программы управления.
попробуйте сузить ширину канала.

[TSMB: потеря работоспособности спустя некоторое время]

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

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

по поводу магической силы Wireshark. не хотел комментировать это. но правда, может не надо так, не пробуя, бросаться словами. это обычное приложение, да, у него есть очень продвинутые функции, однако базовая функциональность, которой достаточно для получения диагностических данных, реализована на уровне "нажми на кнопку, вот она, получишь результат". инструкция есть https://help.keenetic.com/hc/ru/articles/213965969-Захват-сетевых-пакетов-с-помощью-программы-Wireshark
в линуксе, согласен, существует для этой программы нюанс связанный с безопасностью аккаунтов, который влияет и на базовую функциональность, но и это уже пройденный в распространенных дистрибутивах момент, скорее прозрачный чем загадочный. меньше флуда больше по делу пожалуйста!

[Проблема с DNS на LAN-клиентах]

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

однако насчет работы разрешения при этом на клиентах, подключенных беспроводно, и насчет неработы разрешения на проводных клиентах, где статически указаны публичные DNS-серверы (в случае если вы не используете на роутере фильтр, транзитные запросы должны обрабатываться как любой другой трафик) - это все синхронно при установке альфа14 возникло? если можно вышлите с проводного клиента ipconfig /all и nslookup ya.ru и nslookup ya.ru 1.1.1.1. на беспроводных клиентах где не возникала проблема - DHCP, так понимаю?

[Mash ситема]

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

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

[Keenetic Extra ll нестабильное интернет-соединение]

рекомендовал бы обратиться в поддержку

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

[Работа с USB HDD, отвалы при пропаже света]

это не совсем так, не в любой момент, а есть определенные обстоятельства. примерно это выглядит следующим образом, драйвер ntfs ставит такую метку на том при монтировании, а при отмонтировании снимает. если метка уже присутствует при попытке смонтировать, драйвер пишет про dirty filesystem. эту метку можно убрать и не отключая диск
https://help.keenetic.com/hc/ru/search?utf8=✓&query=dirty&commit=Поиск

[Проблема с DNS на LAN-клиентах]

разрешение идет в основном через один из указанных серверов. посмотрите в диагностике по словам DNS Servers там есть статистика

настройка раздельная по интерфейсам, причем вместо PPPoE указан подлежащий интерфейс, это лучше изменить наоборот. вообще интерфейсы зачем указывать, если это публичные серверы, они у вас одинаковые по два раза вписаны.

когда на ПК сделана вручную настройка, указаны какие серверы DNS - адрес кинетика или публичные/провайдеров?

 

в политике у вас получаются серверы только для домена. потому что активен PPPoE для которого серверы явно не указаны, а те, что провайдер присылает в этом интерфейсе, вы прикрепили к другим интерфейсам. у пользовательской настройки приоритет над полученной автоматически

[L2TP маршрутизация]

Замечу, вы упомянули интерфейс L2TP, похоже что сервер находится удаленно и именно Keenetic устанавливает к нему подключение, а не наоборот?

Когда включено автоматическое правило трансляции для определенного сегмента (стоит галка NAT в Домашней сети), трафик из этой сети поступает во внешние сети с адресом интерфейса устройства в этой внешней сети.

На входящий трафик непосредственное влияние этой настройки отсутствует. Однако, если говорить о трафике ответном, то разница разумеется будет, поскольку адрес отправителя разный. При включенном NAT это адрес интерфейса, который установлен у вас по L2TP, при выключенном - это адрес хоста, отправляющего запрос, так как подмены не будет происходить.

Пожалуйста, посмотрите статью.

[Доступ сегмента к интернету]

Прочтите пожалуйста статью. Насколько я могу понять, локальная сеть вашего huawei это по статье "сеть предприятия".

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