Le ecureuil

Здесь все довольно плохо из-за существования ppe hardware и ppe software, а также fastnat с которых снимать статистику довольно проблематично. Можем добавить сам модуль ядра ip-netflow в пакет opkg-kmod-netfilter, при этом вы сами отключите абсолютно все ускорители (подскажем как, но максимальные скорости будут конечно на порядок ниже) и настроите userspace через entware или debian - так вас устроит? Все остальное требует очень кропотливой нашей работы, и будущее этого туманно.

Обсуждается здесь:

Ну так и используйте P660 или UPnP. У нас другая реализация SNMP, скорее всего просто плохо подходящая вам или вашей утилите для сбора статистики. Попробуйте в ней увеличить интервал опроса, а мы пока подумаем над решением вашей проблемы.

Да, это так и должно быть при непрерывном опросе по snmp. Ну и собственно вам автор утилиты все ответил про причину такого графика.

Пока нет, но создайте отдельную тему и подумаем вместе над реализацией.

Zabbix server? Да вы батенька....

Наш transmission 2.92 это уже давно умеет (последовательная загрузка), патч для него применен.

Там более старое ядро, и это имеет свои тонкости, но в целом основные фичи должны работать.

С чего вы взяли? у RT6856 точно такой же блок аппаратного шифрования EIP93, доступен в прошивке 2.06 через те же самые команды.

Пока интерфейсы, которые являются концами VPN-подключений у VPN-сервера, никак не обрабатываются в прошивке, потому управлять и снимать с них статистику невозможно. Однако мы поставим эту задачу в план, и посмотрим в будущем как ее можно решить.

На Ultra II с аппаратным шифрованием IPsec показал 350 Мбит/сек, PPTP же в аналогичных условиях на этой железке - 70..80 Мбит/сек

В некоторых младших тоже - Start II, Lite III rev B и 4G rev B (устройства на MT7628) тоже умеют аппаратное шифрование AES.

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

Используйте команду schedule по описанию: Вам нужно создать schedule со временем, которое вы желаете для работы основного канала (там, где ip global выше), и применить его к этому интерфейсу. В таком случае интерфейс с большим приоритетом будет "гаситься" согласно расписанию, и все будет работать по резервному каналу, по приходу времени все опять будет возвращаться на основной канал.

Вас брутфорсят. Эти записи мы специально не скрываем, чтобы вы знали о факте перебора паролей и о том, насколько упорно это делается. Однако вы сами можете их скрыть через system log suppress nginx или же забанив эти IP в межсетевом экране.

Сейчас на 2.07 и 2.08 такие настройки: - между любыми запросами при ответе HTTP/401 - интервал 300 мс, которые выдерживает nginx и не отдает данные. Это для защиты от тупого refresh страницы с 401 ответом и DоS в результате. - если учетные даннные неверны, или такого юзера вообще нет в системе - то задержка перед выдачей HTTP/401 составляет 3000 мс, что достаточно, чтобы защитить от брутфорса, если у вас стоит нормальный пароль. Такими темпами (0,33 в секунду максимум) их будут перебирать дооооолго. Еще можно попробовать включить ограничение на число коннектов с одного IP на nginx, но тут нужно быть аккуратным, чтобы не зарезать случаем нормальную пользовательскую активность.

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

Если сами маршрутизаторы пингуются - значит все отлично и должно работать без всяких дополнительных прописываний маршрутизаций. Единственной проблемой может быть то, что на хостах за маршрутизаторами в качестве шлюза по умолчанию не указаны именно эти маршрутизаторы, которые соединены IPsec VPN. Проверьте это.

В теории кроме service snmp можно вообще ничего не делать. Community по умолчанию - и так public.

Александру респект за debian, сегодня проверил на ultra II, работает чудесно!

Там использовался другой http-сервер, в 2.07 и выше используется nginx.

Сейчас проверил Safari из OS X El Capitan (10.11), все отлично. И через my.keenetic.net, и через 192.168.1.1, и через SSL, и через plaintext. Похоже, что-то не то с настройками Safari. Нужны либо подробности, либо снимите через wireshark на os x дамп пакетов когда не пускает на web.

Сходу подсказываю, что неправильно создана тема. Насчет 1 (N-greenfield) нужно создавать отдельную тему и набирать голоса, тут все может быть сделано. Насчет 2 - была вкладка про "Клиенты WiFi", трагическую историю с ней вполне можно прочитать в соседней теме, зачем дублирование? Насчет 3 - тоже нужно создавать отдельную тему. Вывод: по каждой из фич, которые вы хотите, нужно создавать отдельные темы в этом разделе; барахтаться в болоте из 20 предложений и их одновременного обсуждения никто не хочет.

На 2.06 @ 2.6.22 не были до конца включены алгоритмы для multipath. В следующей пятничной сборке все должно быть, перепроверьте на ней. Не работает в смысле "Не поднимаются два соединения" или в смысле что невозможно через ip route добавить команду и не идут пакеты?

В плане реализация недостающих фич в ndmq, чтобы вытаскивать нужные данные из ndm. Кстати необязательно указывать gateway, можно указывать просто dev - сетевое устройство как назначение. На мой взгляд чтобы понять кто у нас wan - это нужно сначала через configuration-request запросить у ndmq на каких интерфейсах ip global > 0 и какие из них в состоянии enabled, и затем оттуда опять запросом через ndmq узнать их системное имя, и уже эти системные имена использовать в скрипте. В итоге все будет автоматически работать, если веса равные на шлюзах.