Le ecureuil

с чего вдруг они должны отключаться?)на других роутерах они не отключаются и всё нормально)здесь же на гиге2 жор бешеный) я знаю,что есть функции на телефоне wifi в спящем режиме "не выключать,только при питании от сети,всегда выключать" И смысл мне отключать,если роутер не должен запросы отправлять так часто на смартфон?другие роутеры не отправляют же и спокойно спят На Keenetic II, Ultra и Giga II используется очень древний по современным меркам чип WiFi (2010 года разработки), поддержка драйвера производителем давно закончена. Потому приходится подтыкать тут и там нетрадиционными методами

А с чем это связано? Развитие прошивки версии 2.05 законечно, готовится официальный релиз 2.06 для Giga II, Keenetic II и Ultra. Потому нет смысла перетаскивать это в устаревшую версию, которая скоро уйдет на покой. Если вы сидите на 2.05 из-за того, что вас что-то не устраивает в 2.06, то лучше помогите нам это поправить, чтобы всем была польза.

В свежем билде 2.06 в пятницу (10.06.2016) этот флаг везде по умолчанию будет взведен в 1.

А в 2.07 такая команда появится? Есть с самого рождения.

Нет, скорее всего пробел или другой непечатный символ перед "no". Попробуйте ввести руками, без копирования. (config)> no ppe software Command::Base error[7405602]: argument parse error. без изменений! а это сильно может повлиять на трафик? мне, в принципе, нужен примерный подсчет куда стрелять Тогда попробуйте так > system set net.core.swnat 0 > system configuration save Если и тут будет ошибка, то значит программного ускорителя нет и все будет хорошо. Повлиять может очень сильно, вплоть до того, что трафик не будет захватываться через pcap и утилиты будут показывать погоду на Марсе.

В консоли ndmc, которая доступна через telnet. Спасибочки вроди все вышло! (config)> no ppe hardware Network::Interface::Rtx::Ppe: Hardware PPE disabled. (config)> no ppe software Command::Base error[7405602]: argument parse error. (config)> system set net.ipv4.netfilter.ip_conntrack_fastnat 0 FileSystem::Proc: System setting saved. (config)> system configuration save Core::ConfigurationSaver: Saving configuration... Base error[7405602] это наверно потому что он уже выключен? Нет, скорее всего пробел или другой непечатный символ перед "no". Попробуйте ввести руками, без копирования.

Точное значение не помню, но буквально минуты, что конечно очень безопасно, но вызывает расход батарей.

В пятницу (10.06.2016) выйдет очередная тестовая draft прошивка 2.06 для Giga II, попробуйте поставить ее. В ней появилась команда > interface WifiMaster0 rekey-interval 3600 которая позволяет задать интервал пересогласования сессионных ключей и которая заметно улучшает время жизни подключенных устройств. Попробуйте задать значение в 3600 или 7200, что означает время в секундах (раз в час или в два). Слишком большое время тоже ставить не стоит из-за опасности проведения атаки на шифрование посредством собирания большого количества пакетов с одним сессионным ключом. После этого не забудьте сохранить настройки через >system configuration save В 2.05 такой команды нет и добавление не планируется.

Как то не понимаю где писать эти команды? в ssh не то. В консоли ndmc, которая доступна через telnet.

3 июня в этой теме я уже отвечал, что в 2.06 для Giga II уже есть поддержка. Нужно поставить прошивку 2.06 с этого форума, из темы "Тестирование 2.06".

Giga II очень массовое устройство, и как бы нам не было сложно, приходится на него тащить многие вещи

Пока пробросить порты и использовать IPsec для выхода в Интернет невозможно (это касается особенностей реализации), но в следующие полгода возможно будут подвижки в эту сторону.

Нужно обязательно пробросить 500/UDP и 4500/UDP. 50/UDP не нужен. При этом обязательно нужно использовать в качестве идентификаторов сторон не IP-адреса, а FQDN или e-mail идентификаторы, в противном случае работать не будет.

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

Если используете решения из Entware полностью отключите все ускорялки через команды: > no ppe hardware > no ppe software > system set net.ipv4.netfilter.ip_conntrack_fastnat 0 > system configuration save При этом весь трафик будет идти через обычный netfilter, это будет заметно медленнее (и отжирать больше ЦПУ), но зато все счетчики будут работать максимально корректно.

