Le ecureuil

Все довольно стандарно - поищите plz в инете инструкцию к mjpg-streamer, у нас пока руки не доходят написать расширенные мануалы.

2. Разумная цена при отличной картинке. Какие условия съемки? Ночь / день? Какое разрешение нужно? чем будет обрабатываться поток: mjpg-streamer или motion? Я бы еще в требования добавил аппаратную поддержку MJPG.

В консоли Keenetic Ultra II, который является dhcp relay? Просьба приложить ошибки в режиме system debug, без этого ничего подсказать не могу. Сегодня проверил работу также с release/renew на ubuntu 14.04 и windows 7 sp1. Оба они при команде release не отправляют вообще ничего, а при renew просто запрашивают новый адрес как ни в чем не бывало в рамках новой dhcp-транзакции, и никаких ошибок не появляется.

Несмотря на некоторую нестандартность, ваша схема была проверена на прошивке A7 (http://files.keenopt.ru/firmware/Keenetic_Ultra_II/2015-12-05/), и все работает - и с Bridge2, и с других бриджей запросы достигают DHCP сервера через relay и клиенты получают ответ в обоих подсетях. DHCP-сервер был настроен на отдельной машине (в его роли выступал udhcpd, практически в дефолте). Тем не менее, во время тестирования выявились проблемы с настройкой вашей схемы через web, что будет поправлено. Прилагаю self-test с нашего устройства во время тестирования, если вам интересно. self-test(4).txt.zip

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

self-test отвалился на полпути (бОльшая часть информации почему-то оказалась потеряна), если несложно сделайте его пожалуйста еще раз.

Несмотря на то, что нахожу вашу схему несколько необычной, ее тоже проверил: все работоспособно. Приклыдваю self-test роутера с подключенными двумя клиентами - один через IPoE WAN с адреса 192.168.2.220 (IPoE WAN роутера 192.168.2.10) с внутренним адресом 172.16.1.33, другой через LAN (LAN подсеть роутера 192.168.5.0/24) с адреса 192.168.5.33 (внутренний адрес 172.16.1.34). Из этого self-test видно, что оба клиента успешно подключены, и в conntrack имеется запись tcp 6 1197 ESTABLISHED src=172.16.1.33 dst=172.16.1.34 sport=49185 dport=139 packets=1511 bytes=240011 src=172.16.1.34 dst=172.16.1.33 sport=139 dport=49185 packets=1982 bytes=1615365 [ASSURED] mark=0 use=2 Которая подтверждает успешный обмен данными между vpn-клиентами. Просьба еще раз проверить вашу схему и прислать self-test вашего роутера в момент, когда подключены клиенты, они успешно пингуют друг друга, но нету связи по другим протоколам. self-test(3).txt.zip

Про 100% я и не писал. Нагрузка на процессор в моём случае - первичный показатель, так как включенный/выключенный uTorrent изменяет со скоростью Wi-Fi именно загрузку процессора роутера. Т.е. скорость Wi-Fi в моём случае обратно пропорциональна загрузке процессора при включенном uTorrent. А можете попробовать синтетический тест провернуть: не utorrent использовать, а в 1-2 потока передавать данные (например по iperf, или заливая крупный файл на yandex.disk), и при этом отследить зависимость скорости WiFi от скорости отдачи на Ultra II?

Сегодня был собран тестовый стенд из 2-х машин на windows 7 с отключенными брендмауэрами, и испытана ваша схема. В результате тестов было обнаружено, что все работоспособно: пинги проходит, расшаренные папки на обеих машинах видны с обоих сторон туннелей. Есть подозрение, что может быть виновата настройка брендмауера (попробуйте выключить его совсем на обоих клиентах), или же недостаточен MTU - попробуйте на vpn-интерфейсах клиентов снизить MTU до 1280 (например https://support.zen.co.uk/kb/Knowledgebase/Changing-the-MTU-size-in-Windows-Vista-7-or-8 ), и еще если не затруднит - выложите пожалуйста self-test устройства. В любом случае, если проходят пинги (пакеты малого размера), значит внутри кинетика пакеты обрабатываются верно и все должно работать - нужно искать причину извне.

Не обязательно 100% загрузка проца при передаче wifi означает что потенциал WiFi-чипа реализуется полностью. Современное железо умное, умеет в различные DMA и по большому счету нагрузка на проц тут сильно вторичный показатель. Тем не менее это не говорит о том, что проблемы не существует.

Разве они могут быть включены одновременно? Если выключить hardware NAT (для гарантии удалить этот компонент из прошивки), то проблема продолжает ощущаться? В 2.06 и software, и hardware ppe-модули находятся в компоненте ppe. Удалив его, вы удалите и ppe software тоже! Более того, без включенного ppe software работа ppe hardware невозможна, то есть комбинация команд no ppe software ppe hardware отключит и то, и другое.

В исходниках нашего ядра есть какой-то портированный IMQ, но его работу никто не проверял и вряд ли он будет работать модулем без поддержки в самом ядре из-за изменений в структурах .. Он работает и используется как минимум для телефонии на Keenetic III / VOX / LTE. Но то, что это костыль никто не отменял.

На текущей прошивке можно еще проверить работу в режиме ppe software no ppe hardware , должно работать.