1. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      A simple style guide is instead: don't use these typedefs.
      No manual actions, I only ran the bash script:
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
  2. 27 Dec, 2017 2 commits
  3. 21 Dec, 2017 1 commit
    • Thomas Haller's avatar
      settings: drop unmaintained ifnet settings plugin of Gentoo · 0474441e
      Thomas Haller authored
      Even Gentoo disables this plugin since before 0.9.8 release
      of NetworkManager. Time to say goodbye.
      If somebody happens to show up to maintain it, we may resurrect it
      If "$distro_plugins=ifnet" was set, configure.ac would use that
      to autodetect --with-hostname-persist=gentoo. Replace that autodetect
      part by checking for /etc/gentoo-release file.
  4. 20 Dec, 2017 1 commit
    • Thomas Haller's avatar
      core: persist aspired default route-metric in device's state file · 4277bc0e
      Thomas Haller authored
      NMManager tries to assign unique route-metrics in an increasing manner
      so that the device which activates first keeps to have the best routes.
      This information is also persisted in the device's state file, however
      we not only need to persist the effective route-metric which was
      eventually chosen by NMManager, but also the aspired metric.
      The reason is that when a metric is chosen for a device, the entire
      range between aspired and effective route-metric is reserved for that
      device. We must remember the entire range so that after restart the
      entire range is still considered to be in use.
      Fixes: 6a32c64d
  5. 15 Dec, 2017 3 commits
  6. 13 Dec, 2017 1 commit
    • Andrew Zaborowski's avatar
      devices/wifi: Add the wifi-backend config option · 3967eca4
      Andrew Zaborowski authored
      Let the config file select between creating classes of NMDeviceWifi
      (for the usual wpa_supplicant based devices) and NMDeviceIwd depending
      on the new NetworkManager.conf setting.
      [bgalvani@redhat.com: fix leaking @backend in create_device()]
  7. 28 Nov, 2017 1 commit
  8. 27 Nov, 2017 1 commit
  9. 28 Sep, 2017 1 commit
    • Thomas Haller's avatar
      device: add configuration option to mark devices as unmanaged · 5778bc6a
      Thomas Haller authored
      We already have various ways to mark a device as unmanaged.
      1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus
        at runtime.
      2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and
        keyfile.unmanaged-devices in NetworkManager.conf.
      3) at runtime, via D-Bus. This is persisted in the run state file
        and persists restarts (but not reboot).
      This adds another way via NetworkManager.conf file. Note that the
      existing keyfile.unmanaged-devices (above 2) is also a configuration
      optin in NetworkManager.conf. However it has various downsides:
        - it cannot be overwritten at runtime (see commit
        - you can only explicitly mark a device as unmanaged. That means,
          you cannot use it to manage a device which is unmanaged due to
          a udev rule.
        - the name "keyfile.*" sounds like it's only relevant for the keyfile settings
          plugin. Nowadays the keyfile plugin is always loaded, so the option applies
          to NetworkManager in general.
  10. 17 Aug, 2017 1 commit
  11. 07 Jun, 2017 1 commit
  12. 24 May, 2017 1 commit
  13. 20 Apr, 2017 4 commits
  14. 19 Apr, 2017 1 commit
  15. 18 Apr, 2017 1 commit
  16. 07 Apr, 2017 2 commits
  17. 24 Mar, 2017 1 commit
  18. 25 Nov, 2016 5 commits
  19. 28 Oct, 2016 1 commit
    • Thomas Haller's avatar
      core: persist the fake permanent hardware address to the device's statefile · 5912b2f9
      Thomas Haller authored
      On devices that have no real permanent hardware address (as returned
      by ethtool), we take the current MAC address of the device.
      Currently, NM is a bit flaky about whether to accept such fake permanent
      addresses for settings like keyfile.unmanaged-devices or the per-
      connection property ethernet.mac-address. Probably, we should allow
      using fake addresses there in general.
      However, that leads to problems because NetworkManager itself changes
      the current MAC address of such devices. For example when
      and later activating a connection with
      we have a strange situation after restart and the device becomes
      We are going to avoid that, by remembering the fake permanent address
      in the device state file.
      This only matters:
        - for devices that don't have a real permanent address (veth)
        - if the user or NetworkManager itself changed the MAC address
          of the device
        - after a restart of NetworkManager, without reboot. A reboot
          clears the device state for /var/run/NetworkManager.
  20. 11 Oct, 2016 1 commit
  21. 04 Oct, 2016 2 commits
    • Beniamino Galvani's avatar
      config: pass default auth-polkit value as string instead of boolean · 63ceab3a
      Beniamino Galvani authored
      It is less efficient, but allows us to easily print the default value.
    • Thomas Haller's avatar
      core: refactor private data in "src" · 4d37f7a1
      Thomas Haller authored
      - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere.
      - reorder statements, to have GObject related functions (init, dispose,
        constructed) at the bottom of each file and in a consistent order w.r.t.
        each other.
      - unify whitespaces in signal and properties declarations.
      - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify()
      - drop unused signal slots in class structures
      - drop unused header files for device factories
  22. 03 Oct, 2016 1 commit
  23. 26 Sep, 2016 2 commits
  24. 30 Jun, 2016 2 commits
    • Thomas Haller's avatar
      config: make "ignore-carrier" a per-device configuration option · c7cee121
      Thomas Haller authored
      NetworkManager.conf already contains several per-device settings,
      that is, settings that have a device-spec as argument.
      Optimally, these settings should be moved to the new [device*]
      For now, only move main.ignore-carrier there. For the others
      it may not make sense to do so:
      - main.no-auto-default: is already merged with internal state
        from /var/lib/NetworkManager/no-auto-default.state. While
        NMConfig's write API would be fine to also persist and merge
        the no-auto-default setting, we'd still have to read the old
        file too. Thus, deprecating this setting gets quite cumbersome
        to still handle the old state file.
        Also, it seems a less useful setting to configure in the
        global configuration aside setting main.no-auto-default=*.
      - main.assume-ipv6ll-only: one day, I hope that we no longer
        assume connections at all, and this setting becomes entirely
      - keyfile.unmanged-devices: this sets NM_UNMANAGED_USER_SETTINGS,
        which cannot be overruled via D-Bus. For a future device.managed
        setting we want it it to be overwritable via D-Bus by an explicit
        user action. Thus, a device.managed property should have a different
        semantic, this should be more like a device.unmanaged-force setting,
        which could be done.
    • Thomas Haller's avatar
      config: add support for per-device configuration to NetworkManager.conf · 3cda2df1
      Thomas Haller authored
      Add a new [device*] section to NetworkManager.conf. This works similar
      like the default connection settings in [connection*].
      This will allow us to express per-device configuration in NetworkManager.conf
      in our familar style.
      Later, via NMConfig's write API it will be possible to make settings
      accessible via D-Bus and persist them in NetworkManager-intern.conf.
      This way, the user can both edit configuration snippets and modify
      them via D-Bus, and also support installing default configuration
      from the package.
      In a way, a [device*] setting is similar to networkd's link files.
      The match options is all encoded in the match-device specs.
      One difference is, that the resulting setting can be merged together
      by multiple section by partially overwriting them. This makes it
      more flexible and allows for example to drop a configuration snippet
      that only sets one property, while the rest can be merged from different
  25. 01 Jun, 2016 2 commits
    • Thomas Haller's avatar
      config: cleanup includes · 2c411e90
      Thomas Haller authored
    • Thomas Haller's avatar
      config: refactor change-flags to be a cause/reason which triggered the change · eb6140a7
      Thomas Haller authored
      For the most part, this patch just renames some change-flags, but
      doesn't change much about them. The new name should better express
      what they are.
      A config-change signal can be emitted for different reasons:
      when we receive a signal (SIGHUP, SIGUSR1, SIGUSR2) or for internal
      reasons like resetting of no-auto-default or setting internal
      Depending on the reason, we want to perform different actions.
      For example:
       - we reload the configuration from disk on SIGHUP, but not for
       - For SIGUSR1 and SIGHUP, we want to update-dns, but not for SIGUSR2.
      Another part of the change-flags encodes which part of the configuration
      actually changed. Often, these parts can only change when re-reading
      from disk (e.g. a SIGUSR1 will not change any configuration inside
      Later, we will have more causes, and accordingly more fine-grained
      effects of what should be done on reload.