vasek00

exeigor [2.dnscrypt-cert.quad9.net.] the key validity period for this server is excessively long (367 days), significantly reducing reliability and forward security. "....ключевой срок действия для этого сервера чрезмерно длинен (367 дней), значительно уменьшив надежность и передовую безопасность" https://github.com/jedisct1/dnscrypt-proxy/issues/206 Если не принципиально то предложу такой вариант исправления то что у вас пробы вариант A для проверки добавил "quad9-dnscrypt-ip4-filter-pri" вариант B вариант С Для вас принципиально от куда брать сервера из [sources.'public-resolvers'] или [sources.quad9-resolvers] и ожидания выбора из данных списков. Выберите себе 4 быстрых сервера (по меньшему ms на основании лога) поставьте их в "server_names" и можно перетащить в секцию "stamp" из *.md пару-тройку (но тут в какое время данный сервер может сменить сертификат и перестать работать, но всегда можно подправить "stamp") При пробовании каждого варианта выше такого сообщения не было

пардон тогда

Ощущение что у вас запущено что-то очень много [2019-04-06 11:44:05] [NOTICE] dnscrypt-proxy is ready - live servers: 9 у меня ну не более 4 у вас аж 9 [2019-03-24 08:56:29] [NOTICE] [adguard-dns] OK (crypto v1) - rtt: 67ms [2019-03-24 08:56:30] [NOTICE] [cloudflare] OK (DoH) - rtt: 62ms [2019-03-24 08:56:30] [NOTICE] [cpunks-ru] OK (crypto v1) - rtt: 17ms [2019-03-24 08:56:31] [NOTICE] [yandex] OK (crypto v1) - rtt: 39ms [2019-03-24 08:56:31] [NOTICE] Server with the lowest initial latency: cpunks-ru (rtt: 17ms) [2019-03-24 08:56:31] [NOTICE] dnscrypt-proxy is ready - live servers: 4

Для начала подчистите *.md и *.md.mini в /opt/etc и перезапустите dnscrypt-proxy

[2019-04-06 11:43:50] [NOTICE] Now listening to 192.168.1.1:53 [UDP] [2019-04-06 11:43:50] [NOTICE] Now listening to 192.168.1.1:53 [TCP]

Упростить в нынешних реалиях (самое простое что выше) но из-за контроля /opt/etc/ndm/netfilter.d В противном случае по простому решалось бы как написано выше.

Тайный смысл. 🙂 Тогда на голосование.

Смотрите в сторону iptables iptables .... -m recent --update .... --seconds 6000 .... правда это не сработает, так как данное правило через некоторое время будет зачищено прошивкой. Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination .... 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:65222 recent: UPDATE seconds: 600 hit_count: 5 name: ssh_2 side: source mask: 255.255.255.255 и потом его отсутствие Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination ....

AdGuard стал дурить

Проверил на KN1010 стоял раньше релиз 2.15 потом переход на релиз 3, сделал обновление "update/upgrade" с запуском проблем не было.

Обновления по https://download.nextcloud.com/server/ ветки : - prereleases - releases Установить пакет "opkg install unzip", поместить скаченный файл в /opt/share/www, войти в данный каталог и распаковать например "unzip nextcloud-16.0.0beta1.zip" (будет распакован в каталог /opt/share/www/nextcloud ) Далее согласно инструкции выше. В результате как и owncloud пыхтит на 7621 проце с HDD по USB3

Третий роутер с такой же проблемой

Что-то про библиотеку уже пробегало fastvpn: bind table cleared do_page_fault(): sending SIGSEGV to mtkiappd for invalid write access to 0042c45c epc = 771246e8 in libuClibc-1.0.31.so[770c3000+b5000] ra = 77124668 in libuClibc-1.0.31.so[770c3000+b5000] fastvpn: bind table cleared

Сегодня на двух роутерах наткнулся на ошибку на релизе 215С202 По логу роутера Перегруз ошибка аналогична /lib # ls -l lrwxrwxrwx 1 root root 18 Mar 21 18:04 functions -> /opt/lib/functions lrwxrwxrwx 1 root root 21 Mar 21 18:04 functions.sh -> /opt/lib/functions.sh -rwxr-xr-x 1 root root 33090 Mar 21 13:40 ld-uClibc-1.0.31.so lrwxrwxrwx 1 root root 14 Mar 21 18:04 ld-uClibc.so.0 -> ld-uClibc.so.1 lrwxrwxrwx 1 root root 19 Mar 21 18:04 ld-uClibc.so.1 -> ld-uClibc-1.0.31.so lrwxrwxrwx 1 root root 18 Mar 21 18:04 libatomic.so.1 -> libatomic.so.1.2.0 -rwxr-xr-x 1 root root 17487 Mar 21 13:40 libatomic.so.1.2.0 lrwxrwxrwx 1 root root 19 Mar 21 18:04 libc.so.0 -> libuClibc-1.0.31.so lrwxrwxrwx 1 root root 19 Mar 21 18:04 libc.so.1 -> libuClibc-1.0.31.so .... -rwxr-xr-x 1 root root 154864 Mar 21 14:01 libndmYandexDnsClient.so -rwxr-xr-x 1 root root 746073 Mar 21 13:40 libuClibc-1.0.31.so .... /lib #

