Network manager shows and connects to virtual interfaces

I have a feeling this problem is what was causing my vmnet interfaces to not initialize correctly as well. I ended up having to add definitions in interfaces for my vmnet1 and vmnet8 or they came up w/o IP configured, as well in kdenetworkmanager they showed up in the list of configurable devices which they never did before.

Now that I have static assignments for them they don't show up in kdenetworkmanager any longer.

This regression was caused by the fix for bug 199269. In addition to confusing network-manager, libvert is not correctly dealing with assigning addresses for its virtual network devices.

See bug 198541.

FYI, I uploaded a new hal into hardy which reverts the recent patch to detect virtual network interfaces. So this is at least not a blocker for hardy any more, but one day it will come back, so it eventually needs to get fixed.

ok, unmilestoning for hardy. Please bring this back to my attention once it becomes relevant again.

Technically, filtering by hal udi should be fairly simple - if we really need it.

what capability does such a virtual interface have in hal? If its net.80203 ... do we know that this is actually correct?

I have entry below in my /etc/network/interfaces, this caused NM to not add any Auto ethX but instead present 'ifupdown tap0'

auto tap1
iface tap1 inet static
        address 10.238.1.1
        netmask 255.255.255.0
        tunctl_user thnov

I have the same bug when trying to use hamachi. The hamachi client assigns a static IP, but networkmanager tries to run dhclient on the address which fails. The underlying interface is a tun device which gets a new mac address each time, so saving settings to tell NM to ignore it don't work. Putting the blacklisting line above helps.

how does the virt device show up in hal?

Please note that the hal patch to show virtual network devices is in Jaunty (coming from upstream).

Hi Alexander,

As requested on bug #320652, here's the lshal output for my tap0 vs. eth0 devices. The key difference I notice is the net.originating_device, which shows only '/org/freedesktop/Hal/devices/computer' for tap0 - I think this corresponds to the fact that /sys/class/net/tap0/ has no 'device' entry, and seems to be an accurate way to distinguish physical devices from virtual ones.

