vasek00

Покажите любым анализатором уровень на клиенте в нужной вам точке для начала (ввиду того что не известно что и как у вас стоит), так же для информации клиент при наличие нескольких точек будет подключаться к той у которой RSSI лучше. Далее оценить что происходит у вас в данной конкретной точке на самом клиенте, для примера сам пользуюсь analiti для Android 13 (или можно Aruba Utilities) или если на Samsung : - включить режим разаработчика (раздел wifi, root не нужен), после подключения можно увидеть два мака роутера (у вас их 3) и уровни от них (активный со *), без разницы какой Android - Android 13 тогда "Intelligent Wi-Fi" (в низу на версии нажимать несколько раз пока не появиться раздел ниже Wifi developer options) -> Nearby Wifi information -> ваш SSID на котором будет стоит например # 2 (два устройства, у вас будет 3) нажать и увидите Нa Analiti можно сделать тест "Handover Analyzer" т.е. увидеть реальную картину происходящего на вашем клиенте по отношению к 3 точкам в нужном месте. Если потом не трудно то напишите про свои результаты и указав на каком клиенте и что у вас получилось.

Любой - оставляете в основном режиме роутера (WAN порт в LAN или отключаете, подключение LAN порта к основному роутеру) + две настройки : 1. маршрут по умолчанию на основной роутер и DNS 2. отключить DHCP в данной конфигурации к любому роутеру, настройки на Keenetic как вам надо.

4.0.19 все по старому. После включения клиента и если долго не работает он (страницы не просматривает) то лог так же забит сообщениями. Есть дискомфорт при включение клиента и после его долгого тайм аута.

https://keenetic-gi.ga/2020/11/25/winapp-routing.html Роутинг для отдельных приложений Windows

