vasek00

На обоих 31Aх, раздел ntfs /tmp/mnt # mount -t cifs //192.168.1.97/s1-1tb /tmp/mnt/KN -o username=guest /tmp/mnt # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 18176 18176 0 100% / tmpfs 127348 0 127348 0% /dev tmpfs 127348 236 127112 0% /tmp /dev/mtdblock/7 2048 508 1540 25% /storage /dev/sda1 483392508 272905084 210487424 56% /tmp/mnt/01.......60 /dev/sda2 4671018 580064 3837207 13% /tmp/mnt/fc.......401 /dev/sda2 4671018 580064 3837207 13% /opt //192.168.1.97/s1-1tb 972028924 869615140 102413784 89% /tmp/mnt/KN /tmp/mnt # /tmp/mnt # lsmod | grep cifs cifs 229607 2 nls_base 5552 9 tntfs,nls_cp437,cifs,nls_cp866,thfsplus,nls_utf8,nls_cp1251,tfat,usbcore /tmp/mnt #

Поставьте hdparm посмотрите в нем параметры диска, выполните нужную команду "hdparm -B 255". Данную команду можно добавить в /opt/etc/init.d например S001hdparm.sh #!/bin/sh # APM HDD (-B 255 OFF, -B 128 default) /opt/sbin/hdparm -B 255 /dev/sd... 2> /dev/null где sd.... ваш диск, дать права файлу "chmod 755 S001hdparm.sh" посмотреть можно выполнив команду "df"

Usage: vconfig COMMAND [OPTIONS] Create and remove virtual ethernet devices add IFACE VLAN_ID rem VLAN_NAME set_flag IFACE 0|1 VLAN_QOS set_egress_map VLAN_NAME SKB_PRIO VLAN_QOS set_ingress_map VLAN_NAME SKB_PRIO VLAN_QOS set_name_type NAME_TYPE set_egress_map [vlan-name] [skb_priority] [vlan_qos] — указывает, что для исходящих пакетов через vlan-name с определённым приоритетом буфера сокетов (sk_buff) skb_priority, должна выполняться маркировка приоритета VLAN в значение vlan_qos (3-х битное значение в VLAN заголовке). По умолчанию значение приоритета VLAN vlan_qos: 0. /opt/sbin # vconfig add eth3 10 /opt/sbin # vconfig set_egress_map eth3.10 0 2 /opt/sbin # ifconfig eth3.10 up /opt/sbin # ifconfig ... eth3.10 Link encap:Ethernet HWaddr хх:хх:хх:хх:хх:95 inet6 addr: хххх::хххх:хххх:хххх:хххх/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:738 (738.0 B) ... как итог /proc/9122/net/vlan # cat eth2.1 eth2.1 VID: 1 REORDER_HDR: 1 dev->priv_flags: 1201 total frames received 4586469 total bytes received 1287639583 Broadcast/Multicast Rcvd 645478 total frames transmitted 2802703 total bytes transmitted 1141665307 Device: eth2 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESS priority mappings: /proc/9122/net/vlan # cat eth3.10 eth3.10 VID: 10 REORDER_HDR: 1 dev->priv_flags: 1001 total frames received 0 total bytes received 0 Broadcast/Multicast Rcvd 0 total frames transmitted 7 total bytes transmitted 738 Device: eth3 INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 EGRESS priority mappings: 0:2 /proc/9122/net/vlan #

Все нормально c adguard / # nslookup mail.ru Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: mail.ru Address 1: 217.69.139.202 mail.ru Address 2: 94.100.180.202 mail.ru Address 3: 217.69.139.200 mail.ru Address 4: 94.100.180.200 mail.ru Address 5: 2a00:1148:db00:0:b0b0::1 mail.ru / # nslookup keenetic.net Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: keenetic.net Address 1: 46.105.148.88 / # Отключил adguard / # nslookup ixbt.com Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: ixbt.com Address 1: 91.208.42.67 www.ixbt.com / # / # nslookup rbc.ru Server: 127.0.0.1 Address 1: 127.0.0.1 localhost Name: rbc.ru Address 1: 80.68.253.13 redirector.rbc.ru Address 2: 185.72.229.13 redirector.rbc.ru / # На тех серверах что выше https upstream https://dns.adguard.com/dns-query dnsm https upstream https://cloudflare-dns.com/dns-query?ct=application/dns-json json

