Le ecureuil

HTTPS уже есть (правда с "левым" сертификатом) в 2.07. Выполняете в консоли > ip http ssl enable > system configuration save И можете заходить на 443 порт по https

Добрый день. Пока еще нет, разработка в процессе.

Для прошивок более старших, чем 2.07, функция ACL и прочие фичи не поддерживаются. Ок, файлы ".", "..", и другие начинающиеся с точки мы скроем, однако любой юзер имеющий доступ к Web в 2.06 и ниже будет иметь возможность лазить по дискам невзирая на ACL.

Какая версия прошивки и какая ФС на диске?

Если и будет реализовано, то в ближайшее время только в CLI.

Подождем еще немного голосов здесь, пока кроме вас никому не нужно Но вообще реализуемо при должном спросе.

На диске где выкидывает приложите self-test во время захода на диск + неплохо бы снять дамп пакетов через Wireshark на клиенте.

ipset добавлен, подробнее в теме про "Модули ядра для Opkg"

Нет, а смысл? И зачем так крупно?

В компонент ndm-opkg-kmod-netfilter добавлен ipset для всех версий 2.06 и 2.07. Можно пользоваться. Userspace утилита ipset4 (для 2.06) и ipset6 (для 2.07) присутствует в Entware.

В компонент ndm-mod-opkg-netfilter добавлен ipset, утилиты ipset4 (для 2.06) и ipset6 (для 2.07) присутствуют в Entware. Можно пользоваться.

Нет, названия интерфейсов останутся текущими. Понять что и где - легко. GigabitEthernet0 или FastEthernet0 - свитч GigabitEthernet0/X или FastEthernet0/X - порты свитча, от 0 до 4 там, где 5 портов, потом число возрастет до 7 на Ultra II. GigabitEthernet0/Vlan2 - VLAN номер 2 на свитче. В настройке по умолчанию GigabitEthernet0/Vlan1 - это LAN на свитче, GigabitEthernet0/Vlan2 - это WAN (он же ISP), а Bridge0 (он же Home) - мост между GigabitEthernet0/Vlan1 и AccessPoint0. Bridge1 (он же Guest) - гостевой VLAN / сегмент WiFi. Такой терминологии мы и будем придерживаться (как с CLI-мануале), привязки в системным linux-интерфейсам не будет. Колонку IP-адрес можно добавить, так и сделаем.

Это уже есть и работает, смотрите вывод snmpwalk внимательнее при подключенном диске.

Если скинете вывод snmpwalk с устройства, на котором мониторируется WiFi (другой марки, не ZyXEL), подумаем как можно и его сделать.

Пока "обкатываем" на Keenetic II, Giga II и Ultra на 2.06, но это обязательно появится в 2.07 на всех поддерживаемых устройствах.

ЭЭ.. вы не пытались систематизировать свои знания? iptables это утилита управления. Подсистема в ядре давно называется NetFilter, в данной подсистеме есть 2 части. xtables, и conntrack. В этом легко убедится если глянуть в конфигурацию ядра config NF_CONNTRACK tristate "Netfilter connection tracking support" и config NETFILTER_XTABLES tristate "Netfilter Xtables support (required for ip_tables)" Кроме того - вы давно делали профайлинг работы netfilter в ядре? особенно в случае нескольких тысяч соединений? Я смотрел не только в конфигурацию, но в и код, и не только смотрел, но и писал (ц) Потому мне не нужно рассказывать как там что устроено. Последний профайлинг был сделан в начале июня, и дал некоторое улучшение. А вообще мы не гонимся именно за суперпроизводительностью netfilter, поскольку у нас есть огромный арсенал средств программного и аппаратного ускорения трафика, который постоянно пополняется. Еще вопросы?

Вы не пытались проанализировать контекст выполнения всех этих операций? Linux kernel так и не научился обрабатывать пакеты в параллель, во всяком случае не в той версии ядра что у вас используется. Как раз таки по этому наличие второго CPU на этой железке никого не спасет. Пакеты в параллель обрабатываются на ура, в 3.4 уже есть RPS. Тут дело именно в драйвере WiFi от Mediatek. Если вы реально умеете анализировать контексты и профилировать драйверы, то почему вам не прийти бы к нам на работу, вместо бестолкового флуда на форуме?

Точно? ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2 ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2 224.0.0.0 является сетью для muticast если верить RFC. видимо у нас с вами разные multicast. То, что это мультикастные адреса, не делает их автоматически используемыми для передачи video-трафика. Этот адрес - 224.0.0.1 - вообще-то означает "Все хосты", и скорее всего используется для сигнализации mDNS, Zeroconf или miniDLNA.

это копейки. Простейший тест вам покажет что для загрузки одной странички с картинками любого сайта - надо 50-70 соединений. запустите скрипт $ while [ 1 ]; do lsof -n -i TCP | grep -v '*:*' | wc -l; lsof -n -i UDP | grep -v '*:*' | wc -l; sleep 0.5; done и походите по страничкам. news.yandex.ru дает 40 конектов, newsru.com - дает 80, открыл 3 страницы подряд - получил 120 конектов, открыл 4ю - получил 150... Открыл одноклассники еще прыжок на 120 соединений. И того активных 500 соединений, просто так. Дальше начинаем вспоминать что большинство браузеров не закрывают сразу сокеты и держат "а вдруг еще что-то потребуется". Это без всяких торрентов замечу. Это в случае использования http/1.0, которые плюс ко всему сразу же закрываются, а не висят постоянно. А вслучае использования http/1.1 к каждому из серверов создается одно отдельное перманентное соединение, а никак не 500.

Считаться будет также (берется все из одного места), потому это другая проблема и лечить ее нужно в теме "Тестирование 2.06". Насчет вывода CPU Usage: пока выводится только load average; CPU Usage, статистика по WiFi и многое другое появится чуть позже - не все сразу и в один заход

Рассматриваем добавление ipset в 2.06 и 2.07. Ожидайте, вероятнее всего в ближайших сборках будет.

Примерно так это выглядит:

вопрос больше не к памяти. 16к соединений много - но к примеру один торрент на NAS + 2 ноута в держат 2k соединений на роутере. То есть роутер даже в этих настройках потянет с десяток клиентов - не более. Сколько больше вопрос к CPU. Текущие настройки будут вынуждать прогонять весь мультикаст/броадкаст/мултикаст прокси через все iptables input правила. Пока трафик не большой - это ладно, а с ростом - получим съедание CPU. Достаточно лишь 4-5 клиентам начать смотреть видео через igmp proxy. К примеру - сейчас копирование файла с wifi на eth - съедает 30-32% в ksoftirqd (точнее не скажу - perf отсутствует в репозитории). А это время от iptables в том числе. Вообще-то у вас какая-то каша в голове. Во-первых, 2к соединений на хост это _ОЧЕНЬ_ много, говорить что десяток клиентов и все - это совершенное безумие. У вас на всех 10 клиентах запущен торрент с огромным числом раздач и пиров? Во-вторых, для multicast есть отдельный ускоритель, и пакеты с видео не идут через netfilter. В-третьих, при копировании с WiFi на Eth ЦПУ сильно грузится именно из-за полусофтовой реализации WiFi в драйверах, и мы плавно работаем над улучшением ситуации. iptables тут погоды не делает. В-четвертых не путайте iptables, netfilter и conntrack. Это разные вещи, они вступают в действие на разных этапах обработки пакетов и несут на себе разную нагрузку. Отключать conntrack на роутере - это стрельба из пушек по воробьям.

Пока не планируется.