-
Posts
407 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by ankar84
-
-
1 час назад, Mamay сказал:
Тьфу, ну попробуйте на время отключить entware и проверить нагрузку, чтобы выяснить где собака порылась...
Не думаю, что это связано, да и /bin/nqcs -i 50ff20085ac1 это явно часть прошивки, а не Entware.
-
Прошивка 2.15.А.3.0.-2 на Гига KN-1010 после обновления Entware (хотя, имхо, вряд ли это связано вообще) вижу постоянную загрузку процессора в веб интерфейсе порядка 10-15%
top показывает /bin/nqcs -i 50ff20085ac1 в топе по CPU со значениями в районе 4.3-5.7
Сетевой активности в момент наблюдения данной загрузки роутера практически нет. Ранее такого не было - обычно загрузка CPU в районе 0 по веб интерфейсу (да и в top тоже).
Что это и как исправить?
Селф как обычно ниже.
-
-
После обновления на 2.15.A.3.0-2 уже 2 дня проблему не наблюдаю. Время от времени захожу в админку роутера, пока всё работает как часы. Если что-то изменится, напишу.
-
@Max Pl в dns на роутере ничего не меняли? Интернет фильтры там или вообще отдельный сервис вроде dnscrypt?
-
В 12.12.2018 в 23:46, zyxmon сказал:
Допилить предлагаю самостоятельно. Я dnscrypt-proxy2 не юзаю.
В итоге получилось почти так как вы указали, только добавил вывод таблицы nat, так как без этого наше правило не выводилось.
#!/bin/sh [ "$type" == "ip6tables" ] && exit 0 [ "$table" != "nat" ] && exit 0 [ -z "$(iptables -nvL -t nat | grep "to:192.168.1.1:53")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 exit 0
После перезагрузки проверил - правило на месте, ошибки разумеется нет.
- 1
-
11 час назад, zyxmon сказал:
Мне кажется следует в скрипте заменить iptables-save на выдачу правил только из PREROUTING - и быстрее чуть работать будет
А может быть уже есть готовая реализация? А то я далек от баша и iptables.
-
3 часа назад, rotor сказал:
дает адекватный ответ без ругани. И в журнале пропала запись.
А у меня всё по прежнему, вывод с ошибкой. Пока вроде нечего не обновилось.
-
22 минуты назад, Le ecureuil сказал:
Уже можно, пробуйте.
Вот прямо в моменте и не доступно.
Возможно это связано, с тем, что KeenDNS FQDN разрешается как в мой белый IPv4 адрес, так и в облачный IPv6 адрес KeenDNS.
Хотя только что поставил и затем снял галочку Режим работы (IPv6) на странице Доменное Имя и это имя стало разрешаться только в мой реальный IPv4 адрес. Но веб так и не доступен.
Селф ниже как обычно.
-
1 час назад, TheBB сказал:
Ещё рано для `opkg update`. Но можете затестить предварительную версию пакета )))
Теперь понял где и что поправлено.
Подожду штатного обновления, так как проблема не слишком критичная.
-
В 05.12.2018 в 21:40, Le ecureuil сказал:
Про conndmmark:
Что-то не пойму, куда именно добавлен патч. Установил самый свежий драфт 2.15.A.3.0-1, в Entware сделал update&&upgrade, а ошибка осталась.
-
6 часов назад, Le ecureuil сказал:
Внимание обращено, к следющему релизу draft 2.15 кое-что предпримем. Я сообщу, как стоит пробовать.
Супер! Большое спасибо! Как сообщите, перейду на драфт и протестирую.
- 1
-
Доброго дня!
Имею проблему с недоступностью webui по зарегистрированному имени KeenDNS с автоматическим получением сертификата Let's Encrypt.
Так же по этой проблеме создан тикет #400857 в официальную поддержку, где коллеги уточнили, что с текущим уровнем журналирования происходящего с KeenDNS и в целом webui сложно диагностировать мою проблему и попросили обратится к разработчикам тут, на форуме, чтобы те добавили расширенную диагностику работы webui в том числе и по KeenDNS FQDN.
От себя добавлю, что было бы очень здорово, если бы эта расширенная диагностика была опциональной, а не обязательной. То есть выполняешь в CLI что-то типа set http.debug=1 и у тебя включается эта самая расширенная диагностика.
В целом, считаю данную функцию очень нужной. Притом и самим разработчикам для более точной диагностики возникающих проблем.
Прошу поддержать голосованием.
Спасибо!
-
7 часов назад, vlad сказал:
У меня воспроизводится ещё одна проблема, dns запросы пролетают мимо dnscrypt-proxy,в итоге сайт показывает заглушку провайдера.
Нужно проверить, работает ли приземление DNS запросов клиентов на роутер, например, командой
~ # iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1" Can't find library for target `CONNNDMMARK' -A PREROUTING -p udp -m udp --dport 53 -j DNAT --to-destination 192.168.1.1:53
Так же с помощью tcpdump host IP_проверяемого_девайса посмотреть куда именно проходят запросы, на какой сервер.
-
Обновился до релиза 2.14 и проблема резко обострилась.
Даже после перезагрузки роутер не доступен по KeenDNS FQDN.
Напомню, Запрос #400857
Селф будет ниже.
Большая просьба @Le ecureuil обратить внимание.
Спасибо!
- 1
-
@vlad @rotor я сегодня обновился до 2.14 релиза и подтверждаю проблему со скриптом приземления всех DNS запросов на резолвер роутера:
Дек 3 22:46:51 ndm Opkg::Manager: /opt/etc/ndm/netfilter.d/01-ClientDNS-Redirect.sh: Can't find library for target `CONNNDMMARK'.
Взываю на помощь @Александр Рыжов и @Le ecureuil
Каких-то библиотек не находит простой скрипт
#!/bin/sh [ "$type" == "ip6tables" ] && exit 0 [ "$table" != "nat" ] && exit 0 [ -z "$(iptables-save | grep " --dport 53 -j DNAT --to-destination 192.168.1.1")" ] && iptables -t nat -I PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.1:53 exit 0
- 1
- 2
-
@Le ecureuil @eralde ок, если это by design, то тему, думаю, можно закрывать. Спасибо за объяснения.
-
4 минуты назад, r13 сказал:
не не не Девид Блейн, еще в 2.11 было
Действительно, начиная с версии 2.11.A.6.0-0 где явно указано, что защита от перебора https есть.
-
Тоже считаю, что защищать http, но не защищать https, который keenetic os даёт из коробки (за что огромное спасибо, это большая работа) это весьма странно.
- 1
-
-
В 06.11.2018 в 21:27, vlads сказал:
Как сообщить dnscrypt-proxy что lib нужно искать в [sources.'opennic']?
В общем, именно так реализовать вряд ли получится. Так как зону lib умеют разрешать ТОЛЬКО серверы проекта OpenNIC, то только у них и нужно спрашивать об этой зоне. Если использовать общий список серверов, который так же включает в себя серверы opennic, то разрешить узлы зоны lib скорее всего не получится, так как есть гораздо более быстрые серверы, которые и будут отвечать на ваши запросы, а они в свою очередь ничего не знают про зону lib. Поэтому решением в лоб будет использовать только серверы opennic (я именно так и делаю).
Так же можно решить это проблему средствами dnsmasq (как вы и указали) или же средствами самого dnscrypt-proxy (я имею ввиду forwarding). Но в обоих случаях, насколько я понимаю, будут выполняться обычные dns запросы, а не dnscrypt шифрованные запросы.
-
По сообщению коллег из технической поддержки, на их экземпляре смартфона моей модели никаких проблем с воспроизведением видео историй в Инстаргам с включенным блютузом нет, что на самом деле очень странно, так как в гостях были друзья с таким же смартфоном и проблема проявлялась стабильно. Но тем не менее, было решено, что это у меня с женой такие не удачные образцы смартфонов и проблемы как таковой нет.
Да и у меня за все время решения данной проблемы теперь есть, как говорят заокеанские коллеги, workaround в виде выключения блютуза дома для супруги и использования только 5ГГц точки для меня.
На этом тему можно считать закрытой, хоть и не решенной. Если кто-то все же столкнется с такой же или подобной проблемой на своем девайсе, желаю удачи?
-
В 23.10.2018 в 02:47, sergeyk сказал:
Во всех протестированных сценариях были одинаковыми канал, ширина полосы, расстояние между клиентом и точкой, а также мощность сигнала?
Сейчас по запросу ТП проверил воспроизведение проблемы по своему алгоритму на всех каналах 1-2-3-4-5-6-7-8-9-10-11-12-13 и абсолютно на всех были зависания более 5 секунд. Переключался на следующий тестируемый канал после того как "ловил" зависание секунд в 5-10.
Кстати, начиная с 12 канала мой внешний адаптер Alfa AWUS036NH на роутбуке уже не мог подключиться к роутеру, поэтому с 12 на 13 канал пришлось менять на тестируемом смартфоне - Xiaomi Redmi Note 4X Snapdragon 4\64 через браузер.Так же еще по статистике данной проблемы, проверил лично у родственников на их роутере от Ростелекома Eltex NTU-RG-1402G-W - проблема воспроизводится. Ранее мне жена говорила, что не замечала на нем проблем. В посте со статистикой информация обновил.
-
На самом деле это странный баг/фича. Всегда использовал шифрование ещё с времён дефолтного интерфейса transmission, наверное, на 2.06 и всё качало/раздавало. Даже было видно, что все соединения с замочком (шифрованы). А сейчас при включении обязательного шифрования transmission просто не качает. Имхо, так быть не должно.
Загрузка процессора около 10-15%
in 2.15
Posted
Сейчас посмотрел, теперь тоже все в норме.
Загрузка прошла. В top теперь все чаще в топе процесс ndm с 0.5-2 по CPU
Теперь мой вопрос к разработчикам (и знающим), а что это за процесс такой /bin/nqcs? За что он отвечает? и Что это за процесс (в смысле какое действие) мог быть?