Due to the hardware address changes in 77dda53b (danw/hwlen) creating
a new Bluetooth device was crashing. The changes there assumed that the
NMDeviceBt's hardware address should only be valid when we were connected
to the device, but that's not quite true. Since we already know the remote
device's Bluetooth hardware address, we already know the hardware address
for the NMDeviceBt as well.
For device types that don't override it, make
nm_device_get_hw_addr_len() use NMPlatform to find out the actual
hardware address length, rather than just defaulting to ETH_ALEN.
Fixes warnings in the logs when using tun or gre devices.
nm_device_bt_new() was trying to set NM_DEVICE_MANAGED, but that's
been read-only now for a while. Fortunately, it was already trying to
set it to FALSE, which is the default, so we can just remove that
line.
https://bugzilla.gnome.org/show_bug.cgi?id=701715
This is really, really old 2007-era code. Any NMDevice that gets
created is already supported, so there's no reason to have every
device set NM_DEVICE_CAP_NM_SUPPORTED. For those subclasses that
only set that capability, we can remove the subclass method
entirely. Next, it turns out that the "type capabilities" code
wasn't used anywhere, so remove that too. Lastly, "cipsec"
interfaces haven't been used on linux in about 5 years (they
were created by the Cisco binary-only IPSec kernel module for
Cisco VPNs long before vpnc and openswan came around) so we can
remove that code too.
Change the way that nm-properties-changed-signal works, and parse the
dbus-binding-tool-generated info to get the exact list of properties
that it's expected to export.
This makes NM_PROPERTY_PARAM_NO_EXPORT unnecessary, and also fixes the
problem of properties like NMDevice:hw-address being exported on
classes where it shouldn't be.
