With the move of udev logic into the Linux platform class, the
link-added signals are asynchronous, that is they are not emitted
during the call to nm_platform_*_add(), but after that call has
returned. The Fake implementation still emitted them synchronously,
which broke the testcases. Convert the Fake implementation to emit
link-added signals asynchronously and update the testcases to handle
this.
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.
NM handles the default routes, so they shouldn't show up in the NMIP4Config
for any interface. They get exposed via the 'default' and 'default6' properties
of the ActiveConnection instead.
We have to copy the UUID (key) because otherwise the pointer can be invalidated
when the connection is destroyed and problems will start.
The issue showed up as an unability to delete a conenction via D-Bus.
Reproducer:
$ nmcli con add type eth con-name AAA ifname blah
$ nmcli con delete AAA
$ nmcli con add type eth con-name AAA ifname blah
$ nmcli con delete AAA
-- here the connection is not removed from NM
(even though ifcfg- file) was removed --
Since the platform started using udev for link-added signals, we need
to run the glib mainloop to wait for the udev signals to come in,
instead of expecting them to be emitted immediately.
If things happen just right, where a bond is the first device to use
IPv6 and thus has the only reference to the NMIP6Manager, and the
RTM_NEWROUTE event comes in and triggers manager_request_ip6_info()
but then the device is removed by 'rmmod bonding', the call to
manager_request_ip6_info() could be dangling after the IP6Manager
has been disposed. Fix that.
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.
The function only checked whether wimax was enabled (rfkill/user pref)
and whether wimaxd was running. Only nm-device.c calls this function
for WiMAX devices, and the only two uses of it were during activation
(which is already covered by nm-device-wimax.c's is_available() function)
and when the device enters the UNAVAILABLE state, where it is used
to check for missing firmware, which is implemented by the parent
class, not WiMAX.
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
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
Some plugins may emit :new-connection or :unmanaged-specs-changed
while reading connections, so don't connect to those signals until
after the initial load_connections() (and just unconditionally emit
:unmanaged-specs-changed at that point).
In ifcfg-rh's get_unmanaged_specs(), don't bother to try to read the
connections first; if they haven't been read yet, just return NULL;
NMSettings will call it again after the connections have been read.
ifcfg-rh didn't let you unmanage an InfiniBand device by hardware
address because it was recording the hardware address with uppercase
letters, while nm_match_spec_hwaddr() required lowercase. Fix this by
making nm_match_spec_hwaddr() match case-insensitively (and remove the
manual lowercasing that several other places were doing to work around
this.)
keyfile didn't let you unmanage an InfiniBand device by hardware
address because it only accepted ARPHRD_ETHER hardware addresses. Fix
that by using nm_utils_hwaddr_valid() instead.
Originally it was to keep logical balance, since NMSettings exports
the NMSettingsConnection to D-Bus, but it's kind of pointless to
spend some LoC just for that.
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
We need to register NMVpnConnection's properties with the
PropertiesChanged signal (which it inherits from NMActiveConnection)
or it will ignore them.
https://bugzilla.gnome.org/show_bug.cgi?id=701713
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.
The sole purpose of this structure was to track in-progress D-Bus
pending calls, so that they could be selectively canceled if the
supplicant got disconnected during assocation (canceling only
assocation-related calls) or if the supplicant went away (canceling
both assocation-related and general calls). But its only benefit
over NMCallStore alone was knowing which list of pending calls to
remove the current pending call from, and we can just explicitly
do that in the code instead.
Thus, the SupplicantInfo structure is removed and replaced with
explicitly adding and removing the pending calls from the call
store.
(The DBusGProxy is not referenced by dbus_g_proxy_begin_call(),
the caller is expected to hold a reference to the proxy for as long
as necessary, and when the proxy is destroyed, all its pending calls
will be canceled. Since the supplicant interface owns the proxies,
there's no possibility that the proxy will outlive the supplicant
interface and thus call back into it when its dead. The old code
referenced the supplicant interface over the life of the pending
call, but that's not necessary.)
Its only purpose is to track a number of DBusGProxyCalls to let
us cancel them all at the same time, without having to track each
call individually in the supplicant code. Instead of abstracting
it to the level of GObject and gpointer, just use the types it's
meant for.
This reverts commit 7902787263.
We'll be requiring wpa_supplicant 1.0+ from now on. wpa_supplicant
1.0 is over a year old a this point, so it's not unrealistic to
bump the requirement.
NOTE: you really do want 1.1 or later anyway if you want to
successfully use WPA-EAP networks, since that version has fixes
to correctly handle PMKSA preauthentication, otherwise you'll
get periodic disconnections on enterprise networks.
'NM_DEVICE_IP_IFACE' has never been a writable property, just skip it and
explicitly call 'nm_device_set_ip_iface()' when the modem is managed by the old
ModemManager.
https://bugzilla.gnome.org/show_bug.cgi?id=701712
The whole point of having type_name separate from type was so that
unknown devices could still have known device types. But I wrote it
wrong and then didn't notice until explicitly vxlan support got
removed and vxlans started showing up as "unknown".
nm_platform_query_devices() was just looking in the link_cache,
completely ignoring udev, which means that the link list wasn't
filtered for things NM wants to ignore.
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 a "parent" field to NMPlatformLink, giving the parent device
ifindex for devices that have a parent.
Make nm_platform_link_get_all() sort the links before returning them,
so that masters appear after all of their slaves, and parent devices
appear before their children.
Remove the second call to nm_platform_query_devices() from NMManager
since it is now guaranteed that an NMDeviceVLAN's parent NMDevice will
have been created before the NMDeviceVLAN.
Merge the net-subsystem-monitoring functionality of NMUdevManager into
NMLinuxPlatform (and kill NMUdevManager). NMLinuxPlatform now only
emits link-added signals after udev processes the device, and uses
udev attributes to further identify the device. NMManager now
identifies devices solely based on the NMLinkType provided by the
platform.
There is no longer a 'ModemCapabilities' uint32 property; instead we have
'SupportedCapabilities' giving a list of uint32 values. Just read the list and
merge the values into a single mask; NM doesn't care about the exact
combinations supported.
https://bugzilla.gnome.org/show_bug.cgi?id=701668