Релизы 215С202 проверка миграции клиента между двумя роутерами на 5GHz Клиент----5GHz-----KN1810-----LAN------KN1010------5GHz------Клиент KN18 в точке1, KN10 в точке2 (дальности между ними чисто символическая просто для проверки миграции клиента между роутерами). На KN18 и KN10 включено : - Роуминг 802.11r (FT) - совместимость с FT over the DS - Управление BSS-окружением 802.11k/v - BandSteering выключен SSID на роутерах один только разные каналы 52 и 36. Самый простой клиент который дает "ap": "WifiMaster1/AccessPoint0", "txrate": 270, "ht": 40, "mode": "11n", "gi": 800, "rssi": -65, "mcs": 15, "txss": 2, "ebf": false, "mu": false, "roam": "pmk" Клиент ноут, подключается к КТ18 потом переходит в удаленную точку пере подключается к KN10 и возвращается в исходную точку где опять возвращается на KN18. Подключение/пере подключение определялось по LAN анализатору на клиенте (по выбранным каналам 52/36 и по EAPOL Key1-Key4)

Возможно в перспективе для 4.9 на проце 7621 поддержка данного device supports USB Attached SCSI (UAS) и сможет ли он проц осилить или поднять текущие скорости USB3 для роутера. Есть упоминания

Если не трудно то отпишитесь по результатам.

Все это хорошо только Только каждый реализует это по своему. Если есть возможность попробуйте проверить на KN1010/Giga 3/Air

Все зависит от вашего клиента, на моих работает.

Релизы 215С1 проверка миграции клиента между двумя роутерами на 5GHz Клиент----5GHz-----KN1810-----5GHz------ExtraII------5GHz------Клиент KN18 в точке1, ExtraII в точке2 (дальности между ними чисто символическая просто для проверки миграции клиента между роутерами). Линк между роутерами 527Мбит ( по ExtraII ) и 468Мбит ( по KN1810 ) "txrate": 351, "rxrate": 526, "mode": "11ac", "gi": 800, "rssi": -67, "mcs": 4, "txss": 2, "ebf": false, "mu": false На KN18 и ExtraII включено : - Роуминг 802.11r (FT) - совместимость с FT over the DS - Управление BSS-окружением 802.11k/v - BandSteering выключен SSID на роутерах один только разные каналы 52 и 36. 1. При перемещение клиента от KN18 точка1 в сторону ExtraII точка2 => клиент переключился на ExtraII (последний rssi который видел для KN18 был равен -73). После переключения клиента на ExtraII rssi=-64, а по KN18 он равен rssi=-75/74 2. При путешествии обратно т.е. клиент был подключен к ExtraII точка2 перемещался к точке1 ближе к KN18 то клиент вернулся обратно - подключился к KN18, был виден только результат уже когда KN18 rssi=-59/-61 а для ExtraII rssi=-70 Данную процедуру выполнил несколько раз => миграция данного клиента между роутерами была без вопросов - Sams смарт с поддержкой k/r/v и Android 8. По логам что получилось увидеть

Возьмите selftest от данного роутера и посмотрите что касается вашего wi-fi 5Ghz. В данном роутере проц 7620 он же Wi-fi 2,4 и чип RT5592 для Wi-fi 5Ghz, который подключен по PCI Записи на какие либо ошибки в драйверах и в разделе RF-EEROM По данному вопросу так так релиз 2.08 то лучше в поддержку и приложить sleftest файл

Вариант перейдите с knock на iptables поискать примеры в интернете на тему динамическое открытие/закрытие порта http://wiki.enchtex.info/howto/iptables/ssh-guard

