qmxocynjca

Сейчас если на основной политике нет ipv6 на первой позиции, а в другой политике есть, то без костылей с ручной правкой конфига radvd нет возможности получить ipv6 в этой политике. Выглядит как баг, если честно. Уважаемые разработчики, а не прикидывали ли запуск radvd в unicast режиме с ACCEPT-ом RS сообщений по мак-адресам устройств, которые по правилам политик должны уметь в ipv6, и DROP-ом от остальных устройств? А то сейчас либо RA либо включен для всех, либо выключен для всех. Вроде в теории должно работать, но какие там подводные камни - сложно предсказать. Такой сетап позволил фильтровать RS запросы: insmod ip6table_raw.ko ip6tables -t raw -I PREROUTING -p ipv6-icmp -m icmp6 --icmpv6-type router-solicitation -m mac --mac-source <mac> -j DROP interface br0 { AdvSendAdvert on; UnicastOnly on; AdvDefaultLifetime 1800; ... } Вообще, конечно, просто разрешить использовать первый доступный ipv6 в политике кажется логичным и решило бы проблемы большинства в этом треде. Можно сделать это опциональным флагом через CLI, если это прям не хочется включать по-дефолту.

Присоединяюсь. Настроил у себя аналогичную историю и столкнулся с теми же ограничениями веб-интерфейса. Вроде как не критично, но ощущается недоработка в этом направлении. По логике эта тема должна быть в KeeneticOS -> Веб-интерфейс, так как с точки зрения CLI всё работает, а вот в веб есть искусственное ограничение, предполагающее что на одном порту может висеть либо один провайдер, либо несколько локальных сетей. На самом деле там может висеть и несколько провайдеров и несколько локальных сетей одновременно.

Тоже смущало это, но потом увидел что дополнительные несущие вступают в работу, когда пропускной способности активных не хватает. Загрузите канал и проверьте.

Если речь про opkg, то вкину свои 5 копеек: 3proxy умеет прокидывать DNS запросы через заданный интерфейс. Dante правильно работает с ipv6 и udp, но вот DNS пока умеет только через системный резолвер, что никак не обойти. Смотря каким инструментом пользуетесь, такие нюансы и получаете.

Кажется я тоже сталкивался с подобной задачей. Находилось только такое, но там всё через entware крутили. Есть уже какое-то прошивочное решение (пусть и через CLI)?

Да кажется просто надо аплоадить на него уже пожатые gzip-ом файлы и говорить Content-Encoding: gzip. Судя по доке, на отдаче сервер сам разберется - отдавать как есть или расжимать, если клиент совсем тупой. https://cloud.google.com/storage/docs/transcoding

Согласен, не настаиваю. А вот прямую ссылку было бы вполне к месту добавить.

Заметил странное - pdf-ки с инструкциями всегда отдаются не сжатыми с сервера, даже если браузер может и gzip и brotli. Занимают они в районе 7 мегабайт, а пожатые около трёх. Было бы не плохо сжимать их, все современные юзер-агенты как минимум умеют gzip.

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

Прошивки разные, устройства разные. Было бы круто иметь ссылку на актуальную версию инструкции именно для твоей модели и версии прошивки на http://192.168.1.1/a. Ещё в порядке бреда (или не совсем) - добавить опциональный компонент "Справочник команд", чтобы он был доступен в оффлайн-режиме для просмотра прям со встроенного веб-сервера.

Есть такие настройки в Web, сделайте, пожалуйста, чтобы они работали и на страничке WebCLI (http://192.168.1.1/a). Это очень удобно, если орудуешь несколькими роутерами одновременно, но сейчас WebCLI вообще без префикса и не понятно к какому роутеру она относится.

Список всех возможных хуков можно найти здесь https://github.com/ndmsystems/packages/wiki/Opkg-Component#hook-scripts Я что-то подобное решал подписыванием сразу и на ifipchanged и iflayerchanged.

Спасибо. То что нужно!

Собственно, сабж. Есть WG с прописанным IP в пире. В offline-состоянии, пир через http://127.0.0.1:79/rci/show/interface/Wireguard0 или show interface Wireguard0 выглядит так: "remote-endpoint-address": "0.0.0.0", Это баг или так и задумано? Как достать то, что в startup-config прописано по пути interface Wireguard0 wireguard peer <...> endpoint?

Проверил на 4.3.1, похоже вся эта магия работает только для основного профиля. В моём случае есть отдельный профиль, где это соединение я подвинул на самый верх. Завожу устройство в этот профиль и получаю фигу. Если при этом пошурудить основной профиль (двинуть там IPv6 соединение в самый верх), то внезапно на этом дополнительном профиле девайсы начинают видеть IPv6 маршрут и ходить по нему успешно. self-test следующим сообщением прикрепил.