100% загрузка проца ExtraII. Для клиента LAN DNS является ExtraII, просто на клиенте запущен DNSBench и нажата кнопка "Nameservers" ( скрин 1-3). Дело до запуска "Run Benchmark" не дошло. Спустя некоторое время примерно до 1мин все в исходное состояние. При конфиге ! adguard-dns enable dns-proxy tls upstream 176.103.130.130 853 sni dns.adguard.com tls upstream 176.103.130.131 853 sni dns.adguard.com tls upstream 1.0.0.1 853 sni cloudflare-dns.com https upstream https://dns.adguard.com/dns-query dnsm https upstream https://cloudflare-dns.com/dns-query?ct=application/dns-json json tcp 0 0 127.0.0.1:40301 0.0.0.0:* LISTEN 749/https_dns_proxy tcp 0 0 127.0.0.1:40303 0.0.0.0:* LISTEN 750/https_dns_proxy tcp 0 0 127.0.0.1:40508 0.0.0.0:* LISTEN 747/https_dns_proxy tcp 0 0 127.0.0.1:40509 0.0.0.0:* LISTEN 748/https_dns_proxy udp 0 0 127.0.0.1:40508 0.0.0.0:* 747/https_dns_proxy udp 0 0 127.0.0.1:40509 0.0.0.0:* 748/https_dns_proxy udp 0 0 127.0.0.1:40301 0.0.0.0:* 749/https_dns_proxy udp 0 0 127.0.0.1:40303 0.0.0.0:* 750/https_dns_proxy tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 751/ndnproxy tcp 0 0 :::53 :::* LISTEN 751/ndnproxy udp 0 0 0.0.0.0:54321 0.0.0.0:* 751/ndnproxy udp 0 0 0.0.0.0:53 0.0.0.0:* 751/ndnproxy udp 0 0 0.0.0.0:54838 0.0.0.0:* 751/ndnproxy udp 0 0 :::53 :::* 751/ndnproxy Ситуацию проверил три раза и она не изменилась.

KN1010 релиз 301А300 сервис TSMB, клиент Winodws 7, проводник - создал на HDD (раздел NTFS) каталог, стал в него записывать файлы на 695 шт. записал далее запись не возможно. Проводник Windows показывает кол-во в данном сетевом месте 451шт., другая программа показывает кол-во 695шт. (файлы фото размером 2-5МБ) дозапись этой другой программой удачна - общее кол-во довел до 729шт. Windows проводник так и не смог показать на сетевом диске более 451 хотя их там 729. В обратную сторону на лок.диск Windows проводником пришлось делать заход в два раза - первый 451шт. второй заход остатки 278шт. в итоге на лок.диске проводник Windows 7 увидел все 729 файла. Проверял на LAN так как по wi-fi будет долго.

Все возможно, чем больше будет информации у разработчиков тем лучше.

Да нет все вроде нормально, 301A300 Приложение на Android - "Keenetic тестовая версия" от 18.06.2019 (облачный доступ и управление для OS 3.0) И с другого ракурса

