Mkdlk5

Рад видеть! Спасибо. Буду знать - для выбора в соответствующем случае. В отношении активного Keenetic списка хостов. Если я верно понял вопрос: arp говорит, что хост светится... Но позволю себе напомнить, что проблема с транзитом pptp после перепрошивки из файла и последующего обновления из Вашего репозитория изволила исчезнуть. И на текущий момент "мы так и не знаем, чем Вы болели".

То, что "неофициальная поддержка" и развитие имеет быть, уже очень много. И дай ей бог разобраться и починить, если сможет и когда сможет.

Я тут человек новый. Простодушно исполнил правило "нашел багу - напиши". Не следовало?

😉.. и думатель? Аппаратик очень устраивает. Иначе бы столько лет не пользовался. И дефект прошивки обнаруженный здесь бы не расписывал. На ARM не переманивайте, для случая качать и нагружать ARM Ксеону не товарищ. Лучше поддержите запрос проверить - исправить прошивку.

Верно подсказывает ;). Кроме RDP бывают потребности погонять файлы обновлений некоторых справочных правовых систем. Это не жестко, но производительность компьютера действительно несколько выше, чем у устройства общей мощностью 12Вт. Но например, для редкого подключения с планшета - мобильного использую Кинетик.

Спасибо, буду знать! Но я увидел при копирование файлов через VPN IpSec Xauth, что один пользователь в один поток кладет мой Keenetic III на обе лопатки: 90-100% загрузка процессора, производительность 19MB. А пропуск транзитного pptp практически на скорости wan не нагружает процессор более, чем на 31%. А сервер внутри сети при обработке соединения показывает рост нагрузки в пределах 1%. Сделал вывод, что если внутри сети есть включенный 24/7 компьютер, лучше входящие VPN соединения серверить ему. В новых Кинетиках, возможно, все иначе. Однако для ненагружающих задач встроенным серверам Кинетика цены нет. За что и любим

После обновления на 2.11.D.10.0-2 пытался использовать встроенный pptp-сервер. После выяснения, что он работает только с 40-битными ключами и любому клиенту потребуется вносить изменения в реестр, предпочел вернуться на pptp сервер внутри локальной сети. Вот тут-то и обнаружилось, что порт 1723 при отключении встроенного pptp сервера снаружи перестает быть доступен. Пробное удаление - возвращение компонентов pptp сервер и ALG (pptp) к решению не привело, снаружи порт по-прежнему был недоступен. С помощью поддержки в селф-тесте была обнаружена аномалия: Пересоздание которых через web-интерфейс, как выяснилось, эффекта (открытия порта) не дает. А вот команда ip static tcp PPPoE0 1723 [ip address] - эффект дала. Дефект воспроизводился устойчиво, многократно.

Описанный дефект исчез после понижения версии прошивки загрузкой из файла до 2.11.D.10.0-1. Далее для меня неясное. Выполнил через cli удаление компонента dvb - тюнера. Компонент обновился, автоматически обновилась и версия NDM до 2.11.D.10.0-2. После этого обновления управление пробросом порта (во всяком случае, ip порта) через web - интерфейс работает добросовестно! Конечно, хорошо что роутер работает на самой свежей версии прошивки. Но почему устойчивый отказ исчез? Кто - нибудь может объяснить, как такое возможно? Mkdlk5.

Приветствую! после обновления прошивки с 2.11.D.10/0-1 перестал работать, но по-прежнему исправно демонстрируетсяся в web как действующий проброс tcp порта 1723. Многократные удаления - внесения вручную через web - интерфейс правила проброса портов и попытки решить проблему внесением вручную соответствующих правил фейрволла, а также игры с переустановкой связанных с pptp приложений к успеху не привели. Решить проблему удалось внесением правила проброса порта из cli. С уважением, Mkdlk5.