eralde

Расширение ничего в этом процессе не меняет. Screen Recording 2023-01-19 at 14.57.31.mov

Всё правильно, эта функция появилась, начиная с 4.0 Alpha 1: (HTTP: добавлена поддержка подключений по IPv6)

Спасибо за диагностику, но вы сами можете убедиться в том, что веб-интерфейс при настройке провайдера не отправляет команды, связанные с маршрутами через интерфейс провайдера. Тут нужна помощь @admin и @Le ecureuil.

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

Это не проблема, а сознательное решение. Статус работы комбинированного порта (SFP + Ethernet) отображается только на дашборде. На всех остальных страницах цвета портов соответствуют цветам портов на корпусе. Вы можете создать тему в "Развитии" с предложением сделать по-другому.

@T@rkus спасибо, воспроизвел на своем устройстве. К веб-интерфейсу это не имеет отношения, но что-то явно работает не так.

Опишите, пожалуйста, пошагово, что вы делаете. Мне пока не удается воспроизвести проблему: Screen Recording 2022-12-31 at 13.08.43.mov

В версии 4.0 Alpha 2 веб-интерфейс будет показывать корректное название проводного подключения, если еще раз поменять что-нибудь в настройках этого подключения (например, название 😁) и сохранить изменения.

Я согласен с тем, что в новой версии что-то сломано. Но чинить это нужно в системной части, а не в интерфейсе, который работает так же, как работал до этого.

Этот переключатель включает/выключает GigabitEthernet1 (или другой Vlan-интерфейс в зависимости от устройства и настроек). Можно проверить по логу: Screen Recording 2022-12-29 at 08.48.54.mov Что значит Network::Interface::Ppp: "PPPoE0": connection service standby. лучше спросить у @Le ecureuil

Вам может подойти: При такой настройке будет стандартная HTTP-авторизация (https://en.wikipedia.org/wiki/Digest_access_authentication) или вообще свободный доступ.

Сппасибо, уже понятно, что ситуация требует исправления. Мы подумаем как сделать так, чтобы не дергать лишний раз настройки на интерфейсе.

Отправка no ip global была добавлена для остановки DHCP-клиента на ge1 в сценарии, когда задан какой-то VLAN для интернета. Штош, видимо, придется еще пару условий в этом месте дописать 🤖

@Le ecureuil посмотри, пожалуйста.

@Kamil какая точно модель у вашего устройства? (это можно посмотреть, выполнив через telnet команду show version)

Коллеги сказали, что нужно проверить ещё раз в следующей версии 🤷‍♂️

@saffe статус Not connected отображается, если в ответе команды "show crypto map", в поле "ike_state", написано "UNDEFINED". В вашем случае это именно так: Это условие одинаково в коде веб-интерфейса в 3.8 и в 3.9. Поправить силами веб-интерфейса это нельзя. Передаю информацию коллегам, которые отвечают за системную часть. Доступ можно закрыть. Спасибо

Подождите ещё немного, пожалуйста

Спасибо, постараюсь сегодня посмотреть, есть ли разница в веб-интерфейсе 3.8/3.9. Если её нет -- напишу коллегам, которые занимаются прошивкой.

Предоставьте, пожалуйста, даныне для доступа к устройству, где статус отображается неверно. Здесь скрытым сообщением или в личные сообщения мне, например.

@keenet07 вы правы, вашим способом можно создать два одинаковых правила (первое и третье по счету): [ { "acl": "_WEBADMIN_Guest", "index": "87c78140366d42aa2c4261507412b607", "action": "permit", "protocol": "ip", "source": "0.0.0.0", "source-mask": "0.0.0.0", "destination": "1.2.3.4", "destination-mask": "255.255.255.255", "disable": true }, { "acl": "_WEBADMIN_Guest", "index": "af28a9fd6944a5948276e658cc4fa551", "action": "deny", "protocol": "ip", "source": "0.0.0.0", "source-mask": "0.0.0.0", "destination": "87.250.250.242", "destination-mask": "255.255.255.255", "disable": true }, { "acl": "_WEBADMIN_Guest", "index": "87c78140366d42aa2c4261507412b607", "action": "permit", "protocol": "ip", "source": "0.0.0.0", "source-mask": "0.0.0.0", "destination": "1.2.3.4", "destination-mask": "255.255.255.255", "disable": true }, { "acl": "_WEBADMIN_Guest", "auto-delete": true } ] На мой взгляд, это выглядит как ошибка. Надо будет попросить коллег, которые занимаются прошивкой, посмотреть внимательнее. Общую идею про создание "почти такого же" правила я услышал. Передам её руководству. Спасибо за обсуждение

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

Честно говоря, я не знаю, что проверяет прошивка при создании нового правила. Но известно, что создать, например, два правила "Разрешить всё через TCP" или "Разрешить всё через UDP" нельзя. Попробовал вручную создать два правила "Разрешать любой IP-трафик до конкретного IP" -- воспроизвести ваш случай не удается. Возможно, действительно, проверка где-то не сработала. Интересно вот что: при настройке через веб-интерфейс правила, начиная с какой-то версии 2.x, идентифицируются по значению поля index, которое вычисляется по конфигурации правила. В вашем случае значение index должно быть одинаково.

Расскажите, пожалуйста, зачем это нужно? Добавить два одинаковых правила в один список правил прошивка не позволяет. В этом легко убедиться, если попробовать создать правило дважды, не меняя ничего в редакторе настроек правила. Что должно происходить при создании копии правила в том же самом списке?

Да, так и должно быть. К сожалению, пока непонятно, что приводит к этой ошибке.