1. 06 May, 2019 1 commit
    • Beniamino Galvani's avatar
      settings: fix failed assertion · d80818e6
      Beniamino Galvani authored
      Fix the following assertion failure:
        g_object_ref: assertion 'G_IS_OBJECT (object)' failed.
      nm_settings_add_connection() can return a NULL connection.
      Fixes: f034f17f ('settings: keep the added connection alive for a bit longer')
      (cherry picked from commit 48ce3628)
  2. 18 Apr, 2019 2 commits
    • Thomas Haller's avatar
      shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core · 284ac92e
      Thomas Haller authored
      "libnm-core" implements common functionality for "NetworkManager" and
      Note that clients like "nmcli" cannot access the internal API provided
      by "libnm-core". So, if nmcli wants to do something that is also done by
      "libnm-core", , "libnm", or "NetworkManager", the code would have to be
      Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
      Note that:
        0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
           On the other hand, "libnm-libnm-core-aux.la" is not used by
           libnm-core, but provides utilities on top of it.
        1) they both extend "libnm-core" with utlities that are not public
           API of libnm itself. Maybe part of the code should one day become
           public API of libnm. On the other hand, this is code for which
           we may not want to commit to a stable interface or which we
           don't want to provide as part of the API.
        2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
           and thus directly available to "libnm" and "NetworkManager".
           On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
           and "NetworkManager".
           Both libraries may be statically linked by libnm clients (like
        3) it must only use glib, libnm-glib-aux.la, and the public API
           of libnm-core.
           This is important: it must not use "libnm-core/nm-core-internal.h"
           nor "libnm-core/nm-utils-private.h" so the static library is usable
           by nmcli which couldn't access these.
      Note that "shared/nm-meta-setting.c" is an entirely different case,
      because it behaves differently depending on whether linking against
      "libnm-core" or the client programs. As such, this file must be compiled
      (cherry picked from commit af07ed01)
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · d984b2ce
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      (cherry picked from commit 80db06f7)
  3. 28 Mar, 2019 1 commit
    • Lubomir Rintel's avatar
      settings: keep the added connection alive for a bit longer · f034f17f
      Lubomir Rintel authored
      Fixes a crash on failed AddAndActivate:
        $ ip link set eth0 down
        $ nmcli d conn eth0
        Error: Failed to add/activate new connection: Connection 'eth0' is not available on device eth0 because device has no carrier
        <NetworkManager crashes>
        #3  0x000055555558b6c5 in _nm_g_return_if_fail_warning
        #4  0x00005555557008c7 in nm_settings_has_connection
        #5  0x0000555555700e5f in pk_add_cb
        #6  0x0000555555726e30 in pk_call_cb
        #7  0x0000555555726e30 in pk_call_cb
        #8  0x0000555555726e30 in pk_call_cb
        #9  0x00005555555aaea8 in _call_id_invoke_callback
        #10 0x00005555555ab2e8 in _call_on_idle
  4. 07 Mar, 2019 2 commits
  5. 12 Feb, 2019 2 commits
  6. 30 Dec, 2018 1 commit
  7. 19 Sep, 2018 1 commit
    • Thomas Haller's avatar
      core: improve logging why startup-complete is blocked · 793afb7d
      Thomas Haller authored
          "manager: check_if_startup_complete returns FALSE because of eth0"
          "manager: startup complete is waiting for device 'eth0' (autoactivate)"
      Also, the logging line is now more a human readable sentence, but still
      follows the same pattern as later
          "manager: startup complete"
      Meaning: grepping for "startup complete" becomes more helpful because
      one first finds the reasons why startup-complete is not yet reached,
      followed by the moment when it is reached.
  8. 06 Sep, 2018 4 commits
  9. 28 Aug, 2018 1 commit
    • Thomas Haller's avatar
      settings: use delegation instead of inheritance for NMSettingsConnection and NMConnection · 38273a88
      Thomas Haller authored
      NMConnection is an interface, which is implemented by the types
      NMSimpleConnection (libnm-core), NMSettingsConnection (src) and
      NMRemoteConnection (libnm).
      NMSettingsConnection does a lot of things already:
        1) it "is-a" NMDBusObject and exports the API of a connection profile
           on D-Bus
        2) it interacts with NMSettings and contains functionality
           for tracking the profiles.
        3) it is the base-class of types like NMSKeyfileConnection and
           NMIfcfgConnection. These handle how the profile is persisted
           on disk.
        4) it implements NMConnection interface, to itself track the
           settings of the profile.
      3) and 4) would be better implemented via delegation than inheritance.
      Address 4) and don't let NMSettingsConnection implemente the NMConnection
      interface. Instead, a settings-connection references now a NMSimpleConnection
      instance, to which it delegates for keeping the actual profiles.
        - by delegating, there is a clearer separation of what
          NMSettingsConnection does. For example, in C we often required
          casts from NMSettingsConnection to NMConnection. NMConnection
          is a very trivial object with very little logic. When we have
          a NMConnection instance at hand, it's good to know that it is
          *only* that simple instead of also being an entire
          NMSettingsConnection instance.
          The main purpose of this patch is to simplify the code by separating
          the NMConnection from the NMSettingsConnection. We should generally
          be aware whether we handle a NMSettingsConnection or a trivial
          NMConnection instance. Now, because NMSettingsConnection no longer
          "is-a" NMConnection, this distinction is apparent.
        - NMConnection is implemented as an interface and we create
          NMSimpleConnection instances whenever we need a real instance.
          In GLib, interfaces have a performance overhead, that we needlessly
          pay all the time. With this change, we no longer require
          NMConnection to be an interface. Thus, in the future we could compile
          a version of libnm-core for the daemon, where NMConnection is not an
          interface but a GObject implementation akin to NMSimpleConnection.
        - In the previous implementation, we cannot treat NMConnection immutable
          and copy-on-write.
          For example, when NMDevice needs a snapshot of the activated
          profile as applied-connection, all it can do is clone the entire
          NMSettingsConnection as a NMSimpleConnection.
          Likewise, when we get a NMConnection instance and want to keep
          a reference to it, we cannot do that, because we never know
          who also references and modifies the instance.
          By separating NMSettingsConnection we could in the future have
          NMConnection immutable and copy-on-write, to avoid all unnecessary
  10. 24 Jul, 2018 1 commit
    • Thomas Haller's avatar
      core: give better error reason why device is incompatible with profile · 33a88ca5
      Thomas Haller authored
      Note the special error codes  NM_UTILS_ERROR_CONNECTION_AVAILABLE_*.
      This will be used to determine, whether the profile is fundamentally
      incompatible with the device, or whether just some other properties
      mismatch. That information will be importand during a plain `nmcli
      connection up`, where NetworkManager searches all devices for a device
      to activate. If no device is found (and multiple errors happened),
      we want to show the error that is most likely relevant for the user.
      Also note, how NMDevice's check_connection_compatible() uses the new
      class field "device_class->connection_type_check_compatible" to simplify
      checks for compatible profiles.
      The error reason is still unused.
  11. 03 Jun, 2018 1 commit
    • Beniamino Galvani's avatar
      settings: let connections keep NMSettings alive · 3fb4eed3
      Beniamino Galvani authored
      The NMSettings instance can't be disposed while there is any exported
      connection. Ideally we should unexport all connections on NMSettings'
      disposal, but for now leak @self on termination when there are
      connections alive.
      This fixes the following bug on shutdown:
       assertion failed: (c_list_is_empty (&priv->connections_lst_head))
       #0  raise () from target:/lib64/libc.so.6
       #1  abort () from target:/lib64/libc.so.6
       #2  g_assertion_message (domain=0x66cab2 "NetworkManager", file=0x6a5e48 "src/settings/nm-settings.c", line=1929)
       #3  g_assertion_message_expr () at gtestutils.c:2555
       #4  finalize (object=0x1dab170) at src/settings/nm-settings.c:1929
       #5  g_object_unref (_object=0x1dab170) at gobject.c:3340
       #6  dispose (object=0x1de50b0) at src/nm-manager.c:7139
       #7  g_object_unref (_object=0x1de50b0) at gobject.c:3303
       #8  _nm_singleton_instance_destroy () at src/nm-core-utils.c:138
       #9  _dl_fini () from target:/lib64/ld-linux-x86-64.so.2
       #10 __run_exit_handlers () from target:/lib64/libc.so.6
       #11 exit () from target:/lib64/libc.so.6
       #12 main (argc=<optimized out>, argv=<optimized out>) at src/main.c:460
  12. 01 Jun, 2018 1 commit
  13. 31 May, 2018 4 commits
  14. 30 Apr, 2018 1 commit
    • Thomas Haller's avatar
      settings: avoid lookup in nm_settings_has_connection() · feb1ec1e
      Thomas Haller authored
      There is no need to perform a lookup by path. NMSettings is a singleton,
      it has the connection exactly iff the connection is linked.
      Also add an assertion to double-check that the results agree with
      the previous implementation.
  15. 24 Apr, 2018 1 commit
    • Thomas Haller's avatar
      settings: pass in authentication subject to nm_settings_add_connection_dbus() · 8b5f6412
      Thomas Haller authored
      nm_settings_add_connection_dbus() has two callers. One of them is NMManager
      during AddAndActivate. In this case, the NMActiveConnection already created
      an auth-subject. Re-use it.
      Note how creating an auth-subject involves reading procfs to determine
      whether the process still exists. This is not about the additional
      overhead of that, but about the race where the process could drop
      of in the meantime. The calling process might be gone now, and we would
      fail creating the auth-subject. There is no need for that, because we
      already evaluated all information we need. Quite likely, in the case
      of this race, PolicyKit will also determine that the process is gone
      and fail authorization too. But that's PolicyKit's decision to make,
      not nm_settings_add_connection_dbus()'s.
  16. 18 Apr, 2018 2 commits
  17. 16 Apr, 2018 1 commit
    • Thomas Haller's avatar
      Thomas Haller authored
      For one, these flags are "internal" flags. Soon, we will gain
      a new NMSettingsConnectionFlags type that is exported on D-Bus
      and partly overlaps with these internal flags. However, then we
      will need the "flags" properties to expose the public bits.
      This property only exists because other parts are interested in
      notification signals. Note that we encourage NMDbusObject types
      to freeze/thaw property-changed notifications. As freezing the
      notifications also delays the signals, this is not desired for
      the purpose where internal users subscribe to the signal.
  18. 13 Apr, 2018 13 commits