| Summary: | Создание нового некорректного подключения Ethernet после отключения через апплет | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Ivan Alekseev <qwetwe> | ||||||
| Component: | NetworkManager | Assignee: | Mikhail Efremov <sem> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus | ||||||
| Severity: | normal | ||||||||
| Priority: | P5 | CC: | sbolshakov, sem | ||||||
| Version: | unstable | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
|
Description
Ivan Alekseev
2025-12-05 16:33:54 MSK
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. |