Le ecureuil

Можно и так, только это не порт 47, а номер IP-протокола для GRE. Если туннель поднялся, значит GRE работает нормально - очередь разбираться с нетфильтром и роутингом.

Может, включились частоты, запрещенные в РФ или наоборот. Формирование луча на двух всенаправленных антеннах? Смешно. Реальные результаты дают дорогие корпоративные роутеры, где по 20-30 направленных антенн, пробивающие в очень зашумленной среде. Скорее всего "нероссийский" или "draft" клиент, ведь автор так и не указал свое клиентское устройство.

# Открываем доступ к vpn снаружи iptables -A INPUT -p tcp --dport 1723 -j ACCEPT Для PPTP этого недостаточно, еще нужно разрешить GRE: iptables -A INPUT -p gre -j ACCEPT Само соединение-то поднимается? Неплохо бы дамп в wireshark обмена клиента и сервера увидеть.

так-то вопрос был про офподдержку opkg в прошивках GIGA II Тоже скоро будет.

Со временем 2.06 будет и для них, пока же только 2.05 и 2.04.

В инсталляционном скрипте пакетов время ожидания 120 с, в коллбеках и инициализаторе - 8 секунд. По идее после этого все должно завершаться.

На данный момент со встроенным DLNA это невозможно, только если использовать сторонний DLNA из keenopt/Entware.

Спасибо за ответ. А с широковещанием через VPN как быть? Какое конкретно у вас широковещание: на весь интернет, или именно на broadcast-адрес удаленной сети?

А sane-то удалось завести на ndms v2 (в смысле модулей ядра достаточно, или нужны дополнительные)? Если да, то есть вероятность, что пакет cups из Entware вам подойдет.

Да, можете еще опцию nobind на клиенте попробовать - ситуация с привязкой клиента к определенному порту и IP нужна крайне редко.

Можно попробовать через опцию --fragment max Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes. включить внутреннюю фрагментацию UDP, скажем добавить в конфиг fragment 1280 на клиенте и сервере. Если поможет, то нужно подобрать максимальное значение, при котором связь еще есть.

Все довольно стандарно - поищите 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 , должно работать.