Le ecureuil

Так сразу и скажите. Возможно, сотрудник техподдержки просто еще не успел до меня дойти с вашей ситуацией - они же не бегают к нам по каждому звонку и письму от пользователей.

Ломать не стоит, но если еще будут какие-либо вопросы - сразу снимайте self-test и сюда, здесь разберемся уже нужен он был или нет.

Если у вас такая необходимость в IKEv1, то вам придется перейти на IP-адреса в качестве идентификаторов, если вы хотите принимать сразу несколько туннелей с разными настройками. А вообще неплохо бы и self-test с описанием в какое время что делалось, а то гадание на воде к хорошему не приводит.

Какой из интерфейсов (по названию EoIPX) отвалился в данном self-test?

iso9660 и udf не собираются по умолчанию: Добавить их в ndm-opkg-kmod-fs?

Уже сто раз обсуждалось, но давайте подведу вам чеклист того, что нужно сделать в порядке убывания степени важности: - если есть возможность, используйте только IKEv2 со строковыми уникальными идентификаторами Email/DN/FQDN. Никаких IKEv1, о нем стоит забыть, если только не стоит цель в совместимости с другими пирами, которые невозможно перенастроить / обновить. - если есть возможность, не настраивайте другие IPsec-сервисы (даже клиентские) на этих марштуризаторах - чем больше вы их "навесите", тем сложнее вам будет разгребать проблемы с совместимостью. - если есть возможность, ставьте 2.12. По результату будем смотреть.

А написать о проблемах и приложить self-test не судьба? Сейчас сделано все, что можно для сохранения совместимости как с модемами, так и с другими устройствами. Баланс можно сместить в любую из сторон - но все равно останутся недовольные.

На Extra II работает вроде.

Вот так сразу и спрашивайте. wget -qO - http://127.0.0.1:79/rci/ip/hotspot/policy а затем можно утилитой jq обработать: http://keenetic-gi.ga/2017/06/28/core-interaction.html

В show running-config можно увидеть.

Ок, подумаем.

Да, я помню, но приоритет низкий Когда-нибудь доберемся.

Да

На мой взгляд, rtorrent в стандартной поставке нам не подходит по ряду причин: 1 - написан на C++, а значит нужно тащить STL - очень жирная для роутеров начального уровня либа. 2 - не имеет нормального headless-варианта, а значит нужно костылить с tmux/screen/своей реализацией, что опять-таки нас отсылает к пункту 1. Хотя, у pyroscope-ps вроде есть headless-патчи, но я не проверял как они работают. 3 - не имеет официального web-интерфейса, а значит нужно тащить что-то типа rutorrent, а значит нужно тащить к себе PHP - ну сами понимаете, все как в пункте 1. 4 - официальная ветка только недавно с горем пополам научилась в IPv6, и то, только потому, что основной разработчик rtorrent скажем так, немного своеобразный человек, и ему плевать на проект. Лично я ему присылал PR с работающим IPv6, но он его не принял, а через год начал сам костылить из патчей в Интернете (которые имеют много проблем), и спустя пару лет таки дотащил это до мастера (почитать и поржать можно тут: https://github.com/rakshasa/rtorrent/issues/59 ). Еще на предыдущем сайте, когда разработка велась на libtorrent.rakshasa.no, а не на гитхабе, тикет про поддержку IPv6 висел 5 лет, и он там постоянно писал "ПНХ" на тему IPv6. 5 - он не умеет в uTP. Не то, чтобы это была проблема, но тут многие жужжат, что "качает медленно". Так вот без uTP качать будет точно медленнее, потому что у большинства стоит transmission/utorrent, которые делают упор на uTP. 6 - судя по изменениям в git, проект не скончался, но стабилизировался очень сильно. По моим наблюдениям, года с 2009 Ракшасе стало пофигу на rtorrent, а брать его в свои руки на поддержку нам не хочется - там очень суровый код. 7 - из-за C++ памяти он тоже есть заметно больше в том же самом сценарии использования. Честно, уже с 2014 не слежу особо за судьбой этого проекта, возможно что-то уже не соответствует реальности, но до этого активно участвовал - наболело.

Он существует только в ОЗУ в процессе ndm.

Почти никак. Нужен syslog с внешним сохранением.

Кое-что поправил, возможно получшает.

Ping-check кэширует запросы в DNS, потому, если ему не удалось разрешить домен - он будет использовать свой кэш до тех пор, пока ему не удастся разрешить домен или не перезагрузят. Хотите более надежный вариант - добавляйте исключительно IP-адреса. Хотя и в этом случае ответ всего лишь от одного сервера будет означать, что Интернет есть.

Нужен весь вывод syslog, в том числе и то, что случилось 25 тысяч секунд до этого куска. А версия прошивки-то хоть какая?

Наш веб сервер учитывает acl. Если вы для юзера через веб откроете только доступ к одному каталогу - то только туда у него он и будет.

http у вас и так уже есть: по адресу http://<router>/storage/ вы можете спокойно бродить по примонтированным дискам. Причем через https это тоже работает, и через keendns тоже, и пароль можно поставить.

Конечно можно, разве кто-то запрещает?

Наш отдел QA использует для тестов такой вызов: sudo sstpc --log-stderr --log-level 4 --tls-ext --user sstp --password sstp <servername> refuse-eap refuse-pap refuse-mschap require-mschap-v2 noauth noipdefault При этом в /etc/ppp/chap-secrets: # Secrets for authentication using CHAP # client server secret IP addresses sstp * sstp *

Наш отдел QA использует для тестов такой вызов: sudo sstpc --log-stderr --log-level 4 --tls-ext --user sstp --password sstp <servername> refuse-eap refuse-pap refuse-mschap require-mschap-v2 noauth noipdefault При этом в /etc/ppp/chap-secrets: # Secrets for authentication using CHAP # client server secret IP addresses sstp * sstp *

sstp-client у нас же используется в качестве клиента. Отменно работает. Что у вас не так, и как конфигурить в network-manager - понятия не имею.