qmxocynjca

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

Отправил скрытым сообщением.

Словил в клиенте OpenConnect какое-то перманентное кэширование IP зарезолвленного домена. После перезагрузки роутера-сервера, он прописался у меня в xxx.keenetic.link на серый IP от другого провайдера, а потом в течение часа вернулся обратно на правильный статический публичный IP. Это я сам игрался с порядком провайдеров, так что ситуация рядовая. Клиент же, после разрыва, зарезолвил хост только один раз на серый IP и постоянно стал его использовать (около 20 часов подряд), без попыток зарезолвить его опять, когда домен уже указывал на другой IP. После ручного выкл-вкл OC-интерфейса на клиенте, всё сразу завелось. Я уже начал грешить что с мобильного оператора и это прикрыли. То ли OpenConnect не резолвит домен повторно по истечении TTL домена, то ли DNS-кэширование чудит. Судя по nslookup -debug у домена TTL 5 минут. Сервер 5.0A8, клиент 4.3.4. На клиенте провайдерные DNS активны, плюс используется публичный DNS-резолвер "Yandex.DNS - Базовый". cc @Le ecureuil

Добавить возможность задать вызов любой CLI команды через нажатие кнопки. На каждый вариант нажатия (короткий, длинный, двойной) можно вписать список команд. Юзкейс может быть совершенно любым, это должно легко добавить +100 очков к конфигурабельности девайсов за минимальную стоимость. Пример: system button WLAN on click do CliRun "interface Wireguard0 up" "interface Wireguard1 up" system button WLAN on double-click do CliRun "interface Wireguard0 down" "interface Wireguard1 down" Ну круто же! Выхлоп команд или неудачу парсинга пускать в диагностику для лёгкой отладки. Навеяно вот этим ChatGPT ответом. Современные реалии таковы, что нейронка может придумать функционал, который зачастую является очень логичным и адекватным. Не иметь такую возможность в стандартной прошивке кажется упущением.

Путём экспериментов выяснилось, что гейтвей не устанавливается, если RA был обработан до перехода ipv6 на интерфейсе в состояние "running": Ip6::Dhcp::Client: "GigabitEthernet0/Vlan100": state "bound". Network::Interface::Ip6: "GigabitEthernet0/Vlan100": interface "GigabitEthernet0/Vlan100" is global, priority 65278. Network::Interface::Ip6: "GigabitEthernet0/Vlan100": adding default route via GigabitEthernet0/Vlan100 (fe80::be24:11ff:fe30:96b0). Network::Interface::Base: "GigabitEthernet0/Vlan100": "ip6" changed "ipv6" layer state "pending" to "running". @Le ecureuil есть шанс на фикс?

Ситуация: Есть незамысловатый интерфейс GigabitEthernet0/Vlan100: На другой стороне запущен radvd с radvd.conf: Где ens19: Проблема: при включении интерфейса в Кинетике, он успешно отсылает RS и получает RA (видно по tcpdump), в логах даже видно что дефолтный маршрут получен и выставлен: Network::Interface::Ip6: "GigabitEthernet0/Vlan100": adding default route via GigabitEthernet0/Vlan100 (fe80::be24:11ff:fe41:8d08). но по факту интерфейс конфигурирует только адрес, а шлюз не появляется ни в ip -6 route, ни в разделе Маршрутизация. Периодические перепосылы RA так же не добавляют гейтвей. Однако, если остановить и запустить radvd на другой стороне (именно так, т.к. stop отсылает RA с lifetime 0), то маршрут "::/0 fe80::be24:11ff:fe41:8d08" на Кинетике успешно появляется во всех местах где он должен быть виден (на карточке интерфейса, в разделе Маршрутизация, в ip -6 route). По ощущениям это выглядит как гонка, когда маршрут ещё не может быть добавлен по какой-то причине на старте интерфейса. Префиксы менял, dhcpv6 с делегацией подсовывал, параметры в radvd крутил, всё в итоге свелось к такому минимально-воспроизводимому сетапу. Прошивка 4.3.4, селф-тест следующим сообщением.

Сейчас если на основной политике нет 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 следующим сообщением прикрепил.

Есть какой-то простой способ узнать DNS адреса, прописанные в настройках Кинетика на конкретных интерфейсах? Или только руками ndmc -c "show ip name-server" и парсить текст? Может есть какой-то json-вариант ndmc?

Wireproxy - это больше десктопное решение, где проца хватает на любые комбайны. В кинетике лучше такое решать нативным WG и запуском рядом 3proxy или dante с биндом на конкретный интерфейс.

Ну так не интересно. Тогда и весь ipv4 трафик через него пойдет, верно же?

@Le ecureuil ждём какого-нибудь прошивочного механизма настройки radvd.conf для разных сценариев 🤞