GitLab

Seems that NLM_F_CREATE isn't enough, we need to replace anything
that's already there.  Oddly, this is even though we already cleaned
out anything that was already there.

Otherwise, priv->accept_ra_path would be NULL, which isn't very
useful and  makes nm_utils_do_sysctl() angry.  No reason we shouldn't
always create priv->accept_ra_path in the future though.

https://bugzilla.gnome.org/show_bug.cgi?id=691213

Based on work by Guillaume Rousse <guillomovitch@gmail.com>

Use:

  ./autogen.sh --enable-code-coverage
  make
  make -C src/settings check-code-coverage

So that we have the description in generated html documentation and nm-settings
manual page.

of 'nmcli device list'

Example:
nmcli -f connections d l iface wlan5

Add a "need_carrier" argument to nm_device_is_available(), to allow
distinguishing between "device is not available", "device is fully
available", and "device is available except for not having carrier".

Adjust various parts of NMDevice and NMManager to allow for the
possibility of activating a connection with :carrier-detect = "no" on
a device with no carrier, and to avoid auto-disconnecting devices with
:carrier-detect = "on-activate".

https://bugzilla.gnome.org/show_bug.cgi?id=688284

For settings corresponding to devices that have a :carrier property
(ie bond, bridge, infiniband, vlan, and wired), add a :carrier-detect
property specifying how that affects the connection:

  yes: The connection can only be activated when the device
      has carrier, and will be deactivated if the device loses
      carrier (for more than 4 seconds).
  no: The connection ignores carrier on the device; it can be
      activated when there is no carrier, and stays activated
      when carrier is lost.
  on-activate: The connection can only be activated when the
      device has carrier, but it will not be deactivated if the
      device loses carrier.

https://bugzilla.gnome.org/show_bug.cgi?id=688284

Move some duplicated carrier-handling code into NMDevice (which can
introspect itself to see if it's a subclass that has carrier).

The "mostly ignore carrier" special handling for bridges and bonds is
now also handled as part of the NMDevice-level carrier handling.

https://bugzilla.gnome.org/show_bug.cgi?id=688284

Ensure that dhclient uses the administrator-specified or machine-id
generated DUID.

The original used uuid_parse() but that function did not
work properly since the format of the machine-id is
not compatable with a real uuid.  This patch adds a new
machine_id_parse() routine to correctly convert the
character string of hex digits to a 16 byte binary string.

nm_settings_connection_init() was calling nm_connection_set_path(),
but this was pointless since that would end up getting cleared by the
property's default value shortly after init() returned (and
claim_connection() depended on this). So remove that code.

https://bugzilla.gnome.org/show_bug.cgi?id=693829

24cda2bc broke the ability to set NMConnection:path back to NULL after
it had been set, as part of a hack to try to make
NMRemoteConnection:dbus-path work. Fix that by moving the hack
entirely into NMRemoteConnection.

https://bugzilla.gnome.org/show_bug.cgi?id=693829

NMDevice has a D-Bus "AvailableConnections" property, but we weren't
exposing it on NMDevice. Fix that.

https://bugzilla.gnome.org/show_bug.cgi?id=693669

In order to resolve NMRemoteConnection-valued properties, NMObject
needs to be able to create NMRemoteConnections. But NMObject assumes
that all the objects it will be creating have "dbus-connection" and
"dbus-path" properties. So add those properties to NMRemoteConnection,
aliasing the existing "bus" and "path" properties (and ensure that
whichever version gets set, we keep that value, rather than letting it
get overwritten by the NULL default value of the other one).

https://bugzilla.gnome.org/show_bug.cgi?id=693669

apparently this never got tested...

https://bugzilla.gnome.org/show_bug.cgi?id=693669

GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).

So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.

https://bugzilla.gnome.org/show_bug.cgi?id=693678

