Le ecureuil

Есть реальная необходимость в этом? Ищу направления развития микропрограммы. Есть необходимость: это один из способов раздавать полученный ipv6 на подключённые подсети. Направления развития это хорошо, однако ради 2-3 человек никто это делать не будет: нужен немного более массовый спрос. Именно из-за того, что даже на обычный IPv6 почти нет спроса со стороны юзеров его практически нет в web-интерфейсе.

Распишите пожалуйста вашу схему сети и что вы желаете получить от IPsec? Без этого рекомендаций дать невозможно. Для настройки существует web-страница, а также CLI, мануал по которому уже выложен http://keenopt.ru/viewtopic.php?p=1612#p1612. Идеологически все делано наподобие cisco-like.

Пока временно можете поставить winbind из пакета samba из Entware для данной цели.

В 2.06 появился IPsec и L2TP/IPsec на базе strongSwan, работающий в качестве стандартного компонента. Для 2.05 IPsec со стороны NDMS нет и не будет, разве что использовать racoon/libreswan/strongswan из Entware. Я со своей стороны очень рекомендую именно strongSwan как самый активно развивающийся и надежный.

Чем вас не устраивает текущая реализация резервирования?

Есть реальная необходимость в этом?

Какое устройство и какая версия прошивки?

Skype скорее всего не будет никогда, а об остальном можно подумать

Маршрут тоже можно прописать через морду.

Можно и так, только это не порт 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-сервера, будем пытаться собрать у себя аналогичную схему и испытать.