1. 31 Jul, 2017 1 commit
  2. 25 Jul, 2017 2 commits
  3. 05 Jul, 2017 1 commit
  4. 07 Jun, 2017 2 commits
    • Thomas Haller's avatar
      libnm: add enum for setting priorities · a973eacb
      Thomas Haller authored
      Using plain numbers make it cumbersome to grep for
      setting types by priority.
      
      The only downside is, that with the enum values it
      is no longer obvious which value has higher or lower
      priority.
      
      Also, introduce NM_SETTING_PRIORITY_INVALID. This is what
      _nm_setting_type_get_base_type_priority() returns. For the moment
      it still has the same numerical value 0 as before. Later, that
      shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
      a973eacb
    • Thomas Haller's avatar
  5. 28 May, 2017 1 commit
  6. 05 May, 2017 2 commits
  7. 27 Apr, 2017 6 commits
    • Thomas Haller's avatar
      core: make dad_counter argument guint32 type · cfd8cf54
      Thomas Haller authored
      The dad_counter is hashed into the resulting address. Since we
      want the hashing to be independent of the architecture, we always
      hash 32 bit of dad_counter. Make the dad_counter argument of
      type guint32 for consistency.
      
      In practice this has no effect because:
        - for all our (current!) architectues, guint is the same as
          guint32.
        - all callers of nm_utils_ipv6_addr_set_stable_privacy() keep
          their dad-counter argument as guint8, so they never even pass
          numbers larger then 255.
        - nm_utils_ipv6_addr_set_stable_privacy() limits dad_counter
          further against RFC7217_IDGEN_RETRIES.
      
      (cherry picked from commit 951e5f5b)
      cfd8cf54
    • Thomas Haller's avatar
      core: avoid generating reserved IPv6 interface identifiers · 9f7433f8
      Thomas Haller authored
      https://tools.ietf.org/html/rfc7217 says:
      
        The resulting Interface Identifier SHOULD be compared against the
        reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
        and against those Interface Identifiers already employed in an
        address of the same network interface and the same network
        prefix.  In the event that an unacceptable identifier has been
        generated, this situation SHOULD be handled in the same way as
        the case of duplicate addresses (see Section 6).
      
      In case of conflict, this suggests to create a new address incrementing
      the DAD counter, etc. Don't do that. If we generate an address of the
      reserved region, just rehash it right away. Note that the actual address
      anyway appears random, so this re-hashing is just as good as incrementing
      the DAD counter and going through the entire process again.
      
      Note that now we no longer generate certain addresses like we did
      previously. But realize that we now merely reject (1 + 16777216 + 128)
      addresses out of 2^64. So, the likelyhood of of a user accidentally
      generating an address that is suddenly rejected is in the order of
      10e-13 (1 / 1,099,503,173,697). Which is not astronomically, but still
      extreeeemely unlikely.
      
      Also, the whole process is anyway build on the idea that somebody else
      might generate conflicting addresses (DAD). It means, there was always
      the extremely tiny chance that the address you generated last time is
      suddenly taken by somebody else. So, this change appears to a user
      like these reserved addresses are now claimed by another (non existing)
      host and a different address gets generated -- business as usual, as
      far as SLAAC is concerned.
      
      (cherry picked from commit f15c4961)
      9f7433f8
    • Thomas Haller's avatar
      core: move NMIPAddr to nm-core-utils.h · 8ac1bf76
      Thomas Haller authored
      (cherry picked from commit 67da0a28)
      8ac1bf76
    • Thomas Haller's avatar
      core: make dad_counter argument guint32 type · 951e5f5b
      Thomas Haller authored
      The dad_counter is hashed into the resulting address. Since we
      want the hashing to be independent of the architecture, we always
      hash 32 bit of dad_counter. Make the dad_counter argument of
      type guint32 for consistency.
      
      In practice this has no effect because:
        - for all our (current!) architectues, guint is the same as
          guint32.
        - all callers of nm_utils_ipv6_addr_set_stable_privacy() keep
          their dad-counter argument as guint8, so they never even pass
          numbers larger then 255.
        - nm_utils_ipv6_addr_set_stable_privacy() limits dad_counter
          further against RFC7217_IDGEN_RETRIES.
      951e5f5b
    • Thomas Haller's avatar
      core: avoid generating reserved IPv6 interface identifiers · f15c4961
      Thomas Haller authored
      https://tools.ietf.org/html/rfc7217 says:
      
        The resulting Interface Identifier SHOULD be compared against the
        reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
        and against those Interface Identifiers already employed in an
        address of the same network interface and the same network
        prefix.  In the event that an unacceptable identifier has been
        generated, this situation SHOULD be handled in the same way as
        the case of duplicate addresses (see Section 6).
      
      In case of conflict, this suggests to create a new address incrementing
      the DAD counter, etc. Don't do that. If we generate an address of the
      reserved region, just rehash it right away. Note that the actual address
      anyway appears random, so this re-hashing is just as good as incrementing
      the DAD counter and going through the entire process again.
      
      Note that now we no longer generate certain addresses like we did
      previously. But realize that we now merely reject (1 + 16777216 + 128)
      addresses out of 2^64. So, the likelyhood of of a user accidentally
      generating an address that is suddenly rejected is in the order of
      10e-13 (1 / 1,099,503,173,697). Which is not astronomically, but still
      extreeeemely unlikely.
      
      Also, the whole process is anyway build on the idea that somebody else
      might generate conflicting addresses (DAD). It means, there was always
      the extremely tiny chance that the address you generated last time is
      suddenly taken by somebody else. So, this change appears to a user
      like these reserved addresses are now claimed by another (non existing)
      host and a different address gets generated -- business as usual, as
      far as SLAAC is concerned.
      f15c4961
    • Thomas Haller's avatar
      core: move NMIPAddr to nm-core-utils.h · 67da0a28
      Thomas Haller authored
      67da0a28
  8. 28 Mar, 2017 1 commit
  9. 24 Mar, 2017 2 commits
  10. 23 Mar, 2017 1 commit
  11. 17 Mar, 2017 1 commit
  12. 16 Mar, 2017 2 commits
    • Thomas Haller's avatar
      core: track external activations types in the active-connection · bed2fa1b
      Thomas Haller authored
      We need a distinction between external activations and assuming
      connections. The former shall have the meaning of devices that are
      *not* managed by NetworkManager, the latter are configurations that
      are gracefully taken over after restart (but fully managed).
      
      Express that in the activation-type of the active connection.
      
      Also, no longer use the settings NM_SETTINGS_CONNECTION_FLAGS_VOLATILE
      flag to determine whether an assumed connection is "external". These
      concepts are entirely orthogonal (although in pratice, external
      activations are in-memory and flagged as volatile, but the inverse
      is not necessarily true).
      
      Also change match_connection_filter() to consider all connections.
      Later, we only call nm_utils_match_connection() for the connection
      we want to assume -- which will be a regular settings connection,
      not a generated one.
      bed2fa1b
    • Thomas Haller's avatar
      core: add activation-type property to active-connection · 8a31e66d
      Thomas Haller authored
      It is still unused, but will be useful to mark a connection
      whether it is a full activation or assumed.
      8a31e66d
  13. 14 Mar, 2017 1 commit
  14. 06 Mar, 2017 1 commit
  15. 10 Feb, 2017 3 commits
    • Thomas Haller's avatar
      core: consolidate sorting of connections by autoconnect/timestamp · 93f7ab2c
      Thomas Haller authored
      NMPolicy's auto_activate_device() wants to sort by autoconnect-priority,
      nm_utils_cmp_connection_by_autoconnect_priority() but fallback to the default
      nm_settings_connection_cmp_default(), which includes the timestamp.
      
      Extend nm_settings_connection_cmp_default() to consider the
      autoconnect-priority as well. Thus change behavior so that
      nm_settings_connection_cmp_default() is the sort order that
      auto_activate_device() wants. That makes sense, as
      nm_settings_connection_cmp_default() already considered the
      ability to autoconnect as first. Hence, it should also honor
      the autoconnect priority.
      
      When doing that, rename nm_settings_connection_cmp_default()
      to nm_settings_connection_cmp_autoconnect_priority().
      93f7ab2c
    • Thomas Haller's avatar
      core: make nm_utils_cmp_connection_by_autoconnect_priority() more robust · a8221323
      Thomas Haller authored
      Check for NULL and unexpected missing NMSettingConnection.
      Be more forgiving and accept whatever is there when comparing
      @a with @b.
      a8221323
    • Thomas Haller's avatar
      core: add nm_utils_cmp_connection_by_autoconnect_priority_p_with_data() function · eb5ceedb
      Thomas Haller authored
      Have a proper cmp() function and a wrapper *_p_with_data() that can be
      used for g_qsort_with_data().
      
      Thus, establish a naming scheme (*_p_with_data()) for these compare
      wrappers that we need all over the place. Note, we also have
      nm_strcmp_p_with_data() for the same reason and later more such
      functions will follow.
      eb5ceedb
  16. 08 Feb, 2017 1 commit
  17. 03 Feb, 2017 1 commit
    • Lubomir Rintel's avatar
      core: kill nm_spawn_process() · 6404c79e
      Lubomir Rintel authored
      It's not used anymore. Which is a good thing, because if it was used
      we'd have to get rid of the uses.
      
      It did accept a whitespace separated string for an argument, which is
      never useful for us; it indicated error either on g_spawn_sync()
      failure or an error status code of the program spawned, but only set the
      error in the former case which had let to errors.
      
      The would would be a bit nicer place without it.
      (But not much)
      6404c79e
  18. 25 Jan, 2017 4 commits
    • Thomas Haller's avatar
      core: refactor parsing in match_device_s390_subchannels_parse() · 63d4764a
      Thomas Haller authored
      Changes:
      
        - match_device_s390_subchannels_parse() should accept un-initialized
          arguments a,b,c, as they are striclty output arguments (without
          transfering ownership).
        - the output arguments should be set if (and only if) the function
          succeeds. That is, move assigning the output arguments to the end.
        - increase the BUFSIZE. It's unclear why choosing 10. Probably that
          was already sufficient as a subchannel looks like
          "0.0.f5f0,0.0.f5f1,0.0.f5f2". Still, increase it to be ample.
          If we want to restrict the parsing based on the lenght of the input,
          that should be done explicitly (but that seems not desirable).
        - use _nm_utils_ascii_str_to_int64() which checks that the range
          of the values fits in guint32.
      
      It seems wrong that match_device_s390_subchannels_eval() only compares
      the first of up to three subchannels. But leave it as is for now.
      
      (cherry picked from commit 419151a1)
      63d4764a
    • Lubomir Rintel's avatar
      core: add missing initializers to match_data_s390_subchannels_eval() · aa9e908c
      Lubomir Rintel authored
      match_device_s390_subchannels_parse() asserts that arguments point to
      zeroes.
      
        1299     static gboolean
        1300     match_data_s390_subchannels_eval (const char *spec_str,
        1301                                       MatchDeviceData *match_data)
        1302     {
        >>>     CID 160923:  Uninitialized variables  (UNINIT)
        >>>     Declaring variable "c" without initializer.
        1303            guint32 a, b, c;
      
      Fixes: b0aaff86
      (cherry picked from commit 20328ead)
      aa9e908c
    • Thomas Haller's avatar
      core: refactor parsing in match_device_s390_subchannels_parse() · 419151a1
      Thomas Haller authored
      Changes:
      
        - match_device_s390_subchannels_parse() should accept un-initialized
          arguments a,b,c, as they are striclty output arguments (without
          transfering ownership).
        - the output arguments should be set if (and only if) the function
          succeeds. That is, move assigning the output arguments to the end.
        - increase the BUFSIZE. It's unclear why choosing 10. Probably that
          was already sufficient as a subchannel looks like
          "0.0.f5f0,0.0.f5f1,0.0.f5f2". Still, increase it to be ample.
          If we want to restrict the parsing based on the lenght of the input,
          that should be done explicitly (but that seems not desirable).
        - use _nm_utils_ascii_str_to_int64() which checks that the range
          of the values fits in guint32.
      
      It seems wrong that match_device_s390_subchannels_eval() only compares
      the first of up to three subchannels. But leave it as is for now.
      419151a1
    • Lubomir Rintel's avatar
      core: add missing initializers to match_data_s390_subchannels_eval() · 20328ead
      Lubomir Rintel authored
      match_device_s390_subchannels_parse() asserts that arguments point to
      zeroes.
      
        1299     static gboolean
        1300     match_data_s390_subchannels_eval (const char *spec_str,
        1301                                       MatchDeviceData *match_data)
        1302     {
        >>>     CID 160923:  Uninitialized variables  (UNINIT)
        >>>     Declaring variable "c" without initializer.
        1303            guint32 a, b, c;
      
      Fixes: b0aaff86
      20328ead
  19. 23 Jan, 2017 3 commits
  20. 21 Jan, 2017 1 commit
  21. 20 Jan, 2017 2 commits
    • Thomas Haller's avatar
      core: refactor evaluation of device's match-spec · ba1cc6a2
      Thomas Haller authored
      Previously, we would have different functions like
        - nm_match_spec_device_type()
        - nm_match_spec_hwaddr()
        - nm_match_spec_s390_subchannels()
        - nm_match_spec_interface_name()
      which all would handle one type of match-spec.
      
      So, to get the overall result whether the arguments
      match or not, nm_device_spec_match_list() had to stich
      them together and iterate the list multiple times.
      
      Refactor the code to have one nm_match_spec_device()
      function that gets all relevant paramters.
      
      The upside is:
      
        - the logic how to evaluate the match-spec is all at one place
          (match_device_eval()) instead of spread over multiple
          functions.
      
        - It requires iterating the list at most twice. Twice, because
          we do a fast pre-search for "*".
      
      One downside could be, that we have to pass all 4 arguments
      for the evaluation, even if the might no be needed. That is,
      because "nm-core-utils.c" shall be independend from NMDevice, it
      cannot receive a device instance to get the parameters as needed.
      As we would add new match-types, the argument list would grow.
      However, all arguments are cached and fetching them from the
      device's private data is very cheap.
      
      (cherry picked from commit b957403e)
      ba1cc6a2
    • Thomas Haller's avatar
      core: refactor evaluation of device's match-spec · b957403e
      Thomas Haller authored
      Previously, we would have different functions like
        - nm_match_spec_device_type()
        - nm_match_spec_hwaddr()
        - nm_match_spec_s390_subchannels()
        - nm_match_spec_interface_name()
      which all would handle one type of match-spec.
      
      So, to get the overall result whether the arguments
      match or not, nm_device_spec_match_list() had to stich
      them together and iterate the list multiple times.
      
      Refactor the code to have one nm_match_spec_device()
      function that gets all relevant paramters.
      
      The upside is:
      
        - the logic how to evaluate the match-spec is all at one place
          (match_device_eval()) instead of spread over multiple
          functions.
      
        - It requires iterating the list at most twice. Twice, because
          we do a fast pre-search for "*".
      
      One downside could be, that we have to pass all 4 arguments
      for the evaluation, even if the might no be needed. That is,
      because "nm-core-utils.c" shall be independend from NMDevice, it
      cannot receive a device instance to get the parameters as needed.
      As we would add new match-types, the argument list would grow.
      However, all arguments are cached and fetching them from the
      device's private data is very cheap.
      b957403e
  22. 09 Jan, 2017 1 commit
    • Thomas Haller's avatar
      device: support dynamic "connection.stable-id" in form of text-substitution · f0d40525
      Thomas Haller authored
      Usecase: when connecting to a public Wi-Fi with MAC address randomization
      ("wifi.cloned-mac-address=random") you get on every re-connect a new
      IP address due to the changing MAC address.
      "wifi.cloned-mac-address=stable" is the solution for that. But that
      means, every time when reconnecting to this network, the same ID will
      be reused. We want an ID that is stable for a while, but at a later
      point a new ID should e generated when revisiting the Wi-Fi network.
      
      Extend the stable-id to become dynamic and support templates/substitutions.
      Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}".
      Any unrecognized pattern is treated verbaim/untranslated.
      
      "$$" is treated special to allow escaping the '$' character. This allows
      the user to still embed verbatim '$' characters with the guarantee that
      future versions of NetworkManager will still generate the same ID.
      Of course, a user could just avoid '$' in the stable-id unless using
      it for dynamic substitutions.
      
      Later we might want to add more recognized substitutions. For example, it
      could be useful to generate new IDs based on the current time. The ${} syntax
      is extendable to support arguments like "${PERIODIC:weekly}".
      
      Also allow "connection.stable-id" to be set as global default value.
      Previously that made no sense because the stable-id was static
      and is anyway strongly tied to the identity of the connection profile.
      Now, with dynamic stable-ids it gets much more useful to specify
      a global default.
      
      Note that pre-existing stable-ids don't change and still generate
      the same addresses -- unless they contain one of the new ${} patterns.
      f0d40525