vasek00

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 по моему этого не видел в логах.

Ну вот и отловил данный - баг или не баг. 1. Убираю клиента из профиля Policy0 (Wireguard0) и помещаю его в профиль Policy2 (Wireguard3), т.е. КЛИЕНТА В ПРОФИЛЕ Policy0 нет. 2. Дожидаюсь данной описанной выше ошибки и в итоге имею такое поведение в таблице маршрутизация для данного Policy0

Я бы не использовал pingcheck совсем и даже убрал бы компонент "быстрой настройки" 2. люблю настройки через профили и помещать в них клиентов. 3. в основном профиле убрал бы из основного канала 4G т.е. настроил бы по приоритету. - PPTP1 через Ethernet - PPTP2 через Ethernet - 4G По п.2. создал бы профиль и в нем разместил каналы уже так как вам надо - 4G - PPTP1 через Ethernet - PPTP2 через Ethernet Далее в него клиентов и попробовал использовать новую настройку При создание сложный/мудреных схем подключения более одного канала или плюсом VPN лучше использовать профили чем все в основном - личное мнение.

Что интересно - создал еще один профиль, так же создал в нем еще один wireguard (Proton) он один канал, клиента не помещал в него. В итоге никаких лишних записей по нему нет "wireguard" changed "link" layer state "pending" to "running". лог чистый по данному интерфейсу, в отличие от Похоже, после появления/включения клиента в данном профиле где Wireguard0 один и он default данные записи пропадают. В итоге получаю = отличие двух профилей в которых Wirwguard0 - активен и есть клиент (тут важно включен он или нет) и Wireguard4 - активен но нет клиентов.

Да но тут еще так как в нем только один активный интерфейс Wireguard0 и для него может быть "adding default route via Wireguard0/removing default route via Wireguard0" добавить и удалить default -> как сказал выше данный интерфейс у меня в созданном профиле. [I] Mar 25 11:00:18 ndm: Network::Interface::Ip: "Wireguard0": removing default route via Wireguard0. [I] Mar 25 11:00:18 ndm: Network::Interface::Ip6: "Wireguard0": removing default route via Wireguard0. [I] Mar 25 11:00:18 ndm: Dns::Manager: name server 192.168.130.101, domain (default) deleted. [I] Mar 25 11:01:21 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". [I] Mar 25 11:01:21 ndm: Network::Interface::Ip: "Wireguard0": interface "Wireguard0" is global, priority 65434. [I] Mar 25 11:01:21 ndm: Network::Interface::Ip: "Wireguard0": adding default route via Wireguard0. и тут не 3ceк

4.0.14 настроенный wireguard клиент для выхода в интернет (в нем один cloudflare warp). В настройках прописан DNS 192.168.130.101 сам роутер AdGuardHome, весь лог забит сообщениями, "Проверка активности" стоит 240 стояло 120/30 в данном подключение думаю оно по барабану какое, "ip global 65434". Есть созданный профиль с одним только данным подключением. Вопрос это просто лишняя информация в логе или что-то с созданным профилем происходит, так как в нем только один активный интерфейс Wireguard0 и для него может быть "adding default route via Wireguard0/removing default route via Wireguard0" И для справки IP6, хотя не где не чего для него не настраивал.

Каждая политика имеет : 1. свою таблицу маршрутизации 2. свою маркировку пакетов В каждой таблице маршрутизации есть свой default маршрут который выбран исходя из приоритета в данной политики каналов. Вопрос по маркировке для двух политик одному клиенту - не возможно. По маршрутизации тут еще можно по шаманить - клиент в политике А, для него добавляется стат.маршрут : 1. для сети на нужный интерфейс 2. для него в новую таблицу маршрутизации Вот страницу маршрутизации WEB хорошо бы расширить функционал например для клиентов которые подключились к роутеру по VPN и хотят выйти в интернет не через основной профиль а через другой - на данном форуме уже много таких пожеланий.

Если маршрутами. Вариант заворачивал клиента SSTP/wireguard (сервер на роутере) на VPN канал wireguard (на роутере) -> банальным стат.маршрутом, так как клиент который подключается имеет IP адрес. interface Wireguard0 **** выход в интернет description Cloud-warp security-level public ... interface Wireguard3 *** сервер для клиентов description KN-WG security-level public ????? ip address 10.16.130.101 255.255.255.0 ... endpoint 10.16.130.6:хххх keepalive-interval 30 allow-ips 10.16.130.6 255.255.255.255 allow-ips 192.168.130.0 255.255.255.0 allow-ips 0.0.0.0 0.0.0.0 sstp-server interface Home pool-range 172.16.1.101 2 multi-login static-ip User***** 172.16.1.29 lcp echo 30 3 ip policy Policy0 **** профиль cloudflare warp с WG description Cloud permit global Wireguard0 ip nat Wireguard3 ip nat sstp В итоге клиент WG имеет ip-10.16.130.6 а при SSTP имеет ip-172.16.1.29. По умолчанию данный клиент использует выход в интернет через основной профиль в данном случае просто провайдера. Есть созданный профиль Policy0 (cloudfalre warp) в котором только данный канал Wireguard0 и автоматом для него создана table 42 (прошивкой роутера). Прописать стат маршрут для данного клиента, завернув его с интернет ip rule add from 10.16.130.6 table 42 где table 42 это таблица маршрутизации для cloudfalre warp или Policy0 Для SSTP клиента заменить на его ip. В итоге у клиента меняется выход в интернет или провайдер или поднятый VPN wireguard или SSTP - роли не играет эфто все сетевые интерфейсы. Интернет----------[WAN-pppoe]Keenetic[WG-сервер]--Интернет--[клиент-WG]Kлиент Интернет------[WG-cloud-warp]+ Интернет----------[WAN-pppoe]Keenetic[SSTP-сервер]--Интернет--[клиент-SSTP]Kлиент Интернет------[WG-cloud-warp]+ КлиентА--Keenetic1[WG-сервер]--Интернет--[клиент-WG]Keenetic2[WG-сервер]--Интернет--[клиент-WG]KлиентВ Ремарка "странности" - сейчас 4.0.14 проверил "security-level public" для WG3 (сервер wireguard на роутере для клиентов) именно public должен стоять, ранее использовал "private" в данном варианте схемы. Это проверено именно "public" работает. При добавление еще одного WG между двумя роутерами клиент про который выше речь без проблем выходит в удаленную лок.сеть дургого Keenetic через канал WG. Тут только стат маршрут для связи двух сетей. Единственная проблема это прописать маршрут средствами WEB или cli не возможно, с установленным Entware возможно.

Рассмотрите возможность установки при уровени RSSI в данной точке в районе -60 ... -65. KN3010 wifi система 234-351Мбит линк на KN3310 по 5GHz это при "show mws associations" показывает RSSI = -76 -77 прием rxtare - 175 и передача txrate - 351 Все будет зависеть от ваших хотелок на клиентах 5GHz и что вы хотите получить от такого включения.