Handling of renamed interfaces

[Beniamino Galvani]

On Thu, Jan 04, 2024 at 10:23:46AM +0300, Andrei Borzenkov wrote:
> On 03.01.2024 23:26, Beniamino Galvani wrote:
> > On Wed, Jan 03, 2024 at 08:23:58PM +0300, Andrei Borzenkov wrote:
> [...]
> > > So NM treats them as external and ignores. After restart NM starts with new
> > > interface names and continues.
> > > 
> > > Is it expected behavior? I do not see any practical way to synchronize
> > > interface renaming with starting of NM. Is it possible to tell NM to
> > > continue handling interfaces under the new name?
> > 
> > > The full log after boot is available as:
> > 
> > 
> > Hi,
> > 
> > NM waits that udev has renamed the interface before starting to
> > manage it. It does so by using libudev which monitors the netlink
> > events generated by udev.
> > 
> 
> udev already has renamed this interface. No more events are going to appear.
> Nor do I understand how NM can predict the future and know that interface is
> going to be renamed and wait for this event.

It doesn't have to predict the future. udev first optionally renames
the interface, and then always emits the event. NetworkManager waits
for the event before managing the interface. When the device
transitions from "unmanaged" to "unavailable", it means that NM
started managing it.

> > You can see that in the log above, where the interface moves from
> > "unmanaged" to "unavailable" just after the rename. In "unavailable",
> > the WiFi device is waiting for wpa_supplicant to initialize the
> > interface, and you should see that it moves to "disconnected" some
> > time later.
> > 
> No, it never moves to this state.
> 
> > For an overview of device states see:
> > 
> > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.45.9-dev/docs/internal/device.md#device-states
> > 
> 
> Quoting this link
> 
> EXTERNAL: the interface is not touched by NM.
> 
> Which is exactly what we observe - after renaming interface (not device)
> state becomes "external" and NM ignores it.

In "unavailable" state, it is normal that the interface is
external. Please gather trace logs to better understand why the device
is stuck in "unavailable".

Beniamino

> > If the device stays in "unavailable", please enable trace logging in
> > NM to debug why (set level=trace in the [logging] section of
> > /etc/NetworkManager/NetworkManager.conf and restart the service).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/networkmanager/attachments/20240104/503da129/attachment.sig>