-
Posts
4,367 -
Joined
-
Last visited
-
Days Won
74
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Everything posted by vasek00
-
В догонку что имеем <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Мбит и не более)
-
Глюк или не глюк, ПО 4.0.17 Мобильный телефон (Android 13) вчера через MTS работал как удаленный клиент VPN сервера на роутере "IKEv2/IPsec VPN". На смартфоне встроенный клиент и настройки : - тип = IKEv2/IPSec MSCHAPv2 - адрес сервера = 2хх.ххх.ххх.хх1 - сертификат ЦС IPSec = "не проверять сервер" - сертификат сервера IPsec = "получение от сервера" - user/пароль = ****/**** MTS - работал (вчера) MTS сегодня не работает По Tele2 при тех же настройках все ОК. Что могло случиться за ночь через MTS или это бзик который может завтра/после завтра пройти.
-
-
4.0 Alpha 17. Пропал выбор режим порта.
vasek00 replied to AndreBA's question in Тестирование Dev-сборок
-
Есть контроллер к нему еще устройство роутер по Mesh - вопросов нет. Добавлено третье устройство в режиме роутера в данную домашнюю сеть в итоге оно есть но Красное и Offline (Connection стоит -). Да на нем отключен WAN порт через WEB, но данное устройство включено и имеет маршрут в интернет через Контроллер, но не в системе Wifi. С KeenDNS вопросов не возникает. Теперь вопрос - возможно ли исправить отображение/статистику по данному устройству которое в лок сети на LAN кабеле в режиме роутера. Есть еще одна сеть - аналогичная выше, в ней так же два роутера (роутер1 WAN есть и включен, роутер2 WAN выключен), в ней проблем нет оба отобр. зеленым и есть статистика по обоим.
-
KN-1011 низкая скорость WiFi, но только для 1 устройства
vasek00 replied to Сергій Ступніков 's question in Обмен опытом
Он у вас мечется 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. -
4.0 Alpha 6 - 13: Отвалы интернета
vasek00 replied to point027's question in Тестирование Dev-сборок
[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" но интернет не пропадает. -
Политика доступа игнорируется для торрент клиента 4.0 Alpha 15
vasek00 replied to Андрей Шевелёв's question in Тестирование Dev-сборок
Во всех selftest у вас запущен был торрент и вы делали изменения в WEB не выключая торрент. -
Политика доступа игнорируется для торрент клиента 4.0 Alpha 15
vasek00 replied to Андрей Шевелёв's question in Тестирование Dev-сборок
Для встроенного торрент клиента настроена политика доступа "Transmission" с многопутевым трафиком Не встречал такого использования. Обычно на проводных -
Политика доступа игнорируется для торрент клиента 4.0 Alpha 15
vasek00 replied to Андрей Шевелёв's question in Тестирование Dev-сборок
У вас не стыковка настроек с тем что вы озвучили -
Доступ с Wi-fi устройств к сервисам на устройстве LAN
vasek00 replied to XCommandeRX's question in Обмен опытом
Смотрите где какой интерфейс и за что отвечает - WEB/cli ->192.168.1.1/a команда "show interface" далее клавиша TAB будет список всех доступных интерфейсов, выбор и ОК. Посмотрите правило в dd-wrt. -
Есть связка профиля (таблица маршрутов) и маркировки пакетов. Маркировка пакетов привязана к активности клиента, т.е. его нет то нет и правил маркировки, он клиент появился и как итог появилась и маркировка для него. Возможно что-то забыли убрать так как ранее 4.0.13 по моему этого не видел в логах.
-
Я бы не использовал 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к