- Платформы (с обновлением до Sisyphus): * alt-education-10.4-x86_64.iso KDE * alt-education-10.4-x86_64.iso XFCE * slinux-10.4-x86_64.iso XFCE - Версии пакетов: NetworkManager-applet-gtk-1.36.0-alt3.x86_64 (Sisyphus) NetworkManager-applet-gtk-1.36.0-alt1.x86_64 (p10) - Шаги для воспроизведения: 1. Подключить Ethernet к стенду; 2. На нижней панели нажать на иконку апплета; 3. Напротив подключения "System en***" нажать "Отключить" / "Отключиться"; 4. Подождать от 5 до 30 секунд. - Фактический результат: После отключения соединения "System en***" создается новое подключение с названием "en***". Интерфейс Ethernet получает только адрес ipv6. Скриншот: "Снимок экрана_20251205_162612.png". - Ожидаемый результат: Выполняется отключение от соединения "System en***", новое подключение не создается. Ошибка воспроизводится как на реальных стендах, так и на виртуальных машинах.
Created attachment 20270 [details] Скриншот с соединением "ens19", созданным после отключения от "System ens19"
Created attachment 20271 [details] Сообщения в системном журнале при отключении и создании нового подключения
Это соединение с managed-type: 'external'. External devices and managed-type --------------------------------- Even if a device is managed, that doesn't mean that NetworkManager is actively configuring it. When a device is created externally (for example via `ip link`) and has an IP configuration, NetworkManager creates a in-memory connection representing the configuration parameters on the interface such as IP addresses, routes, DNS, etc.; the connection appears as active but NetworkManager doesn't actually touch the interface. The external status is tracked in the `managed-type` member, which can have the following values: - EXTERNAL: the interface is not touched by NM. - ASSUME: this value is deprecated; it used to mean that NM should manage the device without fully reconfiguring it. Now, the interface is either managed on external. - FULL: the interface is fully managed. - REMOVED: the link was removed externally. Т.е. это кто-то другой (подозреваю avahi) сконфигурировал этот интерфейс, NM просто отслеживает это.
(Ответ для Mikhail Efremov на комментарий #3) > Т.е. это кто-то другой (подозреваю avahi) сконфигурировал этот интерфейс, NM > просто отслеживает это. Михаил, спасибо за разъяснение. Выходит, NetworkManager здесь не при чем. В таком случае, похоже на то, что avahi-daemon инициирует новое подключение, так как это происходит после следующих сообщений в системном журнале: avahi-daemon[901]: Joining mDNS multicast group on interface enp4s0.IPv6 with address 2a0c:88c0:2:811:56e1:adff:fed2:313a. avahi-daemon[901]: New relevant interface enp4s0.IPv6 for mDNS. avahi-daemon[901]: Registering new address record for 2a0c:88c0:2:811:56e1:adff:fed2:313a on enp4s0.*. Версия пакета: avahi-daemon-0.8-alt5
avahi-daemon не занимается *настройкой* интерфейсов, никак и никогда. в логе я вижу очистку адресов с интерфейса по кнопке в nm, но не вижу перевода интерфейса в down. Тогда, если в этом сегменте сети есть, например, DHCPv6 или RA, адрес ipv6 будет самоназначен. avahi-daemon после этого просто перечитывает состояние интерфейса и продолжает слушать -- что мы и видим в логе. Я не имею представления, должен ли и пытался ли nm переводить интерфейс в down, так что давайте установим хотя бы это.
Нет, NM сейчас всегда оставляет интерфейсы UP после disconnect (если правильно помню, апстрим обосновывал это тем, что нужно отслеживать link up/down на интерфейсе). Так что да, скорее всего просто RA прилетает.
Ну в общем я не вижу тут проблемы. Интерфейс сконфигурировали, NM это просто отследил. Если это не нужно - отключите RA.
