On Sat, 2015-12-26 at 12:44 -0200, Daniel Miranda wrote: > I've written some udev rules to attempt to exclude docker and > libvirt > interfaces, but I'm not having great success. The bridges, even if > marked with the NM_UNMANAGED=1 udev attribute are still showing up > as > managed. Only one of the libvirt interfaces (not the bridge) is > ignored > as expected.
Hi Daniel, TL;DR: that would be expected. Configure it as unmanaged in /etc/NetworkManager/NetworkManager.conf with: [keyfile] unmanaged-devices=interface-name:docker0 (Sending a SIGHUP signal to reload that configuration, otherwise restart NM). With this configuration, the device will not be managed at all. Theoretically at least: the thread-opener (Jetchko Jekov) has the problem that he configures tap0 as unmanaged, but it is still managed(????). What you did is setting NM_UNMANGED=1 via udev. This configures the device as "default-unmanaged" -- which is different from "user- unmanaged" when configured via NetworkManager.conf. That means, the device still can be managed if either (1) the user actively does something on the device via a D-Bus command (i.e. the device is unmanaged unless you tell NM to do something with the device). (2) the device is externally up and configured to have an IP address. In case (2), NM will "assume" a connection on the device. This means it tries to gracefully handle the device and not interfere with it in a destructive way -- although the device shows up as managed and there seems to be a connection activated on the device. This is supposed not to cause any actual problems for you, although the device appears as managed. Does it cause any problems? (NM's behavior will hopefully improve in the future). Thomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
