On Wed, 2015-11-18 at 09:06 +0000, Jetchko Jekov wrote: > OK, I checked /usr/lib/udev/rules.d/85-nm-unmanaged.rules. > I extended it for my purposes (w)hy there aren't rules by default for > libvirt and docker bridges btw?
NM makes a distinction between software/virtual interfaces (like bridge/bond/team/macvlan/tap/etc) and hardware ones. By default NM will manage hardware interfaces because they always exist. But for virtual interfaces NM will not manage that interface by default if NM did not create it. But for the VM-type interfaces exposed by VMWare, VirtualBox, others and veth it's not easy to determine, so NM uses the udev rules to do so instead of hardcoding things like driver names and whatnot in NM itself. > I am including updated rules file. > With all this in place. (NM config file is still the same) > > $ udevadm test /sys/class/net/tap0 > [ -- cut -- ] > ACTION=add > DEVPATH=/devices/virtual/net/tap0 > ID_MM_CANDIDATE=1 > ID_NET_DRIVER=tun > ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link > IFINDEX=6 > INTERFACE=tap0 > NM_UNMANAGED=1 > SUBSYSTEM=net > SYSTEMD_ALIAS=/sys/subsystem/net/devices/tap0 > TAGS=:systemd: > USEC_INITIALIZED=184623250 > > I see NM_UNMANAGED=1 is there. Still, when I open my vpn connection > NM is > running dhclient on it. > Whats more interesting is that it first kills my dhclient which is > run from > openvpn's up script.. > Whats even more interesting is that this tap0 interface ends up with > 2 IPs > obtained via dhcp .... NM should not be doing this. We'll look into it; is there any chance you could file a bug on bugzilla.gnome.org with the info so it doesn't get lost/forgotten/etc? Dan > Jeka > > > > > > > > On Tue, Nov 17, 2015 at 11:45 PM Dan Williams <[email protected]> > wrote: > > > On Tue, 2015-11-17 at 13:30 +0000, Jetchko Jekov wrote: > > > Hi, > > > Here it is. > > > > NM will always detect all kernel interfaces and expose them through > > its > > APIs, but it will *not* necessarily actively manage them. That is > > what > > an "unmanaged" device means. But NM will still reflect the state > > of > > that device through its D-Bus API.s > > > > In your case, it appears that NM is touching the interface in a few > > cases, first for IPv6LL and second for the arping. NM probably > > shouldn't be doing these things. > > > > Anyway, there are two mechanisms for marking devices as "unmanaged" > > with NM 1.0.x and later: > > > > 1) NetworkManager.conf with unmanaged-devices; it appears that you > > have > > configured this correctly so far, but Thomas would know more. > > > > 2) udev rules; all virtual-type interfaces should already be marked > > 'unmanaged' by udev rules shipped with NetworkManager in > > /usr/lib/udev/rules.d/85-nm-unmanaged.rules. You can add > > additional > > rules by copying that file to /etc/udev/rules.d and modifying it > > for > > your own purposes. > > > > Dan > > > > > > > Jeka > > > > > > On Tue, Nov 17, 2015 at 2:25 PM Thomas Haller <[email protected] > > > > > > > wrote: > > > > > > > On Mon, 2015-11-16 at 21:58 +0000, Jetchko Jekov wrote: > > > > > OK, I spent some time with filtering of NM log. I removed the > > > > > debug > > > > > lines related to WiFi connections management (they contain > > > > > way > > > > > too > > > > > much sensitive data IMO, and are irrelevant to my problem > > > > > anyway). > > > > > Still the resulting file is around 280k (1,5k lines), so the > > > > > question > > > > > is: Is it OK to attach such "huge" file here? Or shall I > > > > > gzip > > > > > (bzip2/xz ) it first? > > > > > > > > If you compress it, it should be small enough. > > > > Otherwise, you can send it to me off-list. > > > > > > > > Thomas > > > _______________________________________________ > > > networkmanager-list mailing list > > > [email protected] > > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
