We can't clear the ip_iface until after all the routes and addresses
are updated and flushed, because the addresses and routes are
identified by the ip_iface, and if we clear the ip_iface, we don't
know which things to flush anymore.
Example: 'hso' modems have an 'iface' of 'ttyHS4' (a serial port) and
an ip_iface of 'hso0' (an ethernet port). If we clear the ip_iface too
soon, then ip_iface/ip_ifindex is invalid and thus NM has no idea what
to remove, and the default route pointing to 'hso0' sticks around.
This could also happen with other devices where the ip_iface is
different than the iface, like modems, ADSL/ATM devices, etc.
Using the new gateway-ping-timeout property, send pings to the first
gateway address until it replies or the timeout is reached, to deal
with dumb hardware that indicates carrier on but doesn't actually
pass traffic.
https://bugzilla.gnome.org/show_bug.cgi?id=702515
Just ignore this, since it happens in the current code and is
harmless. While we're here, improve the warning in the case where it
does occur to say whiich state we're overwriting. This should help
debug any future cases.
These turn out to be pretty useless, since their functions are already
covered by each device's state-changed handler or can be done in other
places like deactivate().
https://bugzilla.gnome.org/show_bug.cgi?id=702190
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 is supposed to ignore carrier and slave states for manual/static
connections when bringing up bonds and bridges, on the theory that
since static configuration does not require connectivity, there's
no need to wait for that connectivity to happen. This wasn't
happening during the IP configuration phase, but was happening
before getting to the IP config phase where the device waits
for slaves before starting IP configuration if the method
requires connectivity.
Rather than passing UDI, ifname, and driver name to the device
constructors as separate arguments, just pass the NMPlatformLink
instead and let it parse them out.
Virtual types still take UDI and ifname separately, since we create
fake NMDevices for them for autoactivating connections. That's weird
in other ways too though, so perhaps this should be revisted.
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.
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.