udi = '/org/freedesktop/Hal/devices/net_c2_af_1e_10_ca_56'
  info.capabilities = {'net', 'net.80203', 'wake_on_lan'} (string list)
  info.category = 'net.80203' (string)
  info.interfaces = {'org.freedesktop.Hal.Device.WakeOnLan'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/computer' (string)
  info.product = 'Networking Interface' (string)
  info.subsystem = 'net' (string)
  info.udi = '/org/freedesktop/Hal/devices/net_c2_af_1e_10_ca_56' (string)
  linux.hotplug_type = 2 (0x2) (int)
  linux.subsystem = 'net' (string)
  linux.sysfs_path = '/sys/devices/virtual/net/tap0' (string)
  net.80203.mac_address = 214057379482198 (0xc2af1e10ca56) (uint64)
  net.address = 'c2:af:1e:10:ca:56' (string)
  net.arp_proto_hw_id = 1 (0x1) (int)
  net.interface = 'tap0' (string)
  net.linux.ifindex = 7 (0x7) (int)
  net.originating_device = '/org/freedesktop/Hal/devices/computer' (string)
  org.freedesktop.Hal.Device.WakeOnLan.method_argnames = {'', '', 'enable'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_execpaths = {'hal-system-wol-supported', 'hal-system-wol-enabled', 'hal-system-wol-enable'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_names = {'GetSupported', 'GetEnabled', 'SetEnabled'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_signatures = {'', '', 'b'} (string list)

udi = '/org/freedesktop/Hal/devices/net_00_15_58_81_5a_8c'
  info.capabilities = {'net', 'net.80203', 'wake_on_lan'} (string list)
  info.category = 'net.80203' (string)
  info.interfaces = {'org.freedesktop.Hal.Device.WakeOnLan'} (string list)
  info.parent = '/org/freedesktop/Hal/devices/pci_8086_109a' (string)
  info.product = 'Networking Interface' (string)
  info.subsystem = 'net' (string)
  info.udi = '/org/freedesktop/Hal/devices/net_00_15_58_81_5a_8c' (string)
  linux.hotplug_type = 2 (0x2) (int)
  linux.subsystem = 'net' (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth0' (string)
  net.80203.mac_address = 91679185548 (0x1558815a8c) (uint64)
  net.address = '00:15:58:81:5a:8c' (string)
  net.arp_proto_hw_id = 1 (0x1) (int)
  net.interface = 'eth0' (string)
  net.linux.ifindex = 2 (0x2) (int)
  net.originating_device = '/org/freedesktop/Hal/devices/pci_8086_109a' (string)
  org.freedesktop.Hal.Device.WakeOnLan.method_argnames = {'', '', 'enable'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_execpaths = {'hal-system-wol-supported', 'hal-system-wol-enabled', 'hal-system-wol-enable'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_names = {'GetSupported', 'GetEnabled', 'SetEnabled'} (string list)
  org.freedesktop.Hal.Device.WakeOnLan.method_signatures = {'', '', 'b'} (string list)

On Fri, Jan 23, 2009 at 11:36:03PM -0000, Steve Langasek wrote:
> Hi Alexander,
>
> As requested on bug #320652, here's the lshal output for my tap0 vs.
> eth0 devices. The key difference I notice is the
> net.originating_device, which shows only
> '/org/freedesktop/Hal/devices/computer' for tap0 - I think this
> corresponds to the fact that /sys/class/net/tap0/ has no 'device' entry,
> and seems to be an accurate way to distinguish physical devices from
> virtual ones.

There is another difference: the driver will be NULL. However, we
patched NM to not disable such devices as we have buggy drivers that
dont get this right. I think it was a broadcom driver quite common in
dell notebooks ... and iirc that was closed so we could not fix it.

We could try to drop that patch now; but i think its safer to do what
you suggest and explicitly ignore devices that dont have a reasonable
parent device; for now checking for the computer parent seems
worth a try.

 affects ubuntu/network-manager
 status triaged

 - Alexander

well, you can only find the driver if you traverse the net.originating_device field. Keying on that looks much more robust to me...

oh, sorry, reading to fast - you already said you would do that :-)

Not sure if this is the same bug. But using new jaunty on my Dell m1210. BCM44 chipset. Network manager fails to manage the device, eth0. Working previously. Now nm shows as NULL driver.

lshal, lspci and nm-tool out put attached

On Mon, Feb 09, 2009 at 08:41:48AM -0000, aenertia wrote:
> Not sure if this is the same bug. But using new jaunty on my Dell
> m1210. BCM44 chipset. Network manager fails to manage the device, eth0.
> Working previously. Now nm shows as NULL driver.
>
> lshal, lspci and nm-tool out put attached
>
>
> ** Attachment added: "logs.gz"
> http://launchpadlibrarian.net/22388840/logs.gz
>

yes, not sure why you think this is your bug. Please open a new bug against
network-manager and subscribe me to it. Please attach your complete
syslog after reproducing whatever issue you are seeing.

 - Alexander

p.s. please dont gzip logs before attaching. thanks!

Same behavior with hamachi and wippien VPN tools. May it be linked to bug #329105 ?

Here is a tentative debdiff for this issue. Alexander, do you see any reason not to apply this patch?

patch tested here, btw; works as intended.

thanks for the debdiff ... i merged your changes with a tiny change to the jaunty branch (see related branches section).

thanks for the merge request i meant.

This bug was fixed in the package network-manager - 0.7.1~rc3-0ubuntu1

---------------
network-manager (0.7.1~rc3-0ubuntu1) jaunty; urgency=low

  * upstream 0.7.1 rc3
    + http://git.freedesktop.org/NetworkManager/NetworkManager/
    + NETWORKMANAGER_0_7 (branch)
  * point Vcs-Bzr: to new 0.7.1 packaging branch
    - update control
  * fix .symbols files for libnm-glib0 and libnm-util0 to only contain symbols
    for the right shared libs
    - update libnm-glib0.symbols
    - update libnm-util1.symbols

  [ Steve Langasek ]
  * src/nm-hal-manager.c: ignore virtual 'wired' devices whose
    originating device is /org/freedesktop/Hal/devices/computer, since
    these are generally managed by some other daemon and network-manager
    just gets in the way. LP: #199140.
    - add patches/lp199140_dont_manage_virtual_devices.patch
    - update series

 -- Alexander Sack <email address hidden> Thu, 05 Mar 2009 00:54:41 +0100