Le ecureuil

Вы не пытались проанализировать контекст выполнения всех этих операций? 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 на роутере - это стрельба из пушек по воробьям.

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

Подскажите, а где найти указанную прошивку? Ставите любой experimental/draft от июня и обновляетесь через страницу "Компоненты".

Должно быть поправлено в ближайших билдах.

Похоже на правду. Можете еще использовать хуки в /opt/etc/ndm/fs.d для получения событий о монтировании и размонтировании ФС: https://github.com/ndmsystems/packages/ ... -Component

Берете entware, ставите iproute2, и вводите: # ip route add table 50 default via dev pppX (ваше l2tp-соединение) # ip rule add from /32 table 50 Вроде как и все

Как у вас ситуация на свежем draft от 1 июля?

А зайти на любой другой хост из удаленной сети получается?

"Машина уже в пути" (ц)

В conntrack попадает весь транзитный L3 трафик, но между хостами в локалке L2. Поясните, пожалуйста, с примером, что загоняется конкретно. как минимум там трафик к самой точке, мультикаст из локалки, и был трафик от NAS подключенного по зернету (сейчас нету, но видел) root@Keenetic_Giga:/opt/root# grep src=192.168.1. /proc/net/nf_conntrack | grep dst=192.168 ipv4 2 udp 17 16 src=192.168.1.36 dst=192.168.1.1 sport=57476 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57476 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 12 src=192.168.1.36 dst=192.168.1.1 sport=57458 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57458 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 14 src=192.168.1.36 dst=192.168.1.1 sport=52105 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=52105 mark=0 nfm_marker = 0 use=2 ipv4 2 unknown 2 431 src=192.168.1.36 dst=224.0.0.2 [uNREPLIED] src=224.0.0.2 dst=192.168.1.36 mark=0 nfm_marker = 0 use=2 ipv4 2 unknown 2 582 src=192.168.1.2 dst=224.0.0.22 [uNREPLIED] src=224.0.0.22 dst=192.168.1.2 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 4 src=192.168.1.36 dst=192.168.1.1 sport=55056 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=55056 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 28 src=192.168.1.36 dst=192.168.1.1 sport=50030 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50030 mark=0 nfm_marker = 0 use=2 ipv4 2 tcp 6 1199 ESTABLISHED src=192.168.1.34 dst=192.168.1.1 sport=50850 dport=22 src=192.168.1.1 dst=192.168.1.34 sport=22 dport=50850 [ASSURED] mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=50763 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50763 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=57699 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57699 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 10 src=192.168.1.34 dst=192.168.1.1 sport=58345 dport=53 src=192.168.1.1 dst=192.168.1.34 sport=53 dport=58345 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 12 src=192.168.1.33 dst=192.168.1.1 sport=57291 dport=53 src=192.168.1.1 dst=192.168.1.33 sport=53 dport=57291 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 9 src=192.168.1.1 dst=192.168.1.255 sport=138 dport=138 [uNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=138 dport=138 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 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 udp 17 3 src=192.168.1.36 dst=192.168.1.1 sport=49447 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=49447 mark=0 nfm_marker = 0 use=2 ipv4 2 udp 17 11 src=192.168.1.36 dst=192.168.1.1 sport=54243 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=54243 mark=0 nfm_marker = 0 use=2 скорее всего в конфете ядра забыто проверять локальный трафик. А это потребление памяти - которого можно избежать без потери функциональности. В этом нет ничего страшного, и это необходимо для работы ip hotspot.

Удалите settings.json с usb-диска.

Не наглейте DNS и http трафик точно не будут включены в обозримом будущем, поскольку в случае с http вступают в роль ppe software и ppe hardware. Второй вообще невозможно настроить на мониторинг трафика по UDP/TCP портам, так как он аппаратный.

Интерфейсы будут без сомнения.

Хотелось бы уточнить, в данном ограничении учитываются только IPsec-туннели, или же L2TPoverIPsec тоже считаются? На данный момент есть два IPsec-туннеля между кинетиками, + туннель на OpenVPN, который думаю перевести на L2TPoverIPSec ради повышения производительности (кстати, он же тоже использует crypto engine hardware?). Дополнительно вопрос - по-умолчанию домашние адреса будут натироваться в L2TPoverIPSec? Как я понимаю, инструкция по предотвращению натирования аналогична https://zyxel.ru/kb/3252/ - но она работает только если есть один WAN со статическим IP? А что делать в случае с динамическим IP и/или резервированием? L2TPoverIPSec не считаются. Использует crypto engine hardware. В скором времени функция будет немного переделана, изменится и конфигурация, будьте внимательны. Да, отключение NAT делается именно как в статье, и работает только для статического IP. Для динамического (по крайней мере пока) нет.

Есть идеи по реализации в ближайшие полгода (а может и раньше, но загадывать не будем, понятно, что пользователи draft-прошивок все получат первыми ) (по состоянию примерно как в посте viewtopic.php?p=5951#p5951 ), если кто еще что напишет - постараемся принять к сведению. Сейчас самая очевидная проблема - при реализации статуса портов свича на устройствах с MT7628 (то есть Start II) не будет расширенной статистики (навроде сколько на каждом порту принято/отправлено байт, ошибок, мультикастных пакетов, коллизий - все эти параметры будут присутствовать, но будут равны нулю). Он позволяет получить только информацию о количестве пройденных RT/TX пакетов. На остальных устройствах сильных сложностей не предвидится..

Эта строка называется "shebang", и правильное ее написание таково: #!/bin/sh У вас же пропущен символ '#' в начале, потому некорректно работает.

Пока нет, пользуйтесь Opkg/Entware.

У процессора роутера в отличие от компьютерного нет расширенных режимов энергосбережения и ACPI, который используется для отключения системы. Он может только жарить на 100%, и все. А из-за отсутствия ACPI (или его аналога) программное управление питанием системы не предусмотрено (кроме USB-портов, где можно снять / подать питание).