A NMActiveConnection may disappear before a match with NMDevice is found. In
such case recheck_pending_activations() would never call the activation
callback and the client would hang indefinitely:
libnm-Message: PC: (0x95bf088) NMManager:active-connections => '['/org/freedesktop/NetworkManager/ActiveConnection/225']' (ao / NMActiveConnection)
libnm-Message: PC: (0x95bf088) NMManager:activating-connection => ''/'' (o / NMActiveConnection)
libnm-Message: PC: (0x95d0a28) NMActiveConnection:state => '4' (u)
libnm-Message: PC: (0x95d0a28) NMActiveConnection:devices => '[]' (ao / NMDevice)
libnm-Message: PC: (0x95bf088) NMManager:active-connections => '[]' (ao / NMActiveConnection)
*hang*
Let's listen for active-connection-removed and tear down the activation with
an error if the removed connection is one we're activating.
Rename NMVpnPluginUiInterface to NMVpnEditorPlugin (to clarify that
it's unrelated to NMVpnPlugin), and add it to NetworkManager.h.
Rename NMVpnPluginUiWidgetInterface to NMVpnEditor, because it's not a
widget, and will soon be used for non-gui editing too. (Also, add a
placeholder for the method that non-gui editing will use.)
Fix the typedefs to not mix up the (dummy) NMVpnEditorPlugin and
NMVpnEditor types with the types of their interface structs. Update to
use G_DEFINE_INTERFACE.
Drop NMVpnPluginUiInterfaceProp; it doesn't matter what codes plugin
implementations use for the interface properties that they implement.
Create NMIPConfig as the parent of NMIP4Config and NMIP6Config, and
remove the two subclasses from the public API; while it's convenient
to still have both internally, they are now identical to the outside
world.
b64c82a3 removed the warning in libnm-util when
nm_setting_new_from_hash() sees an unrecognized property, but we were
still warning in the equivalent libnm-core code. But it doesn't make
sense to warn here either: we do add new properties sometimes, but we
always make sure that older clients still get the information they
need as well, so they can just ignore the new property.
Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.
This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.
NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.
The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
NMSettingIP[46]Config let you associate a gateway with each address,
and the writable settings backends record that information. But it
never actually gets used: NMIP4Config and NMIP6Config only ever use
the first gateway, and completely ignore any others. (And in the
common usage of the term, an interface can only have one gateway
anyway.)
So, stop pretending that multiple gateways are meaningful; don't
serialize or deserialize gateways other than the first in the
'addresses' properties, and don't read or write multiple gateway
values either.
Now that NMSettingIP6Config inherits the dhcp-send-hostname property
from NMSettingIPConfig, fix things up so that it actually gets used.
(Note that this changes behavior: previously if ip6.dhcp-hostname was
unset, no hostname would be sent. Now, the system hostname will be
set. Also, ifcfg-rh does not currently support this property, so there
is no way to disable this...)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
a D-Bus-only property, and arrange for :addresses setter to read the
labels out of that property when creating the addresses.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
nm_setting_compare() and nm_setting_diff() were ignoring the get_func
of overridden properties, because that function requires passing an
NMConnection, and they didn't have one to pass. This wasn't a problem
yet because the only user of _nm_setting_class_override_property()
wasn't using a get_func anyway, but it would cause problems later.
The connection arg to NMSettingPropertyGetFunc is really there to be
used by D-Bus-only properties (which don't get compared anyway), not
for ordinary property overrides. So split it into two different
function types: NMSettingPropertySynthFunc (used by D-Bus-only
properties, to synthesize a fake property value for D-Bus, possibly
using other properties in the NMConnection), and
NMSettingPropertyGetFunc (used by overridden properties for both D-Bus
and comparison purposes, and not getting an NMConnection argument).
The docs for _nm_setting_class_add_dbus_only_property() and
_nm_setting_class_override_property() mistakenly still referred to
some functionality that didn't make it into the final version, and
also had only been partially updated for the GValue->GVariant change.
Missing initializers together with automatic cleanup seem to annoy GCC's
-Werror=maybe-uninitialized, breaking the --enable-more-warnings=error
builds.
Synopsis:
nmcli agent { secret | polkit | all }
The command runs separate NetworkManager secret agent or session polkit agent, or both.
It is useful when
- no other secret agent is available (such as GUI nm-applet, gnome-shell, KDE applet)
- no other polkit agent is available (such as polkit-gnome-authentication-agent-1,
polkit-kde-authentication-agent-1 or lxpolkit)
https://bugzilla.gnome.org/show_bug.cgi?id=739568
It is useful for running nmcli without --ask option, i.e. non-interactively.
Example contents of the file:
wifi.psk: s e c r e t 12345
802-1x.password:kili manjaro
802-1x.pin:987654321
We must also remove -Waggregate-return from m4/compiler-warnings.m4 because systemd
uses aggregate return (correctly) in a couple cases, and we cannot keep single-level
makefiles and override aggregate-return only for the systemd sub-library.
This client currently only supports DHCPv4 because the base systemd code
does not yet fully support DHCPv6.
The systemd code was modified to add "#if 0 /* NM_IGNORED */"
around lines that cause problems for compilation or code that is
not actually used in the library.
An adaptation layer (nm-sd-adapt) was added for glue between
systemd functions and NetworkManager, but changes to the actual
systemd code have been kept to a minimum.
The sd_event/sd_event_source functions of systemd have been
re-implemented on top of the GLib main loop.
client->secs wasn't getting set in the REBOOT state, causing
an assertion. REBOOT should work the same way as INIT, per
RFC 2131:
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
REBOOT is necessary because many DHCP servers (especially on
home routers) do not hand back the same IP address when in
response to a DISCOVER packet, even if the same client ID is used.
The raw socket sd_event_source used for DHCP server solicitations
was simply dropped on the floor when creating the new UDP socket
after a lease has been acquired. Clean it up properly so we're
not still listening and responding to events on it.
Non-ethernet interface types use different client identifier formats,
plus when doing DHCPv4 and DHCPv6 on the same interface, the client
identifier should be related per RFC 4361. Thus let the caller
override the existing MAC-based client identifier if necessary.
