1. 18 Jan, 2018 1 commit
  2. 09 Jan, 2018 4 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      core: rework tracking config in dns-manager to use ifindex · b40729ca
      Thomas Haller authored
      Don't track the per-device configuration in NMDnsManager by
      the ifname, but by the ifindex. We should consistently treat
      the ifindex as the ID of a link, like kernel does.
      
      At the few places where we actually need the ifname, resolve
      it by looking into the platform cache. That is not necessarily
      the same as the ifname that is currently tracked by NMDevice,
      because netdev interfaces can be renamed, and NMDevice updates
      it's link properties delayed. However, the platform cache has
      the most recent notion of the correct interface name for an
      ifindex, so if we ever hit a race here, we do it now more
      correctly.
      
      This also temporarily drops support for mdns. Will be re-added next,
      but differently.
      b40729ca
    • Thomas Haller's avatar
      libnm: rename MDns flag UNKNOWN to DEFAULT · 9d92848a
      Thomas Haller authored
      "UNKNOWN" is not a good name. If you don't set the property
      in the connection explicitly, it should be "DEFAULT".
      
      Also, make "DEFAULT" -1. For one, that ensures that the enum's
      underlying integer type is signed. Otherwise, it's cumbersome
      to test "if (mdns >= DEFAULT)" because in case of unsigned types,
      the compiler will warn about the check always being true.
      Also, it allows for "NO" to be zero. These are no strong reasons,
      but I tend to think this is better.
      
      Also, don't make the property of NMSettingConnection a CONSTRUCT property.
      Initialize the default manually in the init function.
      
      Also, order the numeric values so that DEFAULT < NO < RESOLVE < YES with
      YES being largest because it enables *the most*.
      9d92848a
    • Ismo Puustinen's avatar
      dns: add mechanism for propagating mDNS setting. · 25906eda
      Ismo Puustinen authored
      Update nm-policy.c and nm-dns-manager.c so that the connection-specific
      settings get propagated to DNS manger. Currently the only such value is
      the mDNS status.
      
      Add update_mdns() function to DNS plugin interface. If a DNS plugin
      supports mDNS, it can set an interface with a given index to support
      mDNS resolving or also register the current hostname.
      
      The mDNS support is currently added only to systemd-resolved DNS plugin.
      25906eda
  3. 12 Dec, 2017 1 commit
  4. 05 Dec, 2017 3 commits
    • Thomas Haller's avatar
      settings: let invisible connection not autoconnect according to is_blocked() function · ccc93639
      Thomas Haller authored
      Previously, NMPolicy would explicitly check whether the connection is not visible,
      to skip autoconnect.
      
      We have nm_settings_connection_autoconnect_is_blocked() function, that can do that.
      The advantage is, that at various places we call nm_settings_connection_autoconnect_is_blocked()
      to determine whether autoconnect is blocked. By declaring invisible connections
      as blocked from autoconnect as well, we short-cut various autoconnection attempts,
      that previoulsy only failed later during auto_activate_device().
      ccc93639
    • Thomas Haller's avatar
      settings: remove accessor functions to connection flags · 545e3111
      Thomas Haller authored
      The accessor functions just look whether a certain flag is set. As these
      functions have a different name then the flags, this is more confusing
      then helpful. For example, if you want to know where the NM_GENERATED
      flag matters, you had to know to grep for nm_settings_connection_get_nm_generated()
      in addition to NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED.
      
      The accessor function hid that the property was implemented as
      a connection flag. For example, it was not immediately obvious
      that nm_settings_connection_get_nm_generated() is the same
      as having the NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED flag
      set.
      
      Drop them.
      545e3111
    • Thomas Haller's avatar
      settings: track visible state as regular connection flags · 0e1abe5e
      Thomas Haller authored
      We already need to re-emit the notify::flags signal.
      It's cumbersome to do this for boolean properties, so
      re-use the flags to also track the visibility state.
      0e1abe5e
  5. 29 Nov, 2017 1 commit
  6. 28 Nov, 2017 2 commits
  7. 27 Nov, 2017 22 commits
  8. 16 Nov, 2017 1 commit
  9. 13 Nov, 2017 1 commit
    • Beniamino Galvani's avatar
      core: allow slaves to autoactivate when master is available · b31118cf
      Beniamino Galvani authored
      When a master connection is deactivated by user, we set the
      autoconnect-blocked reason 'user-request' for the connection and we
      propagate the same reason to slaves. Doing so prevents the
      autoactivation of slaves when the master is manually activated again,
      because the only way to override the 'user-request' blocked reason is
      through manual activation of slaves.
      
      Instead what should happen is that the manual deactivation of a master
      marks slaves as blocked for failed dependencies. When the master
      becomes available again, slaves can autoactivate if the profile allows
      it.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1437598
      b31118cf
  10. 08 Nov, 2017 4 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      policy: don't block autoconnect for connections when disconnecting software devices · 8f131e4e
      Thomas Haller authored
      This was added by commit 979b8920
      (core: move virtual device autoconnect tracking bits out of NMManager)
      to avoid autoconnecting software devices repeatedly. That was done,
      because disconnecting a software device would delete the NMDevice
      instance, and there is no property on a device to prevent autoconnect.
      
      In the meantime, we only unrealize software devices and don't delete
      them entirely. Also, the autoconnect-blocked flags of the device are
      preserved when the device unrealized.
      
      It was anyway odd, that deactivating one software-device would block
      autoconnection for all matching connections.
      
      (cherry picked from commit 146fbfab)
      8f131e4e
    • Thomas Haller's avatar
      device: refactor autoconnect blocking by introducing NMDeviceAutoconnectBlockedFlags enum · f0731dc7
      Thomas Haller authored
      The flags allow for more then two reasons. Currently the only reasons
      for allowing or disallowing autoconnect are "user" and "intern".
      
      It's a bit odd, that NMDeviceAutoconnectBlockedFlags has a negative
      meaning. So
        nm_device_set_autoconnect_intern (device, FALSE);
      gets replaced by
        nm_device_set_autoconnect_blocked_set (device, NM_DEVICE_AUTOCONNECT_BLOCKED_INTERN);
      and so on.
      
      However, it's chosen this way, because autoconnect shall be allowed,
      unless any blocked-reason is set. That is, to check whether autoconnect
      is allowed, we do
        if (!nm_device_get_autoconnect_blocked (device, NM_DEVICE_AUTOCONNECT_BLOCKED_ALL))
      The alternative check would be
        if (nm_device_get_autoconnect_allowed (device, NM_DEVICE_AUTOCONNECT_ALLOWED_ALL) == NM_DEVICE_AUTOCONNECT_ALLOWED_ALL)
      which seems odd too.
      
      So, add the inverse flags to block autoconnect.
      
      Beside refactoring and inverting the meaning of the autoconnect
      settings, there is no change in behavior.
      
      (cherry picked from commit 5279ab5b)
      f0731dc7
    • Thomas Haller's avatar
      policy: refactor auto_activate_device() to return early · bb0536fc
      Thomas Haller authored
      (cherry picked from commit a7ef46ea)
      bb0536fc