sergeyk

Это значит, что в начале диска /dev/sdb есть разметка SWAP-раздела с magic "SWAPSPACE2" и UUID 1cbfca3f-dc6c-44ea-ab03-f75d9c605a7b, как видно из журнала.

Попробуйте удалить файлы .ndm-acl через shell, если стоит opkg.

@Rodstvennik63 Должно быть insmod /lib/modules/4.9-ndm-5/exportfs.ko а не insmod lib/modules/4.9-ndm-5/exportfs.ko

Поменяйте пароль (и возможно название) сети и включите её насовсем.

Напишите лучше в техподдержку с описанием конфигурации устройства, версии KeeneticOS, Windows и браузера.

Без конфигурации ничего не понятно. Я попробовал Yandex browser для Linux без каких-либо особенных настроек Keenetic, он без проблем выходит в интернет через 4.01.

Как в этом сценарии участвует OpenSSL на Keenetic? Соединение должно напрямую идти в интернет.

Как этот сценарий связан с OpenSSL роутера? Тут дело точно в чём-то другом, маршрутизация и NAT никак с OpenSSL роутера не связаны. К серверу на Keenetic? В этом случае может помочь захват и анализ трафика при попытке установки соединения.

Почему вы решили, что проблема в OpenSSL?

Это утверждение требует доказательств. Почему вы решили, что проблема не модеме, который потребляет больше стандарта при высоких сетевых нагрузках и слабом сигнале?

Такая функция не предусмотрена.

@severus у вас какое-то расписание срабатывает постоянно, отключая модем. [I] Dec 8 14:22:55 ndm: Network::Interface::Base: "UsbLte0": "ping-check" changed "ipv4" layer state "pending" to "running". [I] Dec 8 14:22:55 ndm: Network::InterfaceFlusher: flushed IPv4 UsbLte0 conntrack and route cache. [I] Dec 8 14:22:55 ndm: Core::Schedule::Manager: raised action "stop" by "schedule0". [I] Dec 8 14:22:55 ndm: Network::InternetChecker: Internet access detected. [I] Dec 8 14:23:03 kernel: usb 1-1: USB disconnect, device number 20

Не имеет значения. Можно через http://<ip>/a.

Он не уникален.

После появления нагрузки подождите минут пять, а затем посмотрите вывод "show configurator status". Там должна быть статистика по самым долго работающим командам.

У вас, похоже, есть какая-то открытая страница Web-интерфейса, которая опрашивает устройство и тем самым создаёт нагрузку. <thread> <name>SCGI Session /var/run/ndm.scgi.socket</name> <tid>24074</tid> <lock_list_complete>yes</lock_list_complete> <locks/> <backtrace> <calls> <![CDATA[]]> </calls> <error/> </backtrace> <statistics> <interval>6</interval> <cpu> <now>422456.840422</now> <min>18</min> <max>76</max> <avg>48</avg> <cur>76</cur> </cpu> </statistics> </thread>

Можете сами посмотреть в выводе команды "show processes" (её результат есть в self-test).

@keenet07 @k19olegh68 сохраните self-test на рабочей версии.

У ретрансляторов адрес по умолчанию — 192.168.1.3. Почему-то в настройках у вас оба клиента Wi-Fi отключены. Вы точно сбрасывали состояние перед захватом?

Без шифрования?

Сохраните self-test со Sprinter в таком состоянии.

У вас подозрительно выглядит адрес шлюза IPv6. Попробуйте отключить IPv6 в настройках WAN-подключения. Устройство напрямую к провайдеру поключено?

Ставьте регион US для 5 ГГц.

Сделайте захват пакетов, в них же всё видно.

Какими, например?