g_malloc(), etc, never return NULL, by API contract. Likewise, by
extension, no other glib function ever returns NULL due to lack of
memory. So remove lots of unnecessary checks (the vast majority of
which would have immediately crashed had they ever run anyway, since
g_set_error(), g_warning(), and nm_log_*() all need to allocate
memory).

https://bugzilla.gnome.org/show_bug.cgi?id=693678

This reverts commit ff15a5e8 and adds netlink.h header file so that
we build on all systems. We haven't propery analyzed which systems
are affected and which are not.

If the Wifi device hadn't yet had a chance to transition away from
UNAVAILALBLE before the supplicant quit, the NMSupplicantInterface
would not be re-acquired becuase that was only happening from
the device state change handler when entering the UNAVAILALBE state,
and clearly setting the same state is NOP.

Since the old supplicant interface was torn down, and the wifi device
hadn't created a new supplicant interface (because it hadn't changed
state) nothing was listening for the supplicant to appear.

Fix that by ensuring that the wifi device reacquires a supplicant
interface whenever an old one is torn down and the device is enabled.

NetworkManager[3062]: <info> (wlan0): supplicant interface state: scanning -> down
NetworkManager[3062]: <info> (wlan0): device state change: config -> unavailable (reason 'supplicant-failed') [50 20 10]
NetworkManager[3062]: <info> (wlan0): deactivating device (reason 'supplicant-failed') [10]
NetworkManager[3062]: <info> wpa_supplicant started
NetworkManager[3062]: <info> wpa_supplicant stopped
NetworkManager[3062]: <info> (wlan0): supplicant interface state: starting -> down
<start new supplicant, nothing happens>

"./autogen.sh --enable-doc && make" produced this error:
warning: failed to load external entity "../settings-spec.xml"
../network-manager-docs.xml:57: element include: XInclude error : could not load ../settings-spec.xml, and no fallback was found

Removing settings-spec.xml from $(content_files) made the file non-DISTed but it
also removed the file as a dependency for html-build.stamp that also runs
cd html && gtkdoc-mkhtml $$mkhtml_options $(MKHTML_OPTIONS) $(DOC_MODULE) ../$(DOC_MAIN_SGML_FILE)
and $(DOC_MAIN_SGML_FILE) includes settings-spec.xml.

Fix that by making $(DOC_MAIN_SGML_FILE) dependent on setting-spec.xml.

"config-changed" signal is added to dns-manager and emited when resolv.conf is
changed. Policy listens for the signal and restarts reverse-lookup in order to
get correct results.

If no config file was specified, and if no other plugins were given
on the command-line, the keyfile plugin would not be loaded.  This
meant no connections would be read, and no connections could be
created either.

Always load the keyfile plugin.

This is a regression introduced by reworked active connections tracking:
7258dd27 core: add the NM_ACTIVE_CONNECTION_STATE_DEACTIVATED state
59420add core: track active connections directly in the manager

Because nm-manager.c:active_connection_state_changed() postpones active
connection removal to an idle handler (to be able to receive last property
change notifications), we also need to ensure that NM_ACTIVE_CONNECTION_STATE_DEACTIVATED
state is not changed again in the meantime in nm-activation-request.c:device_state_changed().
After the NMActRequest was deactivated (which is a terminal state) it was still
listening to state changes of its child NMDevice which could be starting a
new activation request.  Thus the new activation's NMDevice state would cause
the old activation request's state to change from DEACTIVATED.  To fix this
stop listening to the child NMDevice when DEACTIVATED becuase there's no point
to doing so anyway.

Reproducer:
Just activate already active connection by clicking it in nm-applet or
run 'nmcli con up id <connnection name>' several times, and then check
active connections with 'nmcli c s'.

This reverts commit df796527.

We found the real problem.

Some wireless devices don't support Ad-Hoc mode. Expose this fact in
the wireless capabilities so that clients can disable the hot-spot
option if neither CAP_ADHOC nor CAP_AP is available.

https://bugzilla.gnome.org/show_bug.cgi?id=692869