This requires a very recent kernel to even compile, and the kernel
code is still rapidly changing (eg, adding IPv6 support). So take it
out for now, until it stabilizes.
This reverts commit 7f0f04d106.
Add hidden command line option --run-from-build-dir; with that, helpers
like nm-avahi-autoipd.action and nm-dhcp-helper will be called from the
build tree instead of libexecdir, which allows testing without having to
install first.
Helper paths are now stored in global variables instead of macros, and
get modified with that new option.
https://bugzilla.gnome.org/show_bug.cgi?id=698752
nm_device_state_changed() had a check to make sure it wasn't entered
recursively (which had been a source of bugs in the past), but it was
global rather than per-device, so it caused errors when VLANs changed
state in response to their parent device changing state. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=698619
Some devices aren't expected to support carrier detection, so there's
no reason to have NMDevice log about it. Move that message into
NMDeviceEthernet, where failure to support carrier-detect really is
worth mentioning.
Also, make NMDeviceEthernet use NMPlatform for carrier-detection
detection (and move the MII carrier-detect-support check from
NMDeviceEthernet into NMLinuxPlatform).
Finally, have NMDeviceGeneric actually check whether the device
supports carrier detect, rather than just always assuming it doesn't.
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.
With carrier handling moved to NMDevice, the only thing left in
NMDeviceWired was speed, which was actually ethernet-specific anyway.
So move that to NMDeviceEthernet, and then kill NMDeviceWired.
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.
nm_device_release_one_slave() may change the list head, but the
for loop in nm_device_master_release_slaves() can't handle that.
Use a while loop instead.
It *is* legitimate to (re-)activate a connection on an already-active
device, so remove the newly-added "sanity check" preventing that.
Pointed out by jklimes.
If for some reason the connection is disrupted and the AP rejects
reconnection attempts (perhaps the driver has a bug, you get
disconnected, and the AP rejects association because it thinks
you're already associated), the AP object was being removed from
the scan list by code meant to handle out-of-range or turned-off
APs. Thus even though the AP was in-range, it wouldn't be
found and the connection retried until the next scan.
Instead, only remove the AP object from the scan list if the
supplicant hasn't been able to exchange any frames with the
AP. This preserves the out-of-range handling, becuase the
supplicant wouldn't be able to talk to the AP and thus
'ssid_found' will be FALSE, and also ensures that an in-range
but confused AP says in the scan list and will be retried
immediately.