/opt/etc/init.d # mount -t davfs https://webdav.yandex.ru /tmp/mnt/01.....360/Yandex -o rw mount.davfs: the server certificate is not trusted issuer: Yandex Certification Authority, Yandex LLC, RU subject: Russian Federation, Moscow, ITO, Yandex LLC, RU identity: *.disk.yandex.net fingerprint: e1:a6:.............:b2:da You only should accept this certificate, if you can verify the fingerprint! The server might be faked or there might be a man-in-the-middle-attack. Accept certificate for this session? [y,N] y /opt/etc/init.d # df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 17152 17152 0 100% / /dev/root 17152 17152 0 100% / tmpfs 128004 0 128004 0% /dev tmpfs 128004 204 127800 0% /tmp /dev/mtdblock/7 2048 508 1540 25% /storage /dev/sda1 483392508 414769088 68623420 86% /tmp/mnt/01......360 /dev/sda2 4679210 1649435 2780124 37% /tmp/mnt/b7.......401 /dev/sda2 4679210 1649435 2780124 37% /opt https://webdav.yandex.ru 10485756 1386500 9099256 13% /tmp/mnt/01......360/Yandex /opt/etc/init.d # mount rootfs on / type rootfs (rw) ..... /dev/sda2 on /opt type ext4 (rw,relatime,data=ordered) https://webdav.yandex.ru on /tmp/mnt/01D......360/Yandex type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=16384) /opt/etc/init.d # lsof | grep dav mount.dav 4354 nobody cwd DIR 8,2 1024 446466 /opt/etc/init.d mount.dav 4354 nobody rtd DIR 31,4 202 426 / mount.dav 4354 nobody txt REG 8,2 121620 663620 /opt/sbin/mount.davfs mount.dav 4354 nobody mem REG 8,2 79796 237596 /opt/lib/libresolv-2.27.so mount.dav 4354 nobody mem REG 8,2 22548 237570 /opt/lib/libnss_dns-2.27.so mount.dav 4354 nobody mem REG 8,2 49804 237590 /opt/lib/libnss_files-2.27.so mount.dav 4354 nobody mem REG 8,2 2931760 389124 /opt/usr/lib/locale/locale-archive mount.dav 4354 nobody mem REG 8,2 10664 237577 /opt/lib/libdl-2.27.so mount.dav 4354 nobody mem REG 8,2 118872 237582 /opt/lib/libpthread-2.27.so mount.dav 4354 nobody mem REG 8,2 33144 237606 /opt/lib/librt-2.27.so mount.dav 4354 nobody mem REG 8,2 1652528 237601 /opt/lib/libc-2.27.so mount.dav 4354 nobody mem REG 8,2 95288 237603 /opt/lib/libgcc_s.so.1 mount.dav 4354 nobody mem REG 8,2 218216 237846 /opt/lib/libexpat.so.1.6.8 mount.dav 4354 nobody mem REG 8,2 90324 237637 /opt/lib/libz.so.1.2.11 mount.dav 4354 nobody mem REG 8,2 160596 237844 /opt/lib/libneon.so.27.3.2 mount.dav 4354 nobody mem REG 8,2 358284 237763 /opt/lib/libssl.so.1.0.0 mount.dav 4354 nobody mem REG 8,2 1692352 237762 /opt/lib/libcrypto.so.1.0.0 mount.dav 4354 nobody mem REG 8,2 935148 237631 /opt/lib/libiconv.so.2.4.0 mount.dav 4354 nobody mem REG 8,2 40652 237634 /opt/lib/libintl.so.8.1.5 mount.dav 4354 nobody mem REG 8,2 158968 237600 /opt/lib/ld-2.27.so mount.dav 4354 nobody 0r CHR 1,3 0t0 1060 /dev/null mount.dav 4354 nobody 1w CHR 1,3 0t0 1060 /dev/null mount.dav 4354 nobody 2w CHR 1,3 0t0 1060 /dev/null mount.dav 4354 nobody 3u unix 0x8d424a00 0t0 1871283 type=DGRAM mount.dav 4354 nobody 4u IPv4 1871316 0t0 TCP ххх-ххх-ххх-ххх.хххххххх.ххххх.ru:ххххх->webdav.yandex.ru:https (ESTABLISHED) mount.dav 4354 nobody 5u CHR 10,229 0t0 1055 /dev/fuse /opt/etc/init.d # lsmod | grep fuse fuse 63086 2

Естественно для того чтоб получить желаемые уровни (-55-80) на самом клиенте при которых он клиент будет пытаться мигрировать между ТД или хоть что-то предпринять для проверки. Band Streering был отключен везде.

Все получилось как и писал выше клиент Sams, подправил уровни на ТД1 и ТД2 и смартфон "перепрыгнул" Перемещение клиента в другую точку