А чего тут не понять 1. вариант dnscrypt-proxy настройки server_names = ['adguard-dns', ........'] и DNSCrypt 2. вариант фильтр/DoH коробочный При первом варианте скорость выполнения запроса DNS будет быстрее чем при втором варианте. При выполнении DNSBench на клиенте и настроенном на ExtraII DoH проц роутера ушел в 100%.

Видимо хороший гвоздь даже если учесть что речь про dnscrypt-proxy в который забивают гвоздь и скорость обработки запроса уже по барабану была например 20-30ms станет от 60ms и выше (как и было сказано ранее "DoH/DoT" медленнее чем "DNSSec" в dnscrypt-proxy, где интернет фильтр так же включался всего одной строкой server_names = ['adguard-dns', ........']). На Extra-II при применении 2 серверов DoH, а на клиенте запуск DNSBench выводил проц на 100% загрузки, конечно такой страницы и с такой нагрузкой в интернете не будет. То что DoH/DoT есть в коробке - это серьезный плюс. Ниже два скрина клиент на LAN (Extra-II в качестве DNS сервера, с DoH - adguard-dns и cloudflare) в браузере просто перебор страниц (загрузилась, открываем другую) и тот же клиент LAN только запущен DNSBench. На Extra-II канал PPPoE всего то в 20Мбит.

Все взято из selftest Med.Resp/Avg.Resp - серьезный хххms у вас, вопрос только по каким серверам.

Как то не "реальная" картника от DNS Bench, например при dns-proxy 1 tls upstream 1.0.0.1 853 sni cloudflare-dns.com 2 tls upstream 8.8.8.8 853 sni dns.google.com 3 tls upstream 176.103.130.131 853 sni dns.adguard.com Total incoming requests: 1004 Proxy requests sent: 1956 Cache hits ratio: 0.213 (214) Memory usage: 209.63K DNS Servers Ip Port R.Sent A.Rcvd NX.Rcvd Med.Resp Avg.Resp Rank 1 127.0.0.1 40500 692 175 130 46ms 46ms 7 2 127.0.0.1 40501 731 101 86 72ms 122ms 5 3 127.0.0.1 40502 533 0 3 114ms 106ms 0 После запуска DNS Bench 1.0.0.1 cloudflare-dns.com = 46ms/46ms 8.8.8.8 dns.google.com = 72ms/122ms 176.103.130.131 dns.adguard.com = 114ms/106ms

Ну так и оставайтесь на dnscrypt, в чем фишка перепрыгивания?

Лучше реально пример из которого можно что-то выбрать по приемлемым "ms" tls upstream 1.1.1.1 853 sni cloudflare-dns.com tls upstream 8.8.8.8 853 sni dns.google.com tls upstream 9.9.9.9 853 sni dns.quad9.net tls upstream 176.103.130.131 853 sni dns.adguard.com https upstream https://dns.adguard.com/dns-query dnsm https upstream https://cloudflare-dns.com/dns-query?ct=application/dns-json json DNS Servers Ip Port R.Sent A.Rcvd NX.Rcvd Med.Resp Avg.Resp Rank 127.0.0.1 40500 780 96 76 88ms 114ms 3 127.0.0.1 40501 855 70 84 72ms 78ms 3 127.0.0.1 40502 869 80 76 74ms 104ms 3 127.0.0.1 40503 936 0 1 83ms 83ms 0 127.0.0.1 40508 918 48 36 83ms 103ms 3 127.0.0.1 40509 791 119 97 71ms 71ms 3 Что-то и выбрать из данного набора не чего, так чтоб 30-50ms

Вы же написали "В связи с реализацией DoT и DoH dnscrypt уходит на свалку истории." По мимо это в dnscrypt еще был функционал # Use servers implementing the DNSCrypt protocol # Use servers implementing the DNS-over-HTTPS protocol # Server must support DNS security extensions # Server must not enforce its own blacklist (for parental control, ads blocking...) # require_nofilter = true [blacklist] ## Path to the file of blocking rules (absolute, or relative to the same directory as the executable file) # blacklist_file = '/opt/tmp/blacklist.txt' [ip_blacklist] ## Path to the file of blocking rules (absolute, or relative to the same directory as the executable file) # blacklist_file = '/opt/tmp/ip-blacklist.txt' [whitelist] ## Path to the file of whitelisting rules (absolute, or relative to the same directory as the executable file) # whitelist_file = '/opt/tmp/whitelist.txt' https://github.com/jedisct1/dnscrypt-proxy/wiki/Public-blacklists

Маленький вопрос, в dnscrypt можно было блокировать IP по списку, как быть с данным функционалом тогда?

Отключены сервера от провайдера, добавлен dns-proxy tls upstream 1.1.1.1 853 sni cloudflare-dns.com работает как клиенты так и с самого роутера. Весит сервис через который все это и идет "nutdns", так же при "ping aaaaa.ru" c самого роутера запросы уходили на 1.1.1.1:853 и простых запросов на 53 порт не было. В догонку [I] Jun 14 13:11:58 ndm: AdguardDns::Client: AdGuard DNS disabled. [I] Jun 14 13:11:58 ndm: SkyDns::Client: SkyDNS disabled. [I] Jun 14 13:11:58 ndm: YandexDns::Client: Yandex.DNS disabled. [I] Jun 14 13:11:58 ndm: Core::ConfigurationSaver: saving configuration... [I] Jun 14 13:11:58 ndm: Dns::Secure::ManagerDot: DNS-over-TLS name servers cleared. [I] Jun 14 13:11:58 ndm: Dns::Secure::ManagerDot: DNS-over-TLS name server 1.1.1.1:853 added. [I] Jun 14 13:11:58 ndm: Dns::Secure::ManagerDot: DNS-over-TLS name server 8.8.8.8:853 added. [I] Jun 14 13:11:58 ndm: Dns::Secure::ManagerDoh: DNS-over-HTTPS name servers cleared. [I] Jun 14 13:11:58 ndm: Core::ConfigurationSaver: saving configuration... [I] Jun 14 13:12:01 ndm: Core::ConfigurationSaver: configuration saved. dns_server = 127.0.0.1:40500 . dns_server = 127.0.0.1:40501 . ... set-profile-ip 127.0.0.1 0 set-profile-ip ::1 0 dns_tcp_port = 53 dns_udp_port = 53 DNS Servers Ip Port R.Sent A.Rcvd NX.Rcvd Med.Resp Avg.Resp Rank 127.0.0.1 40500 4 1 3 65ms 262ms 3 127.0.0.1 40501 432 428 1 39ms 39ms 6 По скорости работы как то не понятно и так же если судить по [2019-06-12 19:59:37] [NOTICE] dnscrypt-proxy 2.0.23 [2019-06-12 19:59:37] [NOTICE] Now listening to 127.0.0.2:65053 [UDP] [2019-06-12 19:59:37] [NOTICE] Now listening to 127.0.0.2:65053 [TCP] [2019-06-12 19:59:41] [NOTICE] [cloudflare] OK (DoH) - rtt: 50ms [2019-06-12 19:59:41] [NOTICE] [cpunks-ru] OK (DNSCrypt) - rtt: 27ms [2019-06-12 19:59:41] [NOTICE] [yandex] OK (DNSCrypt) - rtt: 26ms [2019-06-12 19:59:41] [NOTICE] Server with the lowest initial latency: yandex (rtt: 26ms) [2019-06-12 19:59:41] [NOTICE] dnscrypt-proxy is ready - live servers: 3 [2019-06-14 11:53:19] [NOTICE] [charis] OK (DNSCrypt) - rtt: 56ms [2019-06-14 11:53:20] [NOTICE] Server with the lowest initial latency: cpunks-ru (rtt: 26ms)

А где можно взглянуть, в наст. время 3.00.B.1.0-0 В догонку, нашел component: name: wireguard group: Opkg priority: low size: 67600 order: 99 version: 3.01.A.1.0-2 hash: 85460176477b55950b0b229d6961369e queued: no

Возможно поможет поиск - "xmlstarlet/ndmq" mac_client=`ndmq -p 'show associations' -x | xml sel -t -m '//station[authenticated="yes"][mac="xx:xx:xx:xx:xx:be"]' -v 'mac' ndmq -p 'show ip hotspot' -x | xml sel -t -m '//host[link="up"][active="yes"]' -v 'name' -o ' : ' -v 'ip' -o ' : ' -v 'rxbytes' -o ' : ' -v 'txbytes' ndmq -p 'show associations' -x | xml sel -t -m '//station[ap="WifiMaster1/AccessPoint0"][authenticated="yes"]' -v 'mac' -o ' ndmq -p 'show interface' -x | xml sel -t -m '//interface[link="up"][state="up"][connected="yes"]' -v '@name' -o ': ' -v 'address' -o '/' -v 'mask' -n так же поиск по форуму

Ваше право считать это главным.

Что значит ущербны? Сосед вот тоже может пытаться подключиться или даже сам клиент потерял связь с роутером и пытается ее опять поднять или даже как в данном случае Но когда кто то закрывает/открывает двери или закрывает своим телом вектор между камерой и роутером, то камеру перекидывает на другой, потом опять обратно. И так может длительное время лихорадить. да малоли что там "летает" по wi-fi И так есть два роутера без всякого контроллера на которых SSID-5GHz но разные частоты, клиент видит роутер1 на rssi=-54 (канал=36), роутер2 на rssi=-48 (канал=52) => клиент подключился к роутер2 (канал 52) => видит Beacon только от данного роутера2 rssi для данного клиента -48. Ухожу в точку где клиент с роутер2 rssi=-73 далее процедура переключения на роутер1 канал 36 Клиент подключился к роутеру1 канал 36 с rssi=-63 и опять видит Beacon только от данного роутера1. Повторим эту же процедуру только с белым списком на роутере1 (в удаленной точке проходило переключение на данный роутер). До момента подключения клиент видит оба роутера => роутер1 на rssi= -53 (канал 36 плюс белый список), роутер2 на rssi=-46 (канал 52). Подключаем клиента, он подключился как и положено на роутер2 (канал 52), уходим клиентом в ту точку в которой было переключение его на другой роутер и что видим, что клиент цепляется до по следненего к данному роутеру2 аж с rssi=-85 не теряя связи с ним Примечание Видимость другого роутера при роуминг в данном случае возникает когда клиент достигает значения rssi равным например -75 и получив 4 раза предложение "ManagementProbe responce" от старого роутера, он клиент получает сразу на свой MAC от нового роутера 4 раза "ManagementProbe responce" с указанным уровнем rssi от него на этом же SSID, т.е. имеем повторы пакетов через 10сек, но клиент регистрацию не потерял с роутером. Уровень rssi=-79-83 (интернет на нем был). Как то так при беглом разборе. При учете условий пользователя т.е. выбираем обычное подключение клиента

Какие "бубны" у вас два роутера вещают wi-fi и КАЖДЫЙ имеет управления ИНДИВИДУАЛЬНО (функционал больше) и это уже называется "танцевать с бубном" не использовать кнопку - "Модульная система" ну-ну. 😄

А данный сервис так уж принципиален на 2-3 роутерах которые находятся в пределах одного помещения. т.е. у вас два роутера один как основной плюс второй как ТД переводите его в нормальный режим (снимаете с него контроль Wi-fi) + делаете настройка Wi-fi для роуминга на данной ТД + плюс "белый список" на данной ТД для сетевых клиентов.

Согласен Почему бы не по пробовать на ТД/роутере - "Контроль доступа к беспроводной сети" выбрать белый список, где данное устройство на ТД нет а на роутере есть.

Добавлю на пк с 10.1" под windows 10 например в разделе мои сети -> расписание работы (редактировать) не позволяет сохранить изменения, при увеличение страницы (масштаб в браузере", изменить возможно.