Le ecureuil

Ну раз так, чем вас не устраивает usb power-cycle в 1:10 например, и в 7:10? И запускать торренты в 1:20, а тормозить в 6:50?

Напоминалка тем, кто потом будет жаловаться почему считает неправильно

Когда я пару лет сидел на LTE от Мегафона с ночным безлимитом, я не рвал никакие соединения. (Это в ЦФО). Просто настраивал потребителей трафика запускаться в 1:30, с принудительным остановом в 6:30, однако они никаким образом не были связаны с роутером и его настройками. И все, никакие разрывы не требовались. Где это там такой идиотизм, что биллинг после 1:00 продолжает считать по-старому без разрыва сессии? Объективные доказательства есть?

Сразу вангую, что не будет считаться трафик, проходящий по PPE.

interface usb power-cycle у вас уже есть много лет, про это уже было написано в теме.

Лишняя работа по переносу кода между ветками и тестирование. Плюс после выхода stable-версии (с буквой C) привнесение в нее нового функционала, требующего новых тестов практически запрещено.

Может, любой Keenetic проектируется так, что на любом USB-порту NDMS может управлять питанием.

В теории именно "последовательную закачку" можно перенести в 2.84. Создавайте тему в развитии, если народ поддержит - возможно сделаю.

@Finish25 @JIABP AUTH_ERR говорит о потере пакетов или об их повреждении при передаче через сеть.

Прямо сейчас это невозможно.

Попробуйте отключить все ускорения как сказано в первом посте:

MTU есть, но на интерфейсах (собственно, по ссылке так и говорят). А у IPsec XFRM нет интерфейсов.

Что там у вас с ppe?

Это не заработает. + вы 100% не сможете inherit lo сделать.

Такая опция была в прошивочной ветке 2.92 (называлась "последовательная закачка"), которую все забраковали и потребовали возврата на 2.84.

MTU у IPsec канала не бывает. Эта настройка включает подстройку TCP MSS согласно MTU на WAN.

Фраза "официальный ответ" и этот форум не могут существовать вместе - или одно, или другое.

Такой вывод вы можете сделать и без нашего ответа

"Машина уже в пути" Никак руки не доходят, но записано и однозначно скоро будет сделано.

У вас тут в этой схеме вообще маршрутизация похоже не нужна, все клиенты роутер2 должны принадлежать к одному L2-домену LAN-сегмента роутер1, и соответственно оттуда получать адреса.

Напишите лучше отзыв на google play, это однозначно дойдет до непосредственных разработчиков, причем быстрее и надежнее

ebtables есть в Entware или в Debian.

Нет никакого глобального заговора "модности и молодежности". Ответ-то проще, надо только подумать и посмотреть по сторонам. Я отвечаю за ipsec и туннели и присутствую на этом форуме, потому лично мне это важно и интересно, потому об этом здесь много обсуждения и вообще движухи. Вон представители команды dect тоже тут есть, и активны, и у них в темах постоянная движуха тоже есть. Те же, кто делают шейперы, intelliqos, igmp, фильтрации, мобильное приложение, wifi и прочее - их на форуме нет (ну или почти нет, @Padavan например появляется раз в неделю), он им неинтересен от слова "вообще". Они работают по ТЗ и обратной связи из других источников, хотя медленно, но верно ваши хотелки туда тоже передаются (естественно в устной форме "для сведения"). Потому никто и не реагирует на ваши темы.

Средствами NDMS невозможно, однако через Opkg есть возможность взять ebtables в свои руки и подкрутить - модули ядра для него лежат в пакете opkg-kmod-netfilter.

В данной теме multiwan - это маршрут по умолчанию на несколько интерфейсов, о другом тут вроде и не говорят.