Ну что ж ладно, благо руки есть интернет под боком так же, да и роутеров в продаже по боле, а не один только вид. Только вот еще есть один "антиквариат" http://www.allnet.de/de/allnet-brand/pr ... an-router/ на железе с RT6856, в котором функций по более. - Hardware: MTK RT6856-700MHz; 16MB Flash; 128MB DRAM - Schnittstellen: 1~2x WAN Port 3~4x LAN 10/100 Mbps RJ45 - QoS Bandbreitenmanagement: Smart QoS; Bandwidth Management; Session Control by IP - L7 Management: L7 Management Blocking; VIP Priority Channel; L7 QoS - NAT: One-to-One NAT/DMZ/Virtual Server; UPnP Support; Static Routing - Firewall: SPI/DoS Detect; Attack Logging; Access Control; URL/Keyword Filter - DDNS: DynDNS; NO-IP Если взять GPL то можно увидеть ядро на 2.6.36МТ.х и так же : tc (точнее соответствующая ему ядерная часть) есть и в 2.6.22, и в 2.6.36, и в 3.4. В этом ни у кого нет сомнений. Что сказать-то хотели?

Это тупой пропуск Ethernet-фреймов c Ethertype 0x86DD (IPv6) с одного интерфейса на другой и обратно. IPv6 Firewall в этом не участвует.

Например так как на скрине. Вопрос только это все реализовывается через сервис "tc" => но его нет ? tc qdisc add dev root handle 1: htb default 30 tc class add dev $WAN parent 1: classid 1:1 htb rate ${UP}kbit prio 1 quantum 1518 (MTU+18) tc class add dev $WAN parent 1:1 classid 1:100 htb rate ${UP}kbit prio 1 quantum 1518 tc class add dev $WAN parent 1:1 classid 1:2 htb rate ${UP}kbit prio 3 quantum 1518 tc class add dev $WAN parent 1:2 classid 1:10 htb rate $((70*${UP}/100))kbit ceil ${UL}kbit prio 3 quantum 1518 ... tc filter add dev $WAN protocol ip pref 1 handle 0x64 fw classid 1:100 tc filter add dev $WAN protocol ip pref 3 handle 0x0A fw classid 1:10 ... tc qdisc add dev $5 root handle 1: htb default 30 tc class add dev $imq_wan parent 1: classid 1:1 htb rate ${DW}kbit prio 1 quantum 1518 tc class add dev $imq_wan parent 1:1 classid 1:100 htb rate ${DW}kbit prio 1 quantum 1518 tc class add dev $imq_wan parent 1:1 classid 1:2 htb rate ${DW}kbit prio 3 quantum 1518 tc class add dev $imq_wan parent 1:2 classid 1:10 htb rate $((70*${DW}/100))kbit ceil ${DW}kbit prio 3 quantum 1518 ... tc filter add dev $imq_wan protocol ip pref 1 handle 0x64 fw classid 1:100 tc filter add dev $imq_wan protocol ip pref 3 handle 0x0A fw classid 1:10 ... Превосходно, что вы раскопали tc, однако он не решает проблему, указанную пользователем в первом посте. Трафик от провайдера все равно будет идти на полной скорости, и только потом уже в роутере будет дропаться/приоритезироваться. В итоге самая главная проблема - перегрузка канала на download - никак не решена, только создается видимость наличия ограничений для пользователя, при том что кино все равно будет лагать. И вторая по важности проблема - простая для пользователя настройка - тоже никак не вяжется с tc. Для его успешной работы все параметры надо подбирать для каждого провайдерского канала индивидуально, иначе он либо не будет работать, либо будет это делать сильно неэффективно. Если так хочется - в entware есть tc, флаг вам в руки.

Что такое "l2tp шифрование"? Что такое "ему подобное"? запятую пропустил, а насчет ему подобного ipsec не не слышал?? Не, вы что, вообще в первый раз все эти слова вижу.

Может не надо валить все на провайдера. Жду конструктивных предложений по эффективной и простой для настройки со стороны пользователя реализации этой фичи.

Я уже ранее предлагал нечто подобное. Увы никакого ответа от многоуважаемых мною разработчиков не последовало Еще раз повторю: мы не решаем как будет выглядеть web и какова будет его функциональность. Какого же вы ответа хотите услышать?

А какова вероятность того, что у провайдера стоят "нужные крыжики в нужных местах"? Или там должно быть что-то более сложное чем "включить опцию в нужном окошке"? Да, куда более сложное, именно поэтому подобных фич нигде нет (или они работают в несколько другом виде, который вообще говоря крайне неоптимален). Единственное, на что провайдеры ставят TOS-флаги в IP-пакетах - это на мультикаст IPTV. И все.

Реализация подобной фичи требует участия со стороны провайдера, иначе это неэффективно. Сделать приоритезацию на download практически невозможно.

Сперва опишите формальные критерии, по которым железка будет понимать что вот этот пакет - плохой, и его не нужно пропукать, а вот этот - хороший, поскольку предназначается компу в локальной сети для браузера (например). Причем критерии должны быть невероятно "дешевы" вычислительно.

Уже вышла, в текущей 2.06 с keenopt присутствует компонент DECT.