В догонку что имеем <file name="temp:ndnproxymain.conf"> <![CDATA[ rpc_port = 54321 rpc_ttl = 10000 rpc_wait = 10000 timeout = 7000 proceed = 500 stat_file = /var/ndnproxymain.stat stat_time = 10000 dns_server = 192.168.130.101 . static_a = my.keenetic.net 78.47.125.180 static_a = f.....f.keenetic.io 78.47.125.180 norebind_ctl = on norebind_ip4net = 192.168.130.101:24 norebind_ip4net = 255.255.255.255:32 set-profile-ip 127.0.0.1 0 set-profile-ip ::1 0 rpc_only = on где 192.168.130.101 - запущен AGH static_a = f.....f.keenetic.io 78.47.125.180 [I] Apr 17 20:11:08 ndm: Ndns::Client: booked "ххх-ххх.keenetic.pro". [I] Apr 17 20:11:08 ndm: Http::Nginx: loaded SSL certificate for "fbжжжжжж2f.keenetic.io".

1. лок клиент по wifi, проблем нет при наборе my.keenetic.net так как 2. апстрим днс https://dns.cloudflare.com/dns-query после получения запроса от клиета AGH просто перенаправит запрос согласно https://dns.cloudflare.com/dns-query на 443 порт

1. Клиент Wifi 5GHx c USB3-Ethernet - дает до 180Мбит 2. Клиент ПК по Wifi 5GHz чтение c HDD роутера - дает до 18-19МB 3. Клиент ТВ по Wifi фильм 4К с HDD (DLNA) - до 60Мбит потоки то что в реале было проверено, проц под 100% будет.

Самое "ресурсоемкое" направление это канал - USB-проц-wifi2.4, но wifi5 это отдельный чип который сидит на PCIe то будет чуток полегче. Итак тест ниже USB 1. [iperf3 -c]Клиент --- 5GHz ---- 7628-USB3-Ethernet ---- [iperf3 -s] Это 150-180Мбит в реале 150Мбит и проц под завязку - 100% или 150/8~18-19MB прием на клиенте, передача через роутер. В роутере порт USB 2.0. Этот интерфейс пропускает до 480 Мбит/с 2. В данном случае роли не играет. Берем PS --<-- LAN --<-- 7628-USB2-HDD Проц роутера под 100% = 10-11MB копирование с HDD роутера на PS. Фильм 4К "Великая стена" на ТВ 4К (который переваривает потоки 160Мбит 4К по wifi, проверено на "медузах" с разными потоками) - есть моменты фриз (скорость диска от 7,5 - 11,7МB потоки 60-80Мb и есть пики/всплески более 100Мb. Проц под 100% нагрузки. В итоге могу сказать 4К не более 60Мбит реально посмотреть на ТВ wifi 5GHz для данного проца и то в идеальных условиях. Из него Вы заключили Я не заключаю а констатирую того что "щупал руками" для проца 7628+7612 или просто что было пройдено ранее вдоль и поперек для данного проца. На данном форуме была куча скринов с тестами и результатами но ввиду ограниченного выделения места для файлов(скринов) приходиться более старое удалять оставляя место под новое. 3. При схеме (относиться к новым роутерам на проце 7628 но с чипом 7613. PS1 --<-- Wifi 5 --<-- Роутер --<-- Wifi 5 --<-- PS2 Нагрузки на проц не будет. что USB 2.0 порт роутера может дать где‐то 175 Мбит/с. Верно я понял? Я бы сказал лучше 150Мбит.

4.0.18 не чего не исправлено. Апр 17 08:42:47 ndm Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "running" to "pending". Апр 17 08:42:47 ndm Network::Interface::Ip: "Wireguard0": removing default route via Wireguard0. Апр 17 08:42:47 ndm Network::Interface::Ip6: "Wireguard0": removing default route via Wireguard0. Апр 17 08:43:50 ndm Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". Апр 17 08:43:50 ndm Network::Interface::Ip: "Wireguard0": interface "Wireguard0" is global, priority 62346. Апр 17 08:43:50 ndm Network::Interface::Ip: "Wireguard0": adding default route via Wireguard0. Апр 17 08:43:50 ndm Network::Interface::Ip6: "Wireguard0": interface "Wireguard0" is global, priority 62346. Апр 17 08:43:50 ndm Network::Interface::Ip6: "Wireguard0": adding default route via Wireguard0. Апр 17 08:43:50 ndm Dns::Manager: name server 192.168.130.101 added, domain (default). Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": adding a host route to name server 192.168.130.101. Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": host route for name server 192.168.130.101 added. Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": adding a host route to name server 192.168.130.101. Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": host route for name server 192.168.130.101 added. Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": adding a host route to name server 192.168.130.101. Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": host route for name server 192.168.130.101 added. Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": adding a host route to name server 192.168.130.101. Апр 17 08:43:50 ndm Dns::InterfaceSpecific: "Wireguard0": host route for name server 192.168.130.101 added. Апр 17 08:46:54 ndm Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "running" to "pending". Апр 17 08:46:54 ndm Network::Interface::Ip: "Wireguard0": removing default route via Wireguard0. Апр 17 08:46:54 ndm Network::Interface::Ip6: "Wireguard0": removing default route via Wireguard0. ip dhcp host хх:хх:хх:хх:хх:e2 192.168.130.2 host хх:хх:хх:хх:хх:e2 policy Policy0 ip policy Policy0 description Cloud permit global Wireguard0 Повторюсь если клиент не в сети, то логи заполнены тем что выше, при подключении клиента лог.чистый. Ранее такого не было до 4.0.14 при тех же настройках.

Все что вы можете вытянуть более 100Мбит это порт USB на данном проце или wifi 5 Клиент1---wifi5---Роутер---wifi5---Клиент2 чип wifi для 5GHz 7613 (старшие братья 1711/1713) не требует ресурсов проца при схеме выше. При использование USB3->Ethernet например на чипе Asix можете получить 150Мбит - упретесь в мощь проца iperf3 -s ----LAN-USB3[Ext-II]---5GHz---клиент(iperf3 -c .... -R) давал 170-180Мбит. [I] Nov 5 19:02:10 ndm: kernel: ax88179_178a 2-1:1.0: eth0: ax88179 - Link status is: 1 Ремарка : то что написано USB3->Ethernet это не описка так как нужен линк 1Gb, другой вопрос сколько он сможет прокачать (все остальные USB2-->Ethernet будут ограничены линком 100Мбит и не более)

Это к чему?

Да нет, просто сегодня нужно было и такой "прикол", включил Tele2 и он работал. По позже MTS на Android 12 проверю.

Глюк или не глюк, ПО 4.0.17 Мобильный телефон (Android 13) вчера через MTS работал как удаленный клиент VPN сервера на роутере "IKEv2/IPsec VPN". На смартфоне встроенный клиент и настройки : - тип = IKEv2/IPSec MSCHAPv2 - адрес сервера = 2хх.ххх.ххх.хх1 - сертификат ЦС IPSec = "не проверять сервер" - сертификат сервера IPsec = "получение от сервера" - user/пароль = ****/**** MTS - работал (вчера) MTS сегодня не работает По Tele2 при тех же настройках все ОК. Что могло случиться за ночь через MTS или это бзик который может завтра/после завтра пройти.

Для того чтоб как хотите вы нужен второй роутер, тогда будет канал 36 на одном, а на втором 52.

FF "ночнушка" 113.0a1 (2023-04-05) 32-bit - ОК. Ночная тема - 0.5.108

Firefox + ночная

Все решил, дал на время канал (через модем) - все везде обновилось и исправилось.

Есть контроллер к нему еще устройство роутер по Mesh - вопросов нет. Добавлено третье устройство в режиме роутера в данную домашнюю сеть в итоге оно есть но Красное и Offline (Connection стоит -). Да на нем отключен WAN порт через WEB, но данное устройство включено и имеет маршрут в интернет через Контроллер, но не в системе Wifi. С KeenDNS вопросов не возникает. Теперь вопрос - возможно ли исправить отображение/статистику по данному устройству которое в лок сети на LAN кабеле в режиме роутера. Есть еще одна сеть - аналогичная выше, в ней так же два роутера (роутер1 WAN есть и включен, роутер2 WAN выключен), в ней проблем нет оба отобр. зеленым и есть статистика по обоим.

Он у вас мечется WifiMaster0/AccessPoint0 - 2.4, WifiMaster1/AccessPoint0 - 5. У вас имя wifi одно и то же для 2.4 и для 5. [I] Apr 5 07:13:23 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 07:13:25 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had deauthenticated by STA (reason: unspecified). [I] Apr 5 07:13:28 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 07:13:29 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 07:13:29 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.78 from 52:b1:ea:ed:33:6d. [I] Apr 5 07:13:29 ndhcps: sending ACK of 192.168.1.78 to 52:b1:ea:ed:33:6d. [I] Apr 5 07:20:46 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had re-associated successfully. [I] Apr 5 07:20:46 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 07:21:14 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had re-associated successfully. [I] Apr 5 07:21:14 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 07:28:20 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had re-associated successfully. [I] Apr 5 07:28:23 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 09:01:23 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 09:01:28 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) pairwise key handshaking timeout (msg 1 of 4-way). [I] Apr 5 09:01:28 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had deauthenticated by AP (reason: PTK 4-way handshake timeout). [I] Apr 5 09:01:32 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 09:01:32 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 09:01:33 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.78 from 52:b1:ea:ed:33:6d. [I] Apr 5 09:01:33 ndhcps: sending ACK of 192.168.1.78 to 52:b1:ea:ed:33:6d. [I] Apr 5 09:03:54 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 09:03:57 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 09:03:58 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 09:03:58 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.78 from 52:b1:ea:ed:33:6d. [I] Apr 5 09:03:58 ndhcps: sending ACK of 192.168.1.78 to 52:b1:ea:ed:33:6d. [I] Apr 5 09:03:59 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.78 from 52:b1:ea:ed:33:6d. [I] Apr 5 09:03:59 ndhcps: sending ACK of 192.168.1.78 to 52:b1:ea:ed:33:6d. [I] Apr 5 09:04:01 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.78 from 52:b1:ea:ed:33:6d. [I] Apr 5 09:04:01 ndhcps: sending ACK of 192.168.1.78 to 52:b1:ea:ed:33:6d. [I] Apr 5 09:14:04 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 09:14:04 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 09:14:04 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.78 from 52:b1:ea:ed:33:6d. [I] Apr 5 09:14:04 ndhcps: sending ACK of 192.168.1.78 to 52:b1:ea:ed:33:6d. [I] Apr 5 09:19:05 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 09:19:07 wmond: WifiMaster0/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had deauthenticated by STA (reason: unspecified). [I] Apr 5 09:19:07 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) had associated successfully. [I] Apr 5 09:19:07 wmond: WifiMaster1/AccessPoint0: (MT7915) STA(52:b1:ea:ed:33:6d) set key done in WPA2/WPA2PSK. [I] Apr 5 09:19:07 ndhcps: DHCPREQUEST received (STATE_INIT) for 192.168.1.78 from 52:b1:ea:ed:33:6d. [I] Apr 5 09:19:08 ndhcps: sending ACK of 192.168.1.78 to 52:b1:ea:ed:33:6d.

[I] Apr 4 23:01:27 kernel: wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (5) (162.159.193.2:500) because we stopped hearing back after 15 seconds В данном случае речь идет о Wireguard Warp - проблем с данным соединением нет, периодически пробегает "because we stopped hearing back after 15 seconds" но интернет не пропадает.

Во всех selftest у вас запущен был торрент и вы делали изменения в WEB не выключая торрент.

Для встроенного торрент клиента настроена политика доступа "Transmission" с многопутевым трафиком Не встречал такого использования. Обычно на проводных

У вас не стыковка настроек с тем что вы озвучили

Смотрите где какой интерфейс и за что отвечает - WEB/cli ->192.168.1.1/a команда "show interface" далее клавиша TAB будет список всех доступных интерфейсов, выбор и ОК. Посмотрите правило в dd-wrt.

Есть связка профиля (таблица маршрутов) и маркировки пакетов. Маркировка пакетов привязана к активности клиента, т.е. его нет то нет и правил маркировки, он клиент появился и как итог появилась и маркировка для него. Возможно что-то забыли убрать так как ранее 4.0.13 по моему этого не видел в логах.